Хотя это вопрос лет ...
Короче говоря, вы можете понимать ACID как гарантию целостности / безопасности данных в любых ожидаемых обстоятельствах . Как и в обычном программировании, все головные боли возникают из-за многопоточности.
Самая большая проблема на NoSQL в основном ACI. D (долговечность) обычно является отдельной проблемой.
Если ваша БД однопоточная - так что только один пользователь может получить к ней доступ одновременно - это изначально совместимо с ACI. Но я уверен, что практически ни один сервер не может иметь такую роскошь.
Если ваша БД должна быть многопоточной - обслуживать несколько пользователей / клиентов одновременно - вам необходима транзакция, совместимая с ACI. Или вы получите молчаливое повреждение данных, а не простую потерю данных. Что намного ужаснее. Проще говоря, это то же самое с универсальным многопоточным программированием. Если у вас нет надлежащего механизма, такого как блокировка, вы получите неопределенные данные. И механизм в БД называется полностью ACID-соответствием .
Многие базы данных YesSQL / NoSQL объявляют себя ACID-совместимыми, но на самом деле очень немногие из них действительно делают.
Нет соответствия ACID = Вы всегда получите неопределенный результат в многопользовательской (клиентской) среде. Я даже не думаю, что это за DB.
Соответствует одной строке / ключу ACID = Вы получите гарантированный результат, если измените только одно значение за один раз. Но неопределенный результат (= повреждение данных без вывода сообщений) для одновременного обновления нескольких строк / ключей. Большинство популярных в настоящее время БД NoSQL, включая Cassandra, MongoDB, CouchDB,… Такие БД безопасны только для однострочных транзакций. Таким образом, вы должны гарантировать, что логика вашей БД не будет касаться нескольких строк в транзакции.
Многострочная / ключевая совместимость с ACID = Вы всегда получите гарантированный результат для любой операции. Это минимальные требования в качестве СУБД. В области NoSQL очень немногие из них делают это. Spanner, MarkLogic, VoltDB, FoundationDB. Я даже не уверен, что есть больше решений. Такие БД действительно свежие и новые, поэтому в основном ничего не известно об их возможностях или ограничениях.
Во всяком случае, это сравнение, кроме D (Urability). Так что не забудьте проверить атрибут долговечности тоже. Очень трудно сравнивать долговечность, потому что диапазон становится слишком широким. Я плохо знаю эту тему ...
Нет долговечности. Вы потеряете данные в любое время.
Безопасно хранится на диске. Когда вы получаете COMMIT OK, то данные на диске гарантированы. Вы потеряли данные, если диск сломался.
Кроме того, есть разница даже в ACID-совместимых БД.
Иногда совместим с ACID / вам нужна конфигурация / нет чего-то автоматического .. / некоторые компоненты не совместимы с ACID / очень быстрые, но вам нужно что-то отключить для этого ... / совместим с ACID, если вы используете определенный модуль ... = мы не будет связывать безопасность данных по умолчанию. Это дополнение, опция или отдельно продаются. Не забудьте скачать, собрать, настроить и выдать соответствующую команду. В любом случае, безопасность данных может быть проигнорирована в молчании. Сделай сам. Проверьте это сами. Удачи, чтобы не ошибиться. Каждый в вашей команде должен быть безупречным администратором баз данных, чтобы безопасно использовать этот тип баз данных. MySQL.
Всегда совместим с ACID = Мы не обмениваем безопасность данных с производительностью или чем-либо еще. Безопасность данных - это обязательный пакет с этим пакетом БД. Наиболее коммерческие СУБД, PostgreSQL.
Выше приведена типичная реализация БД. Но, тем не менее, любой другой сбой оборудования может повредить базу данных. Например, ошибка памяти, ошибка канала данных или любые другие возможные ошибки. Таким образом, вам необходима дополнительная избыточность, а база данных реального качества производства должна обеспечивать отказоустойчивость.
Нет избыточности. Вы потеряете все данные, если ваши данные повреждены.
Резервный. Вы делаете копию снимка / восстановление. Вы теряете данные после последнего резервного копирования.
Резервное копирование онлайн. Вы можете сделать резервную копию снимка во время работы базы данных.
Асинхронная репликация. Резервное копирование на каждую секунду (или указанный период). Если машина не работает, эта БД гарантированно вернет данные, просто перезагрузившись. Вы теряете данные после последней секунды.
Синхронная репликация. Резервное копирование сразу для каждого обновления данных. У вас всегда есть точная копия оригинальных данных. Используйте копию, если происхождение сломано.
До сих пор я вижу, что многим реализациям БД не хватает многих из них. И я думаю, что если им не хватает надлежащей поддержки ACID и избыточности, пользователи со временем потеряют данные.