2
Был фактически FoundationDB, который был кислотно-совместимым. Теперь Apple схватил его
—
пользователь без шляпы
Ответы:
Я опубликую это как ответ исключительно для поддержки разговора - Тим Махи , Наврот и КрэйгТП предложили жизнеспособные базы данных. CouchDB будет моим предпочтением из-за использования Erlang , но есть и другие.
Я бы сказал, что ACID не противоречит и не отрицает концепцию NoSQL ... Хотя после мнения, высказанного голубем , кажется, что существует тенденция , я бы сказал, что эти концепции различны.
В основе NoSQL лежит простая схема ключ-значение (например, Redis) или схема в стиле документа (собранные пары ключ-значение в модели «документ», например MongoDB) как прямая альтернатива явной схеме в классических РСУБД. Это позволяет разработчику обрабатывать вещи асимметрично, в то время как традиционные механизмы применяют жесткое единообразие в модели данных. Причина, по которой это так интересно, заключается в том, что он предоставляет другой способ работы с изменениями , а для больших наборов данных - интересные возможности для работы с объемами и производительностью.
ACID содержит принципы , регулирующие как изменения применяются к базе данных. В очень упрощенном виде говорится: (моя собственная версия):
Разговор становится немного более возбуждающим, когда дело доходит до идеи распространения и ограничений . Некоторые ядра СУБД предоставляют возможность применять ограничения (например, внешние ключи), которые могут иметь элементы распространения (в виде каскада ). Проще говоря, одна «вещь» может иметь связь с другой «вещью» в базе данных, и если вы измените атрибут одного, это может потребовать изменения другого (обновлено, удалено, ... много вариантов). Базы данных NoSQL , в основном (на данный момент) ориентированные на большие объемы данных и большой трафик, похоже, занимаются идеей распределенных обновлений, которые происходят в (с точки зрения потребителя) произвольных временных рамок. Это в основном специализированная форма репликации, управляемая черезтранзакция - так что я бы сказал, что если традиционная распределенная база данных может поддерживать ACID, то и база данных NoSQL.
Некоторые ресурсы для дальнейшего чтения:
ОБНОВЛЕНИЕ (27 июля 2012 г.): ссылка на статью в Википедии была обновлена, чтобы отразить версию статьи, которая была актуальной на момент публикации этого ответа. Обратите внимание, что текущая статья в Википедии была значительно переработана!
Ну, согласно старой версии статьи в Википедии о NoSQL :
NoSQL - это движение, продвигающее слабо определенный класс нереляционных хранилищ данных, которые ломаются от долгой истории реляционных баз данных и гарантий ACID.
а также:
Название было попыткой описать появление растущего числа нереляционных распределенных хранилищ данных, которые часто не пытались предоставить гарантии ACID.
и
Системы NoSQL часто предоставляют слабые гарантии согласованности, такие как возможная согласованность и транзакции, ограниченные отдельными элементами данных, даже если можно наложить полные гарантии ACID, добавив дополнительный уровень промежуточного программного обеспечения.
Так, в двух словах, я бы сказал , что один из главных преимуществ «NoSQL» хранилище данных является явным отсутствием в ACID свойств. Кроме того, ИМХО, чем больше человек пытается реализовать и применять свойства ACID , тем дальше от «духа» хранилища данных «NoSQL» вы получаете, и тем ближе к «истинной» СУБД вы получаете (условно говоря, конечно, ).
Однако все, что говорит «NoSQL», является очень расплывчатым термином и открыто для индивидуальных интерпретаций, и в значительной степени зависит от того, насколько сильно вы придерживаетесь пуристской точки зрения. К примеру, самый современный RDBMS системы фактически не придерживаются все из Кодд «s 12 правил его реляционной модели !
Принимая прагматичный подход, создается впечатление, что CouchDB Apache наиболее близок к воплощению соответствия ACID, сохраняя при этом слабосвязанный нереляционный менталитет «NoSQL».
Пожалуйста , прочитайте введение Мартина Фаулера о базах данных NoSQL . И соответствующее видео.
Прежде всего, мы можем выделить два типа баз данных NoSQL:
По своей структуре большинство графо-ориентированных баз данных являются ACID !
Тогда как насчет других типов?
В агрегатно-ориентированные базы данных мы можем поместить три подтипа:
То, что мы здесь называем Агрегатом , - это то, что Эрик Эванс определил в своем доменно-управляемом дизайне как самодостаточный для сущностей и объектов-ценностей в данном ограниченном контексте.
Как следствие, агрегат - это набор данных, с которыми мы взаимодействуем как единое целое. Агрегаты образуют границы для операций ACID с базой данных. (Мартин Фаулер)
Итак, на уровне Aggregate мы можем сказать, что большинство баз данных NoSQL могут быть такими же безопасными, как и СУБД ACID , с соответствующими настройками. Исходя из этого, если вы настроите свой сервер на лучшую скорость, вы можете столкнуться с чем-то не-ACID. Но репликация поможет.
Главное, что вы должны использовать базы данных NoSQL как есть, а не как (дешевую) альтернативу СУБД. Я видел слишком много проектов, злоупотребляющих отношениями между документами. Это не может быть кислотой. Если вы остаетесь на уровне документа, то есть на агрегированных границах, вам не нужна транзакция. И ваши данные будут в такой же безопасности, как и в базе данных ACID, даже если они не являются действительно ACID, поскольку вам не нужны эти транзакции! Если вам нужны транзакции и обновление нескольких «документов» одновременно, вы больше не находитесь в мире NoSQL - так что используйте вместо этого движок СУБД!
некоторые обновления 2019 года: начиная с версии 4.0, для ситуаций, когда требуется атомарность для обновлений нескольких документов или согласованность между чтениями нескольких документов, MongoDB обеспечивает транзакции с несколькими документами для наборов реплик .
FoundationDB совместим с кислотой:
Он имеет правильные транзакции, поэтому вы можете обновлять несколько разнородных элементов данных в режиме ACID. Это используется в качестве основы для поддержания индексов на более высоком уровне.
В этом вопросе кто-то должен упомянуть OrientDB : OrientDB - это база данных NoSQL, одна из немногих, которая полностью поддерживает транзакции ACID. ACID не только для RDBMS, потому что он не является частью реляционной алгебры. Таким образом, возможно иметь базу данных NoSQL, поддерживающую ACID.
Я больше всего скучаю по этой функции в MongoDB
ACID и NoSQL полностью ортогональны. Одно не подразумевает другого.
У меня есть тетрадь на столе, я использую ее, чтобы вести записи о том, что мне еще предстоит сделать. Этот блокнот является базой данных NoSQL. Я запрашиваю его, используя линейный поиск с «кешем страниц», поэтому мне не всегда приходится искать каждую страницу. Он также совместим с ACID, так как я гарантирую, что я пишу только одну вещь за раз, а не во время чтения.
NoSQL просто означает, что это не SQL. Многие люди сбиты с толку и думают, что это означает очень масштабируемое хранение на диком западе и сверхбыстрое хранение. Это не так. Это не означает сохранение значения ключа или возможную согласованность. Все это означает "не SQL", на этой планете много баз данных, и большинство из них не являются SQL [необходима цитата] .
Вы можете найти много примеров в других ответах, поэтому мне не нужно перечислять их здесь, но есть базы данных, отличные от SQL, с ACID-соответствием для различных операций, некоторые являются ACID только для записи одного объекта, а некоторые гарантируют гораздо больше. Каждая база данных отличается.
«NoSQL» не является четко определенным термином. Это очень расплывчатая концепция. Таким образом, даже невозможно сказать, что является продуктом NoSQL, а что нет. Не почти все продукты, типично маркированные лейблом, являются магазинами ключевой стоимости.
Да, MarkLogic Server - это решение NoSQL (мне нравится называть базу данных документов), которое работает с ACID-транзакциями.
Дедушка NoSQL: ZODB совместим с ACID. http://www.zodb.org/
Однако это только Python.
Как один из создателей NoSQL (я был одним из первых разработчиков Apache CouchDB и выступал на первом мероприятии NoSQL, проходившем в CBS Interactive / CNET в 2009 году), я рад видеть, что новые алгоритмы создают возможности, которых раньше не было , Протокол Calvin предлагает новый способ думать о физических ограничениях, таких как CAP и PACELC .
Вместо активной / пассивной асинхронной репликации или активной / активной синхронной репликации Calvin сохраняет правильность и доступность при сбоях реплики, используя RAFT-подобный протокол для ведения журнала транзакций. Кроме того, транзакции обрабатываются детерминистически в каждой реплике, что исключает возможность возникновения взаимоблокировок, поэтому соглашение достигается только с помощью одного раунда консенсуса. Это делает его быстрым даже при развертывании в нескольких облаках по всему миру.
FaunaDB является единственной реализацией базы данных, использующей протокол Calvin, что делает его уникальным для рабочих нагрузок, требующих целостности данных на уровне мэйнфреймов, с масштабированием и гибкостью NoSQL.
Если вы ищете ACID-совместимое хранилище ключей / значений, есть Berkeley DB . Среди графовых баз данных, по крайней мере, Neo4j и HyperGraphDB предлагают транзакции ACID (HyperGraphDB фактически использует Berkeley DB для хранения низкого уровня в настоящее время).
Эту концепцию участники Википедии определяют как:
[…] Класс современных систем управления реляционными базами данных, которые стремятся обеспечить одинаковую масштабируемую производительность систем NoSQL для рабочих нагрузок чтения-записи в режиме онлайн-обработки транзакций (OLTP), сохраняя при этом гарантии ACID традиционной системы баз данных.
[1][2][3]
[1]Нэнси Линч и Сет Гилберт, «Гипотеза Брюера и осуществимость последовательных, доступных, допускающих разбиение веб-сервисов» , Новости ACM SIGACT, том 33, выпуск 2 (2002), стр. 51-59.
[2] «Теорема CAP пивовара » , julianbrowne.com, получено 02-Mar-2010
[3] «Теорема Брюера CAP о распределенных системах» , royans.net
MongoDB объявил, что его версия 4.0 будет ACID-совместимой для многодокументных транзакций.
Версия 4.2. Предполагается, что поддерживать его в условиях затененных установок.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
FoundationDB был упомянут, и в то время он не был открытым исходным кодом. Это было открыто от Apple два дня назад: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Я считаю, что это совместимо с кислотой.
Чтобы добавить в список альтернатив, еще полностью ACID совместимых баз данных NoSQL является GT.M .
Hyperdex Warp http://hyperdex.org/warp/ Warp (функция ACID) является частной, но Hyperdex бесплатен.
db4o
В отличие от постоянного сохранения или сериализации, db4o безопасен для транзакций ACID и позволяет запрашивать, реплицировать и изменять схемы во время выполнения
Tarantool - это полностью ACID база данных NoSQL. Вы можете выполнять операции CRUD или хранимые процедуры, все будет выполняться в строгом соответствии со свойством ACID. Вы также можете прочитать об этом здесь: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogic также совместим с ACID. Я думаю, что это один из крупнейших игроков сейчас.
Ждать окончено
ACID-совместимая NoSQL DB вышла ----------- взгляните на citrusleaf
BergDB - это легковесная база данных NoSQL с открытым исходным кодом, разработанная с самого начала для выполнения транзакций ACID. На самом деле BergDB является «более» ACID, чем большинство баз данных SQL, в том смысле, что единственный способ изменить состояние базы данных - запустить транзакции ACID с самым высоким уровнем изоляции (термин SQL: «сериализуемый»). Никогда не будет проблем с грязным чтением, неповторяющимся чтением или фантомным чтением.
На мой взгляд, база данных по-прежнему высокоэффективна; но не верьте мне, я создал программное обеспечение. Попробуйте сами.
Многие современные NoSQL-решения не поддерживают транзакции ACID (атомарные изолированные многоключевые обновления), но большинство из них поддерживают примитивы, которые позволяют реализовывать транзакции на уровне приложений.
Если хранилище данных поддерживает линеаризуемость по каждому ключу и сравнение-и-набор (атомарность на уровне документа), то достаточно реализовать транзакции на стороне клиента, более того, у вас есть несколько вариантов на выбор:
Если вам нужен Serializable уровень изоляции, то вы можете следовать тому же алгоритму, который Google использует для системы Percolator или Cockroach Labs для CockroachDB . Я написал об этом в блоге и создаю пошаговую визуализацию , надеюсь, она поможет вам понять основную идею алгоритма.
Если вы ожидаете высокого уровня конкуренции, но для вас нормально иметь уровень изоляции Read Committed, пожалуйста, взгляните на транзакции RAMP Питера Бэйлиса.
Третий подход заключается в использовании компенсирующих транзакций, также известных как шаблон саги. Это было описано в конце 80-х годов в статье Sagas, но стало более актуальным с появлением распределенных систем. Пожалуйста, ознакомьтесь с докладом « Применение шаблона саги» для вдохновения.
Список хранилищ данных, подходящих для транзакций на стороне клиента, включает Cassandra с облегченными транзакциями, Riak с согласованными сегментами, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB и другие.
YugaByte DB поддерживает совместимые с ACID распределенные txns, а также совместимость с Redis и CQL API на уровне запросов.
VoltDB является участником, который заявляет о соответствии ACID, и хотя он все еще использует SQL, его цели одинаковы с точки зрения масштабируемости
Узел levelUP является транзакционным и построен на leveldb https://github.com/rvagg/node-levelup#batch
DynamoDB является базой данных NoSQL и имеет транзакции ACID .
Не только NoSQL не является ACID-совместимым по дизайну. Движение NoSQL охватывает BASE (в основном доступное, мягкое состояние, возможная согласованность), который, как утверждается, является противоположностью ACID. Базу данных NoSQL часто называют базой данных с конечной последовательностью. Чтобы понять различия, вы должны углубиться в теорему CAP (она же теорема Брюера)
Посетите http://www.julianbrowne.com/article/viewer/brewers-cap-theorem