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

Question

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

, а также:

Имя было попыткой описать Появление растущего числа нереляционные распределенные данные магазины, которые часто не пытались предоставить КИСЛОТНЫЕ гарантии.

и

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

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

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

При прагматическом подходе может показаться, что Apache CouchDB наиболее близок к воплощению совместимости с ACID, сохраняя при этом слабосвязанную нереляционную ментальность "NoSQL".

Answer 3

FoundationDB совместим с ACID:

http://www.foundationdb.com/

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

Answer 4

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

Мне больше всего не хватает этой функции в MongoDB

Answer 5

Пожалуйста, убедитесь, что вы прочитали введение Мартина Фаулера о базах данных NoSQL . И соответствующее видео.

Прежде всего, мы можем выделить два типа баз данных NoSQL:

1. Агрегатно-ориентированные базы данных;
2. Графо-ориентированные базы данных (например, Neo4J).

По своей структуре большинство Графо-ориентированных баз данных являются ACID !

Тогда как насчет других типов?

В агрегированных базах данных мы можем поместить три подтипа:

• Базы данных NoSQL на основе документов (например, MongoDB, CouchDB);
• Базы данных Key / Value NoSQL (например, Redis);
• Базы данных NoSQL семейства столбцов (например, Hibase, Cassandra).

То, что мы здесь называем Aggregate , - это то, что Эрик Эванс определил в своем доменно-управляемом дизайне как самодостаточный для сущностей и объектов-значений в данном ограниченном контексте.

Как следствие, агрегат представляет собой набор данных, которые мы взаимодействовать как единое целое. Агрегаты образуют границы для ACID операции с базой данных. (Мартин Фаулер)

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

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

некоторые обновления 2019 года: начиная с версии 4.0, для ситуаций, когда требуется атомарность для обновлений нескольких документов или согласованность между чтениями нескольких документов, MongoDB обеспечивает многодокументных транзакций для наборов реплик .

Answer 6

ACID и NoSQL полностью ортогональны. Одно не подразумевает другого.

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

NoSQL просто означает, что это не SQL. Многие люди сбиты с толку и думают, что это означает очень масштабируемое хранение на диком западе и сверхбыстрое хранение. Это не так. Это не означает сохранение значения ключа или возможную согласованность. Все это означает "не SQL", на этой планете много баз данных, и большинство из них не являются SQL ^{[цитата нужна]} .

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

Answer 7

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

Answer 8

Да, MarkLogic Server - это решение NoSQL (мне нравится называть базу данных документов), которое работает с ACID-транзакциями

Answer 9

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

Answer 10

Дедушка NoSQL: ZODB совместим с ACID. http://www.zodb.org/

Однако, это только Python.