2010-04-28 3 views
8

Согласно Wikipedia NoSQL article, существует множество реализаций NoSQL.Какое хранилище NoSQL для выбора

В чем разница между хранилищами, ориентированными на документы и ключевые значения (как их часто упоминают люди)?

+0

Это зависит от ваших потребностей. – Htbaa

+0

Это вопрос о NoSQL вообще, не связанный с кем-то нужным. –

+0

хорошо, в зависимости от вашей ситуации, лучший выбор изменится, потому что у них нет всех тех же функций. Вам нужно очень масштабируемое решение? или это просто небольшой магазин? вам нужно выполнить поиск? или просто получить ключи? Это в основном чтение? Написать? И то и другое? производительность отличается от одного к другому. Таким образом, вопрос, требующий уточнения ваших требований –

ответ

13

Вот запись в блоге, которую я написал, Visual Guide to NoSQL Systems, что иллюстрирует основные различия между некоторыми из самых популярных систем. Самая большая разница между ними заключается в том, какие из следующих двух они предпочитают оптимизировать для: согласованности, доступности и допустимости разделов.

+1

Идея, что вы можете выбрать два, вводит в заблуждение: http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html – TTT

2

На одном уровне документ и ключ/значение очень похожи - оба будут возвращать объект при запросе ключа. В чистом ключе/значении этот объект будет простой строкой, хотя он может быть сериализованным сложным объектом. База данных документов расширяет ее с помощью функций для работы с этим объектом, таких как частичное обновление или индексирование поиска.

Помимо этого вам нужно будет подумать о своих конкретных требованиях - NOSQL охватывает множество разных систем, и в отличие от баз данных SQL они имеют совершенно разные преимущества/недостатки для конкретного сценария.

2

По-моему, я действительно не вижу, насколько Кассандра несовместима. Он не может выполнять последовательные обновления, но я никогда не работал с моделью базы данных, в которой необходимы обновления, а не согласованные версии вставки (иногда называемые версиями версий, даже если они на самом деле не обновляются.

Также Cassandra может быть полностью ACID, если вы делаете свою модель данных ACID. Вместо того, чтобы использовать транзакцию с базой данных, делайте транзакцию так, как это делают банки. Там транзакция не является изменением mulit-данных, а фактическим объектом данных.

Банковский счет не имеет денег в них: транзакции и текущее состояние ваших счетов вычисляются по транзакциям. Такие транзакции не являются функцией базы данных, а частью модели данных. Они не должны быть мгновенно доступны для всех узлов, чтобы быть последовательными, потому что они я mmutable.

Я не нашел случая, когда создание неизменяемых данных не решает проблему согласованности. Это в сочетании с превращением транзакций в модель данных в качестве неизменяемых данных (однократно прочитанное много раз) удовлетворяют требованиям ACID.

Atomic - транзакция как уникальный неизменяемый объект/строка становится атомной без какого-либо сложного объекта базы данных для ее поддержки.

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

Изоляция. Транзакция, которая делает это собственный объект данных, не должна мешать другим и поэтому изолирована.

Долговечность - если потерянные транзакции данные теряются, это эквивалентно восстановлению базы данных до ее предыдущего состояния. Если данные не потеряны, то они находятся в состоянии после транзакции. В любом случае он заполняет требование долговечности ACID.

Верно, что в модели данных «банка» не может быть достигнуто несколько вещей. У вашей учетной записи не может быть строки ACID с фиксированной суммой денег. Хотя сами транзакции являются ACID, это не означает, что данные в зависимости от них могут быть. Это связано с тем, что все транзакции могут пока не отображаться со всех узлов. Они могут быть даже в другой базе данных банков.Поэтому баланс вашей учетной записи не может обеспечить согласованность ACID, но нет никаких оснований для того, чтобы у него было такое требование, пока все важные данные имеют согласованность ACID - что он делает.

В качестве примера я использовал банковскую базу данных, поскольку он часто используется в качестве примера того, как выполнять транзакции SQL с откатом на балансе аккаунта - то, что НИКОГДА не происходит в реальных реализациях ... потому что банковские транзакции должны поддерживать асинхронные мульти- транзакции базы данных или, другими словами, межбанковские операции.

Вы также можете связать это с файловой системой. Кассандра (например) может дать вам последовательное представление о неизменном снимке файла. Вам не гарантируется просмотр последнего моментального снимка, но моментального снимка. Благодаря этому он становится таким же последовательным, как CVS/SVN или CODA.

Смежные вопросы