NoSQL бази от данни @ Openfest 2010

1,877 views

Published on

За това колко е важно да познавате инструментите, с които може да си свършите работата, когато RDBMS не са достатъчни.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,877
On SlideShare
0
From Embeds
0
Number of Embeds
389
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • хохохо
  • Първо кратко изясняване какво влагам в думата NoSQL. NoSQL е звучно име на група от 50-тина нерелационни бази данни. Тези бази от данни имат малко общо по между си, като повечето не поддържат никакви форми на SQL.
    Под нерелационни бази от данни имам предвид, че не използват двумерни таблици, игнорират първа нормална форма и като следствие - не поддържат ANSI SQL. Нека разясня.
  • Релационният модел изисква данните да са нормализирани - за да няма аномалии при работата с тях. Съответно извличането става със заявки като тази:
  • За да имат една данна само на едно място, ви трябват заявки като тази. Има доста проблеми в нея, но като такситата ментета, с малко данни е ОК.
  • В реалността има началници, които ви съветват да разширите функционалността. Това е около ½ от схемата на истински софтуер за CRM.
  • А това е истинска заявка, която една програма генерираше и ми казаха да оправя.
    Като стартирате проекта, всичко това работи прекрасно. Ако проектът е успешен, той расте едновременно като обем данни, като брой заявки и като функционалност. Доста е вероятно да усетите първите проблеми с времето за достъп до данните, преди да натрупате обем данни, който сам по себе си да е проблем.
  • ОК на къси дистанции
  • Записваме обобщени данни по колони, индексираме по тях, актуализираме при обновяване или периодично.
  • За да имат една данна само на едно място, ви трябват заявки като тази. Има доста проблеми в нея, но като такситата ментета, с малко данни е ОК.
  • Ако просто решите, че като разделите базата данни на 4 ще решите проблемите, може да прибегнете към репликация.
  • Мастър-слейв репликацията помага донякъде, но…
  • Ако трябва да разпределите базата си данни на части върху отделни сървъри, рибката няма да остане жива. Ще ви е нужна клиентска логика за разделяне и трябва да се откажете от join
  • Скалируемост – възможност да се работи с нарастнал трафик или нарастнал обем, чрез добавяне на хардуер.
    RDBMS се забавят с нарастването на обема. JOIN, GROUP BY, ALTER стават бавни и постепенно невъзможни.
    Partitioning в RDBMS се прави по PK. Ако употребата на данните не е по PK, забавяне.
    Sharding е разделяне на данните от 1 таблица по критерий с код, написан от програмистите.
  • Скалируемост – възможност да се работи с нарастнал трафик или нарастнал обем, чрез добавяне на хардуер.
    RDBMS се забавят с нарастването на обема. JOIN, GROUP BY, ALTER стават бавни и постепенно невъзможни.
    Partitioning в RDBMS се прави по PK. Ако употребата на данните не е по PK, забавяне.
    Sharding е разделяне на данните от 1 таблица по критерий с код, написан от програмистите.
  • Всичко ново е добре забравеното старо?
  • NoSQL решенията включват най-разнообразни идеи. Отказът от SQL е общ, отказът от фиксирана схема – почти. JS, JSON и REST са разпространени. Евентуалната консистентност е почти обща. MapReduce е особено популярен.
    Има разработена теорема на Ерик Брюър – от наличност, консистентност и толерантност към разделяне на части, БД може да осигури само 2. За това обичайно се жертва консистентността, като най-малкото зло.
  • Около 15 разгледани в известни детайли, от общо няколко десетки. BigTable клонинги, Динамо клонинги, Документни БД, k/v персистентни cache и др.
  • Многомерен масив, състоящ се от
    Колони и семейства от колони, записани под формата на
    SSTable, която е
    Компресия компресирана, върху
    GFS, която е разпределена и обобщени с
    MapReduce
    2004 г.
  • Втората идеологически най-влиятелна NoSQL DB, 2007 г. Концепцията й е да е хоризонтално скалируема, с равнопоставени сървъри, разположени в ринг. Използва gossip протокол за синхронизация, vector clocks за определяне коя версия на данната е остаряла, въвежда евентуалната консистентност, свежда модела на данните до ключ и стойност.
  • Суперколоната е допълнително ниво на йерархия от колони. Ако имаме колона с домашен адрес и колона с модел автомобил, суперколоната човек с идентификатор името му, обединява автомобила и адреса. Има шел, свой протокол за разпространение на измененията.
    Тази БД почти погреба digg, но пък изстреля в небесата reddit.
  • Users и Lectures са семейсва от колони
  • Суперколоната е допълнително ниво на йерархия от колони. Ако имаме колона с домашен адрес и колона с модел автомобил, суперколоната човек с идентификатор името му, обединява автомобила и адреса. Има шел, свой протокол за разпространение на измененията.
    Тази БД почти погреба digg, но пък изстреля в небесата reddit.
  • Документът в каучдб е json обект с произволна структура, подреден по ключ. Идентификаторите могат да са както от потребителя, така и автоматично генерирани. За да бъдат дотъпни данните от вътрешността на документа се използват изгледи, чрез design documents. Изгледите са материални и много бързи. Използват дистрибутиран между сървърите mapreduce за генерирането си. За решаване на конфликти се използва MVCC, базиран на ревизии, които съществуват едновременно.
  • Документът в каучдб е json обект с произволна структура, подреден по ключ. Идентификаторите могат да са както от потребителя, така и автоматично генерирани. За да бъдат дотъпни данните от вътрешността на документа се използват изгледи, чрез design documents. Изгледите са материални и много бързи. Използват дистрибутиран между сървърите mapreduce за генерирането си. За решаване на конфликти се използва MVCC, базиран на ревизии, които съществуват едновременно.
  • Документът в каучдб е json обект с произволна структура, подреден по ключ. Идентификаторите могат да са както от потребителя, така и автоматично генерирани. За да бъдат дотъпни данните от вътрешността на документа се използват изгледи, чрез design documents. Изгледите са материални и много бързи. Използват дистрибутиран между сървърите mapreduce за генерирането си. За решаване на конфликти се използва MVCC, базиран на ревизии, които съществуват едновременно.
  • Документът в каучдб е json обект с произволна структура, подреден по ключ. Идентификаторите могат да са както от потребителя, така и автоматично генерирани. За да бъдат дотъпни данните от вътрешността на документа се използват изгледи, чрез design documents. Изгледите са материални и много бързи. Използват дистрибутиран между сървърите mapreduce за генерирането си. За решаване на конфликти се използва MVCC, базиран на ревизии, които съществуват едновременно.
  • Документна база, с конзолен шел, индекси за достъп в реално време. Много бързо писане, много компромиси по отношение консистентност. Fail при 4sq, голям успех на други места.
  • NoSQL бази от данни @ Openfest 2010

    1. 1. NoSQL бази от данни – възможности и приложение* За живота, вселената и всичко останало.
    2. 2. Hi! Веселин Николов http://dzver.com/blog/ @dzver NoSQL БД – възможности и приложение, Веселин Николов
    3. 3. Темата NoSQL БД – възможности и приложение, Веселин Николов 1. Какво е NoSQL 2. Проблеми пред RDBMS 3. Някои NoSQL DB 4. MySQL като NoSQL DB 5. Малко практика
    4. 4. Какво е NoSQL NoSQL БД – възможности и приложение, Веселин Николов Нерелационни бази от данни, които евентуално не поддържат SQL
    5. 5. Проблеми пред RDBMS? NoSQL БД – възможности и приложение, Веселин Николов  С прост модел  Добре познати  Надеждни  Таблиците се възприемат лесно  Учат се в училище  Стандартизиран SQL
    6. 6. Примерна схема NoSQL БД – възможности и приложение, Веселин Николов
    7. 7. Примерна заявка NoSQL БД – възможности и приложение, Веселин Николов SELECT u.id, max(u.username), count(*) FROM users u JOIN followers f ON u.id = f.followed GROUP BY u.id ORDER BY count(*) DESC LIMIT 10;
    8. 8. Истинска схема NoSQL БД – възможности и приложение, Веселин Николов
    9. 9. govnokod.ru NoSQL БД – възможности и приложение, Веселин Николов
    10. 10. OK NoSQL БД – възможности и приложение, Веселин Николов
    11. 11. Компромиси NoSQL БД – възможности и приложение, Веселин Николов ALTER TABLE users ADD COLUMN followers_count INT DEFAULT 0; Промени в схемата И кеширане извън БД: Memcache, Redis
    12. 12. …и проблеми NoSQL БД – възможности и приложение, Веселин Николов Размер на БД > RAM Размер на индексите > RAM Размер на БД > дисковото пространство Locks Недостиг на CPU => #FAIL
    13. 13. Ограничени ресурси NoSQL БД – възможности и приложение, Веселин Николов
    14. 14. Проблемни места NoSQL БД – възможности и приложение, Веселин Николов
    15. 15. Репликация NoSQL БД – възможности и приложение, Веселин Николов
    16. 16. Скалируемост NoSQL БД – възможности и приложение, Веселин Николов
    17. 17. Partitioning + Sharding = • JOIN #FAIL • Трудни обобщения • Много логика във вашето приложение NoSQL БД – възможности и приложение, Веселин Николов
    18. 18. Проблеми пред RDBMS • Скалируемост • Partitioning • Sharding • Кеширане • Денормализация • Промени в схемата NoSQL БД – възможности и приложение, Веселин Николов
    19. 19. Теоремата CAP Консистентност (C): Всички клиенти на базата от данни виждат една и съща информация, даже при конкурентно обновяване. Наличност (A): Всички клиенти на базата от данни могат да достъпват някоя версия на информацията. Възможност за разделяне върху много сървъри (P): Базата от данни може да се разделя върху множество сървъри. Изберете две. Ерик Брюър, 2000 г. NoSQL БД – възможности и приложение, Веселин Николов
    20. 20. NoSQL решения • Управление на компромисите • Евентуална консистентност • Отказ от фиксирана схема • JavaScript, JSON, REST • MapReduce • GFS, HDFS • Отказ от SQL NoSQL БД – възможности и приложение, Веселин Николов
    21. 21. Мащаби на бедствието • BigTable, Dynamo • Cassandra, Riak • CouchDB, MongoDB • Redis, MemcacheDB • Hadoop, Hbase, RavenDB, Kyoto Cabinet, Sherpa, Neo4j, FlockDB, Hypertable и др. NoSQL БД – възможности и приложение, Веселин Николов
    22. 22. Google BigTable • Многомерен масив • Колони и семейства от колони • SSTable • Компресия • GFS • 2004 г. NoSQL БД – възможности и приложение, Веселин Николов
    23. 23. Amazon Dynamo • Хоризонтално скалируема • Евентуално консистентна • Равнопоставени сървъри • Key/value БД • put/get • 2007 г. NoSQL БД – възможности и приложение, Веселин Николов
    24. 24. Cassandra • BigTable + Dynamo = Cassandra • Настройваема консистентност • Колони, семейства, суперколони • Cassandra-cli shell • Вместо индекси, нови семейства • Gossip • Java, Thrift NoSQL БД – възможности и приложение, Веселин Николов
    25. 25. Колони { "name": “City", "value": “Sofia“, "timestamp": "1290196015" }, { "name": “Code", "value": “1784“, "timestamp": "1290196013“ } NoSQL БД – възможности и приложение, Веселин Николов
    26. 26. Семейства колони { “Veselin Nikolov":{ "Users": { "emailAddress": {"name":"emailAddress","value":“dzver@bar.com"}, "webSite":{"name":"webSite", "value":"http://bar.com"} }, “Lectures":{ “Openfest":{"name":“lectureName", "value":“NoSQL DB"} } }, “Stefan Kanev": { "Users": { "emailAddress":{"name":"emailAddress", "value":“skanev@foo.br"}, "twitter":{"name":"twitter", "value":“skanev"} } } “Lectures": { “Openfest":{"name":“lectureName", "value":“MongoDB Rulez"} } NoSQL БД – възможности и приложение, Веселин Николов
    27. 27. Суперколони Friend_Diggs { // Column Family – гласовете на приятелите 12345 : { // story_id as Row key user_id: { // SuperColumns are User’s IDs friend_id1: true, friend_id2: true, friend_id3: true } } } Суперк олона = k/v ,двойк а в к оято стойността е набор от .к олони https://nosqleast.com/2009/slides/sarkissian-cassandra.pdf NoSQL БД – възможности и приложение, Веселин Николов
    28. 28. Някои проблеми с Cassandra 1. Digg #FAIL, Reddit #WIN 2. Индекс = Ново семейство колони 3. Ново семейство колони = restart 4. WTF is a SuperColumn? NoSQL БД – възможности и приложение, Веселин Николов
    29. 29. CouchDB • Документи • REST, JavaScript, JSON • Материални изгледи • MapReduce • MVCC – ревизии на документите NoSQL БД – възможности и приложение, Веселин Николов
    30. 30. Документ { "_id": "163271278f438b6ccb9c87879d0001c7", "_rev": "3-29830772003eb7f6e49f55834d28c640", "url": "http://dzver.com/blog/?p=2000", "author": "Eric Brewer", "title": "The CAP Theorem", "comments": [ { "author": "Veselin Nikolov", "published": "2010-08-17 15:00:00", "body": "Cool Dude!" }, { "author": "Mark Twain", "published": "2010-08-17 15:01:00", "body": “Вафла трепач" } ] } NoSQL БД – възможности и приложение, Веселин Николов
    31. 31. Още документи { "_id": "60206fa17eb65874b38594abd57ded49", "_rev": "3-29830772003eb7f6e49f55834d28c640", "doc_type": “Post”, "url": "http://dzver.com/blog/?p=2000", "author": "Eric Brewer", "title": "The CAP Theorem", } { "_id": "60206fa17eb65874b38594abd57dcafd", "_rev": "1-5e9d312e407a13661fa69fb626c78466", "body": "Hello Dolly", "doc_type": "Comment", "author": “Veselin", "id_post": "60206fa17eb65874b38594abd57ded49", } NoSQL БД – възможности и приложение, Веселин Николов
    32. 32. Design document NoSQL БД – възможности и приложение, Веселин Николов
    33. 33. Материален изглед NoSQL БД – възможности и приложение, Веселин Николов
    34. 34. Някои проблеми с CouchDB 1. Бавен запис 2. Бавно първоначално създаване на изгледи 3. GROUP BY .. ORDER BY count – само с hack. NoSQL БД – възможности и приложение, Веселин Николов
    35. 35. MongoDB • Документи • Индекси • Mongo shell • JSON, JavaScript, MapReduce • ReplicaSet, auto sharding* NoSQL БД – възможности и приложение, Веселин Николов
    36. 36. Разлики с CouchDB • No single server durability • MapReduce работи подобно на SQL • Работи бързо NoSQL БД – възможности и приложение, Веселин Николов
    37. 37. Hadoop • HDFS • MapReduce • HBase • Pig • Hive NoSQL БД – възможности и приложение, Веселин Николов
    38. 38. Още няколко важни NoSQL DB • Redis & MemcacheDB • FlockDB за friends & followers • Neo4j за графи • Riak – Dynamo аналог с MapReduce NoSQL БД – възможности и приложение, Веселин Николов
    39. 39. MySQL NoSQL 1. FriendFeed 2. Yoshinori Matsunobu NoSQL БД – възможности и приложение, Веселин Николов
    40. 40. MySQL във FriendFeed 1. Сериализиран масив в blob 2. Нова таблица за всеки индекс http://bret.appspot.com/entry/how-friendfeed-uses-mysql NoSQL БД – възможности и приложение, Веселин Николов
    41. 41. MySQL без SQL 1. NDB Cluster + NDBAPI 2. HandlerSocket Plugin 3. Заявки по PK, без SQL http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as NoSQL БД – възможности и приложение, Веселин Николов
    42. 42. Малко практика NoSQL БД – възможности и приложение, Веселин Николов Тестовете са спекулативни, ако не се провеждат в разпределена среда
    43. 43. Запис на данни 5000 документа в 50 нишки MySQL: 65 sec, MongoDB 21 sec, Cassandra: 23 sec NoSQL БД – възможности и приложение, Веселин Николов
    44. 44. Извличане на данни 1000 изчитания на статия с нейните коментари, конкурентно в 10 нишки MySQL: 2.4 sec, CouchDB: 0.57 sec. NoSQL БД – възможности и приложение, Веселин Николов
    45. 45. Обобщение • Прости и бързи • Подходящи за специфични задачи • Нужни са много тестове NoSQL БД – възможности и приложение, Веселин Николов
    46. 46. Перспективи за развитие • MongoDB single server durability • Cassandra – конфигурация в реално време • CouchDB – подреждане на MapReduce • Hadoop PIG, Hadoop Hive QL • MapReduce в RDBMS NoSQL БД – възможности и приложение, Веселин Николов
    47. 47. Въпроси? NoSQL БД – възможности и приложение, Веселин Николов
    48. 48. Благодаря! NoSQL БД – възможности и приложение, Веселин Николов

    ×