Есть ли какое-либо хранилище данных NoSQL, которое является совместимым ACID?

ОБНОВЛЕНИЕ (27 июля 2012 г.): Ссылка на статью в Википедии была обновлена, чтобы отразить версию статьи, которая была актуальной на момент публикации этого ответа. Обратите внимание, что текущая статья в Википедии была значительно переработана!

Что ж, согласно более старой версии статьи в Википедии о NoSQL :

NoSQL - это движение, продвигающее слабо определенный класс нереляционных данных хранилища, которые нарушают долгую историю реляционных баз данных и гарантии ACID.

, а также:

Название было попыткой описать появление растущего числа нереляционных распределенных хранилищ данных , которые часто не пытались чтобы предоставить гарантии ACID.

и

Системы NoSQL часто предоставляют слабые гарантии согласованности, такие как конечная согласованность и транзакции , ограниченные отдельными элементами данных, даже хотя можно наложить полные гарантии ACID , добавив дополнительный уровень промежуточного программного обеспечения .

Вкратце, я бы сказал, что одним из основных преимуществ хранилища данных «NoSQL» является его отчетливое отсутствие свойств ACID . Кроме того, ИМХО, чем больше вы пытаетесь реализовать и применять свойства ACID , тем дальше вы от «духа» хранилища данных «NoSQL» и тем ближе к «истине» RDBMS вы получите (условно говоря, конечно).

Однако все сказанное «NoSQL» - очень расплывчатый термин, допускающий индивидуальные интерпретации и во многом зависит от того, насколько пуристической точки зрения вы придерживаетесь.Например, большинство современных СУБД на самом деле не соответствуют всем из 12 правил Эдгара Ф. Кодда его модели отношений. !

Если исходить из прагматического подхода, то может показаться, что Apache CouchDB наиболее близок к воплощению как ACID-соответствия, так и при сохранении слабосвязанного, нереляционного менталитета «NoSQL».

«NoSQL» не является четко определенным термином. Это очень расплывчатое понятие. Таким образом, невозможно даже сказать, что является продуктом NoSQL, а что нет. Не почти все продукты, обычно маркируемые этим лейблом, являются магазинами, работающими по принципу "ключ-значение".

принимают посмотрите на теорему CAP

РЕДАКТИРОВАТЬ: RavenDB, похоже, совместим с ACID

Если вы ищете ACID-совместимое хранилище ключей/значений, есть Berkeley DB. Среди графовых баз данных по крайней мере Neo4j и HyperGraphDB предлагают ACID транзакции (HyperGraphDB фактически использует Berkeley DB для низкоуровневого хранения в настоящее время).

VoltDB является участником, который заявляет о соответствии ACID, и хотя он все еще использует SQL, его цели те же с точки зрения масштабируемости

db4o

В отличие от настойчивости с собственной проверкой или сериализация, db4o - это ACID транзакция безопасна и позволяет запросы, репликация и схема изменения во время выполнения

http://www.db4o.com/about/productinformation/db4o/

Я отправлю это как ответ исключительно для поддержки беседы - Тим Мэхи , Наврот и CraigTP имеют предлагаемые жизнеспособные базы данных. CouchDB я бы предпочел из-за использования Erlang , но есть и другие.

Я бы сказал, что ACID не противоречит и не отрицает концепции NoSQL ... Хотя, похоже, существует тенденция, следующая за мнением, выраженным dove ], Я бы сказал, что концепции разные.

NoSQL в основном представляет собой простую схему «ключ-значение» (например, Redis) или схему в стиле документа (собранные пары «ключ-значение» в «документной» модели, например, MongoDB) как прямую альтернативу явной схеме в классических СУБД .Это позволяет разработчику обрабатывать вещей асимметрично, в то время как традиционные движки обеспечивают жесткую одинаковость во всей модели данных. Причина, по которой это так интересно, состоит в том, что он предоставляет другой способ обработки изменений , а для больших наборов данных он предоставляет интересные возможности для работы с объемами и производительностью.

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

• (A) когда вы делаете что-то для изменения базы данных, изменение должно работать или не работать в целом
• (C) база данных должна оставаться согласованной (это это довольно обширная тема)
• (I) если в то же время происходят другие вещи, они не должны видеть вещи в середине обновления
• (D), если система взорвется (аппаратная или программная) база данных должна иметь возможность восстанавливать себя; и если он говорит, что завершил применение обновления, он должен быть уверен

. Разговор становится немного более возбужденным, когда дело доходит до идеи распространения и ограничений . Некоторые механизмы РСУБД предоставляют возможность применять ограничения (например, внешние ключи), которые могут иметь элементы распространения (как каскад ). Проще говоря, одна «вещь» может иметь отношение к другой «вещи» в базе данных, и если вы измените атрибут одной, это может потребовать изменения другой (обновления, удаления, ... множества опций). Базы данных NoSQL , которые в основном (на данный момент) ориентированы на большие объемы данных и большой трафик, похоже, решают идею распределенных обновлений, которые происходят в (с точки зрения потребителя) произвольных временных рамках. По сути, это специализированная форма репликации , управляемая посредством транзакции - поэтому я бы сказал, что если традиционная распределенная база данных может поддерживать ACID, то может и база данных NoSQL.

Некоторые ресурсы для дальнейшего чтения:

• Статья в Википедии по ACID
• Википедия по ограничениям распространения
• Википедия (да, мне нравится сайт, хорошо?) По нормализации базы данных
• Документация Apache по CouchDB с хороший обзор того, как он применяет ACID
• Википедия на Кластерные вычисления
• Википедия (опять же ...) на транзакциях базы данных