Різниця між базами даних, заснованими на документах, та базами даних, що базуються на ключах / значеннях?


97

Я знаю, що існують три різні, популярні типи баз даних, не пов’язаних з sql.

  • Ключ / значення: Редіс, Токійський кабінет, Memcached
  • Стовпець Сім'я: Кассандра, HBase
  • Документ: MongoDB, CouchDB

Я читав довгі блоги про це, не розуміючи так багато.

Я знаю реляційні бази даних і бавлюся навколо баз даних на основі документів, таких як MongoDB / CouchDB.

Хтось може сказати мені, які основні відмінності між ними та двома колишніми у списку?


4
існує п’ять: (1) магазини ключових цінностей: Oracle Coherence, Redis, кабінет Кіото (2) Бази даних у стилі BigTable: Apache HBase, Apache Cassandra (3) Бази даних документів: MongoDB, CouchDB (4) Повнотекстові пошукові системи: Apache Lucene, Apache Solr (5) Графічні бази даних: neo4j, FlockDB, див. Nosql-data-modeling-methods
Gary Gauh

Відповіді:


74

Основні відмінності - модель даних та можливості запитів.

Ключові цінності магазинів

Перший тип дуже простий і, ймовірно, не потребує подальших пояснень.

Модель даних: більше, ніж зберігає ключ-значення

Хоча існують суперечки щодо правильної назви баз даних, таких як Кассандра, я хотів би назвати їх магазинами сімейних колонок . Хоча пари ключ-значення є важливою частиною Кассандри, але це не обмежується лише цим. Це дозволяє вкладати пари ключ-значення, тому ключ може посилатися на кілька пар під-ключ-значення.

Однак ви не можете вкладати пари ключ-значення нескінченно довго. Ви обмежені трьома рівнями (сімейства стовпців) або чотирма рівнями вкладеності (сімейства суперколон). Якщо термін сімейство стовпців не дзвонить, див. WTF - це стаття SuperColumn , це гарне пояснення моделі даних Кассандри.

Бази даних документів , такі як CouchDB та MongoDB, зберігають цілі документи у вигляді об'єктів JSON . Ви можете розглядати ці об'єкти як вкладені пари ключ-значення. На відміну від Кассандри, ви можете вкладати пари ключ-значення скільки завгодно. JSON також підтримує масиви і розуміє різні типи даних, такі як рядки, числа та булеві значення.

Запит

Я вважаю, що магазини сімейства колонок можна запитувати лише за допомогою ключа або шляхом написання функцій зменшення карти. Ви не можете запитувати значення, як це було б у базі даних SQL. Якщо вашій програмі потрібні більш складні запити, вам доведеться створювати та підтримувати індекси для доступу до бажаних даних.

Бази даних документів також підтримують запити за функціями ключа та зменшення карти, але також дозволяють робити базові запити за значенням, наприклад, "Надіслати мені всіх користувачів із понад 10 публікаціями". Таким чином, бази даних документів є більш гнучкими.


2
Отже, сховища ключ-значення, такі як redit, не дозволяють зберігати вкладені значення key: values? І з вашого опису, потім зберігання цілої бази даних (із СУБД) у Кассандрі звучить не дуже розумно, оскільки вона не дозволяє гнучкі запити та має обмежену глибину вкладеності, я не помиляюся?
never_had_a_name

7
@ajsie: Правильні сховища ключ-значення не підтримують вкладені пари ключ-значення. Більшість із них підтримують спеціалізовані цінності, такі як списки. Кассандра сильно відрізняється від СУБД, оскільки обидва призначені для вирішення дуже різних проблем. Системи СУБД спрямовані на реляційні дані, які потребують складних запитів, тоді як Кассандра спрямована на обробку величезних обсягів, в основному нереляційних даних. Звичайно, можна перенести базу даних RDBMS до Кассандри, але насправді не дуже розумно. Кожен з них має своє використання.
Нільс ван дер Рест

Тож кожна база даних документів також є ключем, сховищем значень, де значення - це просто JSON типу {value: base64 (val)}?
GroovyDotCom

@GroovyDotCom: Так, ви можете використовувати базу даних документів для зберігання простих об'єктів ключ / значення.
Нільс ван дер Рест

15

Аєнде дав гарне пояснення щодо різниці між базою даних і ключами:

База даних документів за своєю суттю є сховищем ключів / значень за одним основним винятком. Замість того, щоб просто зберігати в ньому будь-яку крапку, документ db вимагає, щоб дані зберігались у форматі, який база даних може зрозуміти (тобто JSON, XML тощо). У більшості dob dbs це означає, що тепер ми можемо дозволяти запити щодо даних документа.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.