В настоящее время я оцениваю базы данных для использования в новом проекте, который потребует вставки и запроса больших объемов торговых данных. Наша команда склоняется к Кассандре, но затем я прочитал эту статью, в которой, кажется, предлагается использовать базы данных, не совместимые с ACID, которые могут привести к случайной потере данных:
http://www.dbms2.com/2010/09/21/acid-compliant-transaction-integrity/
Я не могу найти дополнительную информацию по этому вопросу в Интернете и не могу понять, как не-ACID соответствие означает, что может произойти потеря данных. Кто-нибудь может пролить свет?
Ответы:
Кислотные средства
Для вас это означает, что «каждое действие записи будет выполнено только один раз (без дублирующихся записей), но будет полностью сохранено в базе данных после выполнения действия», и что каждый раз, когда вы читаете, вы получаете нужные данные. ,
Суть баз данных NoSQL в том, что они часто распределяются (это то, что люди хотят, плоские масштабируемые системы, которые дешевы), а это означает, что для репликации данных на все узлы требуется время. Иногда можно читать во время записи и получать старые данные, когда поступают новые данные.
Вы жертвуете чистотой ради скорости.
Это краткая версия моего ответа, и я не уверен, что мне нужно объяснять дальше. Спроси меня!
источник
Хотя это вопрос лет ...
Короче говоря, вы можете понимать 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 и избыточности, пользователи со временем потеряют данные.
источник
«Это зависит», - ответ - есть варианты конфигурации, упомянутые здесь .
Небольшой придирка: база данных может быть надежной, но не совместимой с ACID, поскольку ACID - это расширенный набор функций (ACID). Я не думаю, что какая-либо база данных NoSQL может претендовать на то, чтобы быть полностью ACID, но многие из них могут претендовать на то, чтобы соответствовать индивидуальным суб-требованиям, таким как долговечность.
источник