Это парадокс, что каждый парень RDBMS думает, что небо упадет без ACID, но большинство парней NoSQL с радостью разворачивают и поддерживают приложения конечного пользователя, даже не думая, что «мое приложение будет лучше с ACID».
(Примечание: этот ответ аналогичен ответу на очень похожий вопрос: Какие приложения не нуждаются в ACID? )
Подавляющее большинство баз данных NoSQL обладает свойством «D» (долговечность): неожиданная потеря мощности оставит вас с подтвержденными транзакциями, которые будут очевидны в базе данных, с оговоркой, что транзакции NoSQL в некотором смысле «малы». Так что «Нет»: типичная база данных NoSQL не теряет данные.
В большинстве баз данных NoSQL вы можете использовать ограниченные версии атомарности, изоляции и т. Д., Но для реализации транзакций произвольной сложности требуется значительное количество усилий. Таким образом, нет никаких причин, по которым вы не можете внедрить банковскую систему, использующую базу данных, отличную от ACID: большинство баз данных NoSQL позволяют использовать микротранзакции, которые вычитают деньги с одного счета и добавляют его на другой, с вероятностью 0% от Общая сумма денег в системе меняется. (Однако, как контрпример, я считаю, что банковское приложение может быть , а не написано в Google AppEngine, потому что их транзакции работают только в пределах одного «сложного объекта», который будет набором банковских счетов одного пользователя).
Чтобы обсудить этот вопрос в контексте реальных примеров, я опишу наше приложение. Моя компания продает программное обеспечение для средних школ, в первую очередь, для составления расписания, а также для переклички, управления отсутствием / заменой учителей, экскурсий и бронирования номеров. Наше программное обеспечение основано на разработанном компанией механизме базы данных, не поддерживающем ACID, под названием Mrjb (доступен только внутри), который имеет ограничения, типичные для баз данных NoSQL.
Пример различия между ACID и NoSQL в отношении конечного пользователя заключается в том, что если два пользователя пытаются отметить один и тот же бросок в одно и то же время, существует (очень) небольшая вероятность того, что конечный результат будет комбинация данных, представленных обоими пользователями. База данных ACID гарантирует, что конечный результат будет либо данными одного пользователя, либо данными другого, либо, возможно, обновление одного пользователя завершится неудачно и вернет пользователю сообщение об ошибке.
В этом случае я не думаю, что нашим пользователям было бы важно заботиться о том, соответствуют ли статусы «отсутствия» отдельных учеников обновлению одного пользователя или их комбинации, хотя они будут обеспокоены, если мы присвоим статусы отсутствия, которые вопреки мнениям обоих пользователей. Этот пример не должен встречаться на практике, и если это так, то это «условие гонки», когда по существу нет правильного ответа о том, какому пользователю мы верим.
В связи с нашей базой данных Mrjb был задан вопрос о том, можем ли мы реализовать ограничения, такие как «не разрешать объекту Student существовать без соответствующего объекта Family». («C» в «ACID» = согласованность). Фактически мы можем поддерживать это ограничение - еще один пример микротранзакции.
Другой пример - загрузка новой версии школьного расписания (обычно двухнедельный цикл), на котором основано ежедневное расписание.Нам было бы трудно сделать эту транзакцию обновлением атомарной или разрешить другим транзакциям выполняться изолированно от этого обновления.Таким образом, у нас, в основном, есть выбор: «остановить мир» во время этой крупной транзакции, которая занимает около 2 секунд, или предоставить возможность студенту распечатать расписание, содержащее комбинацию данных до и после обновления (естьвероятно, окно 100 мс, в котором это может произойти).Вариант «остановить мир», вероятно, является лучшим вариантом, но на самом деле мы делаем последнее.Вы можете утверждать, что смешанное расписание хуже, чем расписание до обновления, но в обоих случаях нам нужно полагаться на то, что в школе есть процесс уведомления учеников об изменении расписания - ученик отрабатывает устаревшее расписаниеВ любом случае это большая проблема.
Для справки наша компания описана здесь: http://edval.com.au, а наша технология NoSql описана здесь (описана как методика): http://www.edval.biz/memory-resident-programming-object-databases.