Я опубликую это как ответ исключительно для поддержки разговора - Тим Махи , Наврот и КрэйгТП предложили жизнеспособные базы данных. CouchDB будет моим предпочтением из-за использования Erlang , но есть и другие.
Я бы сказал, что ACID не противоречит и не отрицает концепцию NoSQL ... Хотя после мнения, высказанного голубем , кажется, что существует тенденция , я бы сказал, что эти концепции различны.
В основе NoSQL лежит простая схема ключ-значение (например, Redis) или схема в стиле документа (собранные пары ключ-значение в модели «документ», например MongoDB) как прямая альтернатива явной схеме в классических РСУБД. Это позволяет разработчику обрабатывать вещи асимметрично, в то время как традиционные механизмы применяют жесткое единообразие в модели данных. Причина, по которой это так интересно, заключается в том, что он предоставляет другой способ работы с изменениями , а для больших наборов данных - интересные возможности для работы с объемами и производительностью.
ACID содержит принципы , регулирующие как изменения применяются к базе данных. В очень упрощенном виде говорится: (моя собственная версия):
(A) когда вы что-то делаете для изменения базы данных, изменение должно сработать или потерпеть неудачу в целом
(C) база данных должна оставаться согласованной (это довольно широкая тема)
(I), если другие вещи происходят одновременно, они не должны видеть вещи в середине обновления.
(D) если система взрывается (аппаратная или программная), база данных должна быть в состоянии восстановить себя; и если он говорит, что завершил применение обновления, он должен быть уверен
Разговор становится немного более возбуждающим, когда дело доходит до идеи распространения и ограничений . Некоторые ядра СУБД предоставляют возможность применять ограничения (например, внешние ключи), которые могут иметь элементы распространения (в виде каскада ). Проще говоря, одна «вещь» может иметь связь с другой «вещью» в базе данных, и если вы измените атрибут одного, это может потребовать изменения другого (обновлено, удалено, ... много вариантов). Базы данных NoSQL , в основном (на данный момент) ориентированные на большие объемы данных и большой трафик, похоже, занимаются идеей распределенных обновлений, которые происходят в (с точки зрения потребителя) произвольных временных рамок. Это в основном специализированная форма репликации, управляемая черезтранзакция - так что я бы сказал, что если традиционная распределенная база данных может поддерживать ACID, то и база данных NoSQL.
Хороший ответ. Вы можете иметь как NoSQL + ACID, так и не-ACID-RDBMS (например, MySQL + MyISAM). Обычно я рассматриваю NoSQL как «в конечном итоге непротиворечивый». Я также добавлю теорему CAP ... :-)
gbn
+1 @gbn за упоминание теоремы CAP. Быть более знакомым с dos "nosql" сейчас, чем я тогда, только усилило разделение понятий. Кроме того, ключ-значение по сравнению с базами данных doc, поскольку есть архитектурные различия.
ОБНОВЛЕНИЕ (27 июля 2012 г.): ссылка на статью в Википедии была обновлена, чтобы отразить версию статьи, которая была актуальной на момент публикации этого ответа. Обратите внимание, что текущая статья в Википедии была значительно переработана!
NoSQL - это движение, продвигающее слабо определенный класс нереляционных хранилищ данных, которые ломаются от долгой истории реляционных баз данных и гарантий ACID.
а также:
Название было попыткой описать появление растущего числа нереляционных распределенных хранилищ данных, которые часто не пытались предоставить гарантии ACID.
и
Системы NoSQL часто предоставляют слабые гарантии согласованности, такие как возможная согласованность и транзакции, ограниченные отдельными элементами данных, даже если можно наложить полные гарантии ACID, добавив дополнительный уровень промежуточного программного обеспечения.
Так, в двух словах, я бы сказал , что один из главных преимуществ «NoSQL» хранилище данных является явным отсутствием в ACID свойств. Кроме того, ИМХО, чем больше человек пытается реализовать и применять свойства ACID , тем дальше от «духа» хранилища данных «NoSQL» вы получаете, и тем ближе к «истинной» СУБД вы получаете (условно говоря, конечно, ).
Однако все, что говорит «NoSQL», является очень расплывчатым термином и открыто для индивидуальных интерпретаций, и в значительной степени зависит от того, насколько сильно вы придерживаетесь пуристской точки зрения. К примеру, самый современный RDBMS системы фактически не придерживаются все из Кодд «s 12 правил его реляционной модели !
Принимая прагматичный подход, создается впечатление, что CouchDB Apache наиболее близок к воплощению соответствия ACID, сохраняя при этом слабосвязанный нереляционный менталитет «NoSQL».
+1 Я не уверен, что согласен с тем, что ACID является ключевой характеристикой «NoSQL», но я действительно ценю вашу рецензию. В конечном счете, это должно быть решение, которое подходит.
AJ.
2
Я отредактировал (в ожидании обзора), чтобы попытаться сделать еще более ясным. В моделях данных NoSQL нет ничего, что подразумевало бы невозможность транзакций ACID. Некоторые распределенные системы NoSQL не имеют их. Некоторые на самом деле обходятся без какого-либо «промежуточного слоя».
Эрик Блох
2
Это никогда не было правильным и даже потеряло его источник. Это действительно должно быть удалено.
Леннарт Регебро
2
Ну, самое очевидное, это: «в двух словах, я бы сказал, что одним из основных преимуществ хранилища данных« NoSQL »является его явное отсутствие свойств ACID». Вы также подразумеваете, что NoSQL и ACID так или иначе являются взаимоисключающими, что, безусловно, неверно. Это хороший пример того, как большое количество невежественных людей высказывают неправильный ответ, потому что это звучит разумно. То, что большинство баз данных NoSQL не совместимы с ACID, объясняется главным образом тем, что люди, реализовавшие его, не знали, что это было / почему это важно / не заботились.
Леннарт Регебро
@LennartRegebro - я не подразумевал ничего подобного. Соответствие ACID действительно игнорировалось большинством существующих существующих баз данных NoSQL в пользу скорости / производительности и возможной согласованности. Я никогда не говорил, что у вас не может быть NoSQL с ACID-совместимостью.
Прежде всего, мы можем выделить два типа баз данных NoSQL:
Агрегатно-ориентированные базы данных;
Графо-ориентированные базы данных (например, Neo4J).
По своей структуре большинство графо-ориентированных баз данных являются ACID !
Тогда как насчет других типов?
В агрегатно-ориентированные базы данных мы можем поместить три подтипа:
Базы данных NoSQL на основе документов (например, MongoDB, CouchDB);
Базы данных Key / Value NoSQL (например, Redis);
Базы данных NoSQL семейства столбцов (например, Hibase, Cassandra).
То, что мы здесь называем Агрегатом , - это то, что Эрик Эванс определил в своем доменно-управляемом дизайне как самодостаточный для сущностей и объектов-ценностей в данном ограниченном контексте.
Как следствие, агрегат - это набор данных, с которыми мы взаимодействуем как единое целое. Агрегаты образуют границы для операций ACID с базой данных. (Мартин Фаулер)
Итак, на уровне Aggregate мы можем сказать, что большинство баз данных NoSQL могут быть такими же безопасными, как и СУБД ACID , с соответствующими настройками. Исходя из этого, если вы настроите свой сервер на лучшую скорость, вы можете столкнуться с чем-то не-ACID. Но репликация поможет.
Главное, что вы должны использовать базы данных NoSQL как есть, а не как (дешевую) альтернативу СУБД. Я видел слишком много проектов, злоупотребляющих отношениями между документами. Это не может быть кислотой. Если вы остаетесь на уровне документа, то есть на агрегированных границах, вам не нужна транзакция. И ваши данные будут в такой же безопасности, как и в базе данных ACID, даже если они не являются действительно ACID, поскольку вам не нужны эти транзакции! Если вам нужны транзакции и обновление нескольких «документов» одновременно, вы больше не находитесь в мире NoSQL - так что используйте вместо этого движок СУБД!
некоторые обновления 2019 года: начиная с версии 4.0, для ситуаций, когда требуется атомарность для обновлений нескольких документов или согласованность между чтениями нескольких документов, MongoDB обеспечивает транзакции с несколькими документами для наборов реплик .
Есть случаи, когда есть большой процесс / сага, которая обрабатывает много агрегатов. Существуют случаи, когда команда, отправляемая в агрегат, может вызывать некоторые события, которые изменяют другие агрегаты. В этих случаях вам нужны ACID-совместимые хранилища данных.
Тудор
1
@TudorTudor, но в этом случае вы нарушаете один из принципов nosql, поскольку вы используете его как rdbms. Вам просто нужно больше агрегатов или версий документов (как в couchdb). Документально-ориентированные БД Nosql являются кислотными на границах документов / агрегатов.
Арно Бушез
Ни один из тех, кого вы перечисляете, не соответствует кислоте. Монго просто не соответствует требованиям ACID. CouchDB делает вид, что соответствует кислоте, если вы не обновляете два документа. Redis имеет только «частичную поддержку транзакций». HBase прямо не соответствует кислотам (от разработчиков) , как и Cassandra. Этот ответ на самом деле просто неверен. Ни одна из этих баз данных не поддерживает ACID, и большинство из них открыто владеют им с помощью простого поиска в Google.
Эван Кэрролл,
@EvanCarroll Я никогда не писал, что MongoDB совместим с ACID, в том же смысле, что и с транзакцией СУБД ACID. Нет доступных транзакций. Я написал, что большинство баз данных NoSQL могут быть такими же безопасными, как СУБД ACID, с правильными настройками . Например, проверьте $ изолированный оператор MongoDB для БД без какого-либо общего кластера. Я бы никогда не использовал MongoDB для финансового процесса, но я мог бы доверять его процессу записи в некоторой степени, для ACID-подобных операций, если достаточно A для атомарности. Извините, если мой ответ сбивает с толку.
Он имеет правильные транзакции, поэтому вы можете обновлять несколько разнородных элементов данных в режиме ACID. Это используется в качестве основы для поддержания индексов на более высоком уровне.
к сожалению, это не с открытым исходным кодом. Но это выглядит как очень хорошая база данных.
Кевин Кокс
Чтобы добавить к ответу @ Ken-Tindell, djondb также является NoSQL и реализует транзакции и совместима с ACID. djondb.com Я согласен, что NoSQL - это просто термин для обозначения всех баз данных, который не следует традиционным правилам СУБД, это не означает «избавиться от систем TX» или забыть об отношениях.
Крест
3
Мой ответ был спорным после приобретения Apple Foundation DB.
Кен Тинделл,
1
foundationdb теперь открытые источники от Apple
RBanerjee
17
В этом вопросе кто-то должен упомянуть OrientDB : OrientDB - это база данных NoSQL, одна из немногих, которая полностью поддерживает транзакции ACID. ACID не только для RDBMS, потому что он не является частью реляционной алгебры. Таким образом, возможно иметь базу данных NoSQL, поддерживающую ACID.
ACID и NoSQL полностью ортогональны. Одно не подразумевает другого.
У меня есть тетрадь на столе, я использую ее, чтобы вести записи о том, что мне еще предстоит сделать. Этот блокнот является базой данных NoSQL. Я запрашиваю его, используя линейный поиск с «кешем страниц», поэтому мне не всегда приходится искать каждую страницу. Он также совместим с ACID, так как я гарантирую, что я пишу только одну вещь за раз, а не во время чтения.
NoSQL просто означает, что это не SQL. Многие люди сбиты с толку и думают, что это означает очень масштабируемое хранение на диком западе и сверхбыстрое хранение. Это не так. Это не означает сохранение значения ключа или возможную согласованность. Все это означает "не SQL", на этой планете много баз данных, и большинство из них не являются SQL [необходима цитата] .
Вы можете найти много примеров в других ответах, поэтому мне не нужно перечислять их здесь, но есть базы данных, отличные от SQL, с ACID-соответствием для различных операций, некоторые являются ACID только для записи одного объекта, а некоторые гарантируют гораздо больше. Каждая база данных отличается.
Просто чтобы быть педантичным, но обычно это означает «Не только SQL» :-)
shmish111
4
@ шмиш111 не совсем. Это означало «нет SQL», когда термин был впервые введен. Буква «о» маленькая, а не заглавная. Позже были попытки изменить термин «не только SQL», когда некоторые из них (продукты NoSQL) начали добавлять интерфейсы языка запросов, подобные SQL.
ypercubeᵀᴹ
11
«NoSQL» не является четко определенным термином. Это очень расплывчатая концепция. Таким образом, даже невозможно сказать, что является продуктом NoSQL, а что нет. Не почти все продукты, типично маркированные лейблом, являются магазинами ключевой стоимости.
Лучший ответ. Когда бы ни возникала эта пламенная война, я хотел бы спросить другую сторону, какие определяющие функции они явно требуют от базы данных NoSQL, и часто она пересекается с функциями, которые они могут найти в СУБД, - не потому, что одна или СУБД соответствуют теме NoSQL, а просто потому, что их «требования» к функциям настолько расплывчаты, что они не отменяют полностью функции, обнаруживаемые (не обязательно) в RDMBS. +1 за ваш комментарий приятель!
StartupGuy
8
Да, MarkLogic Server - это решение NoSQL (мне нравится называть базу данных документов), которое работает с ACID-транзакциями.
MarkLogic имеет транзакции ACID, транзакции с несколькими документами, транзакции с несколькими выписками и поддержку XA - все в кластере / распределенные.
Для тех, кто хочет перейти с библиотеки «полки» в python, я обнаружил, что ZODB почти не имеет смысла. Мне не нужно было переписывать все мои функции - просто получите доступ к ZODB как словарь, как полка, но это на порядок быстрее.
Майкл Гэлакси
8
Как один из создателей 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]
Да, транзакции ACID с несколькими документами теперь поддерживаются в MongoDB. См. Mongodb.com/transactions для получения дополнительной информации и подробного видео о том, как они были реализованы.
В отличие от постоянного сохранения или сериализации, db4o безопасен для транзакций ACID и позволяет запрашивать, реплицировать и изменять схемы во время выполнения
Tarantool - это полностью ACID база данных NoSQL. Вы можете выполнять операции CRUD или хранимые процедуры, все будет выполняться в строгом соответствии со свойством ACID. Вы также можете прочитать об этом здесь: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
Поддерживает ли Aerospike многоключевую транзакцию ACID? AKAIK ограничивается транзакцией с одним ключом.
Эонил
1
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 и другие.
Создатель VoltDB упомянул, что они не обозначают себя как NoSql, но больше похожи на NewSql (все еще используют Sql, но с лучшей реализацией, чем те RDBM, построенные в восьмидесятых годах)
Мэтт W
0
Хотя это всего лишь встроенный механизм, а не сервер, leveldb имеет WriteBatch и возможность включать синхронную запись для обеспечения поведения ACID.
Не только NoSQL не является ACID-совместимым по дизайну. Движение NoSQL охватывает BASE (в основном доступное, мягкое состояние, возможная согласованность), который, как утверждается, является противоположностью ACID. Базу данных NoSQL часто называют базой данных с конечной последовательностью. Чтобы понять различия, вы должны углубиться в теорему CAP (она же теорема Брюера)
Я думаю, что указатель на теорему CAP очень актуален для этого вопроса!
mxro
2
Некоторые базы данных NoSQL имеют транзакции ACID.
Эрик Блох
1
Некоторые noSQL утверждают, что они совместимы с ACID, но когда вы углубляетесь в себя, вы обнаруживаете, что только в некоторых особых случаях они являются ACID, поэтому, ИМХО, поскольку «в конечном итоге ACID» нет, они определенно не ACID
Ste
1
Вы в корне неправильно используете CAP. CAP и ACID в лучшем случае слабо связаны, но CAP не препятствует совместимости ACID с распределенной системой. CAP описывает необходимые компромиссы распределенной системы - система NoSQL, которая строго согласована, может быть недоступна во время раздела, но это не мешает ей быть ACID-совместимым.
Ответы:
Я опубликую это как ответ исключительно для поддержки разговора - Тим Махи , Наврот и КрэйгТП предложили жизнеспособные базы данных. CouchDB будет моим предпочтением из-за использования Erlang , но есть и другие.
Я бы сказал, что ACID не противоречит и не отрицает концепцию NoSQL ... Хотя после мнения, высказанного голубем , кажется, что существует тенденция , я бы сказал, что эти концепции различны.
В основе NoSQL лежит простая схема ключ-значение (например, Redis) или схема в стиле документа (собранные пары ключ-значение в модели «документ», например MongoDB) как прямая альтернатива явной схеме в классических РСУБД. Это позволяет разработчику обрабатывать вещи асимметрично, в то время как традиционные механизмы применяют жесткое единообразие в модели данных. Причина, по которой это так интересно, заключается в том, что он предоставляет другой способ работы с изменениями , а для больших наборов данных - интересные возможности для работы с объемами и производительностью.
ACID содержит принципы , регулирующие как изменения применяются к базе данных. В очень упрощенном виде говорится: (моя собственная версия):
Разговор становится немного более возбуждающим, когда дело доходит до идеи распространения и ограничений . Некоторые ядра СУБД предоставляют возможность применять ограничения (например, внешние ключи), которые могут иметь элементы распространения (в виде каскада ). Проще говоря, одна «вещь» может иметь связь с другой «вещью» в базе данных, и если вы измените атрибут одного, это может потребовать изменения другого (обновлено, удалено, ... много вариантов). Базы данных NoSQL , в основном (на данный момент) ориентированные на большие объемы данных и большой трафик, похоже, занимаются идеей распределенных обновлений, которые происходят в (с точки зрения потребителя) произвольных временных рамок. Это в основном специализированная форма репликации, управляемая черезтранзакция - так что я бы сказал, что если традиционная распределенная база данных может поддерживать ACID, то и база данных NoSQL.
Некоторые ресурсы для дальнейшего чтения:
источник
ОБНОВЛЕНИЕ (27 июля 2012 г.): ссылка на статью в Википедии была обновлена, чтобы отразить версию статьи, которая была актуальной на момент публикации этого ответа. Обратите внимание, что текущая статья в Википедии была значительно переработана!
Ну, согласно старой версии статьи в Википедии о NoSQL :
а также:
и
Так, в двух словах, я бы сказал , что один из главных преимуществ «NoSQL» хранилище данных является явным отсутствием в ACID свойств. Кроме того, ИМХО, чем больше человек пытается реализовать и применять свойства ACID , тем дальше от «духа» хранилища данных «NoSQL» вы получаете, и тем ближе к «истинной» СУБД вы получаете (условно говоря, конечно, ).
Однако все, что говорит «NoSQL», является очень расплывчатым термином и открыто для индивидуальных интерпретаций, и в значительной степени зависит от того, насколько сильно вы придерживаетесь пуристской точки зрения. К примеру, самый современный RDBMS системы фактически не придерживаются все из Кодд «s 12 правил его реляционной модели !
Принимая прагматичный подход, создается впечатление, что CouchDB Apache наиболее близок к воплощению соответствия ACID, сохраняя при этом слабосвязанный нереляционный менталитет «NoSQL».
источник
Пожалуйста , прочитайте введение Мартина Фаулера о базах данных NoSQL . И соответствующее видео.
Прежде всего, мы можем выделить два типа баз данных NoSQL:
По своей структуре большинство графо-ориентированных баз данных являются ACID !
Тогда как насчет других типов?
В агрегатно-ориентированные базы данных мы можем поместить три подтипа:
То, что мы здесь называем Агрегатом , - это то, что Эрик Эванс определил в своем доменно-управляемом дизайне как самодостаточный для сущностей и объектов-ценностей в данном ограниченном контексте.
Итак, на уровне Aggregate мы можем сказать, что большинство баз данных NoSQL могут быть такими же безопасными, как и СУБД ACID , с соответствующими настройками. Исходя из этого, если вы настроите свой сервер на лучшую скорость, вы можете столкнуться с чем-то не-ACID. Но репликация поможет.
Главное, что вы должны использовать базы данных NoSQL как есть, а не как (дешевую) альтернативу СУБД. Я видел слишком много проектов, злоупотребляющих отношениями между документами. Это не может быть кислотой. Если вы остаетесь на уровне документа, то есть на агрегированных границах, вам не нужна транзакция. И ваши данные будут в такой же безопасности, как и в базе данных ACID, даже если они не являются действительно ACID, поскольку вам не нужны эти транзакции! Если вам нужны транзакции и обновление нескольких «документов» одновременно, вы больше не находитесь в мире NoSQL - так что используйте вместо этого движок СУБД!
некоторые обновления 2019 года: начиная с версии 4.0, для ситуаций, когда требуется атомарность для обновлений нескольких документов или согласованность между чтениями нескольких документов, MongoDB обеспечивает транзакции с несколькими документами для наборов реплик .
источник
FoundationDB совместим с кислотой:
http://www.foundationdb.com/
Он имеет правильные транзакции, поэтому вы можете обновлять несколько разнородных элементов данных в режиме 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 для хранения низкого уровня в настоящее время).
источник
NewSQL
Эту концепцию участники Википедии определяют как:
Ссылки
[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/
Я считаю, что это совместимо с кислотой.
источник
взгляните на теорему CAP
РЕДАКТИРОВАТЬ: RavenDB, кажется, совместим с кислотой
источник
Чтобы добавить в список альтернатив, еще полностью ACID совместимых баз данных NoSQL является GT.M .
источник
Hyperdex Warp http://hyperdex.org/warp/ Warp (функция ACID) является частной, но Hyperdex бесплатен.
источник
db4o
http://www.db4o.com/about/productinformation/db4o/
источник
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, его цели одинаковы с точки зрения масштабируемости
источник
Хотя это всего лишь встроенный механизм, а не сервер, leveldb имеет WriteBatch и возможность включать синхронную запись для обеспечения поведения ACID.
источник
Узел levelUP является транзакционным и построен на leveldb https://github.com/rvagg/node-levelup#batch
источник
Google Cloud Datastore - это база данных NoSQL, поддерживающая транзакции ACID
источник
DynamoDB является базой данных NoSQL и имеет транзакции ACID .
источник
Не только NoSQL не является ACID-совместимым по дизайну. Движение NoSQL охватывает BASE (в основном доступное, мягкое состояние, возможная согласованность), который, как утверждается, является противоположностью ACID. Базу данных NoSQL часто называют базой данных с конечной последовательностью. Чтобы понять различия, вы должны углубиться в теорему CAP (она же теорема Брюера)
Посетите http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
источник