Блог

Извините за невежественный вопрос, но для каких приложений не требуется сервер базы данных, совместимый с ACID? У меня есть опыт работы с SQL Server, где ACID всегда «был там», и теперь изучение других СУБД заставляет меня задуматься. Почти каждое приложение, о котором я могу думать, желало бы либо атомарности, либо изоляции. Спасибо!

Чего, по-видимому, не хватает в других ответах, так это того, что общеприменимая альтернатива ACID — это не «ничего», это нечто, называемое окончательной согласованностью (иногда называемое BASE).

Когда люди говорят, что им нужна семантика ACID, часто то, что они на самом деле имеют в виду, по крайней мере, с точки зрения требований домена / бизнеса, — это просто целостность данных. Они хотят убедиться, что данные не будут потеряны или повреждены. Многие базы данных NoSQL по-прежнему предоставляют эту гарантию, просто они предоставляют ее другим способом и на своих собственных условиях.

Безусловно, можно использовать базу данных NoSQL или BASE в качестве небезопасной альтернативы базе данных SQL или ACID, если вы относитесь к ней просто как к «базе данных без ACID». Принятие обоснованного решения означает, что вы понимаете, что должно быть сделано на уровне приложения, чтобы компенсировать нехватку крупнозернистых транзакций и использовать сильные стороны EC. Некоторые распространенные методы:

• Оптимистичный параллелизм, который уже используется для минимизации блокировки в транзакционной среде.

• Идемпотентность операций, такая, что если длительная операция завершается неудачей на полпути, ее можно просто повторять снова и снова, пока она не завершится успешно.

• Методы длительных транзакций, использующие компенсирующие транзакции, часто называемые sagas в распределенных системах, где множество независимых транзакций группируются по некоторому идентификатору корреляции и состояние всей операции отслеживается независимо. Часто они фактически используют семантику ACID для самого состояния saga, но это намного легче, чем двухфазная фиксация.

На самом деле, если вы проводите много времени, работая над распределенными системами — даже теми, с семантикой ACID, доступной в каждой из отдельных подсистем, — вы обнаружите, что многие из этих же методов используются для управления межсистемными операциями, потому что без них вы просто снижаете производительность (вспомните BizTalk и BPEL).

Как только у вас появится некоторый опыт работы с этим, вы поймете, что на самом деле это имеет большой смысл и часто проще, чем пытаться применить семантику ACID. Вычислительные процессы — это всего лишь модели реальных процессов, а реальные процессы иногда могут завершаться сбоем в середине потока. Вы забронировали рейс, но внезапно вы больше не можете лететь. Что вы делаете? Вы отменяете. Может быть, вы получите свои деньги обратно, может быть, нет, или, может быть, это что-то среднее — таковы ваши бизнес-правила. Или, может быть, вы начали бронирование, но отвлеклись, или у вас отключилось питание, и теперь время ожидания вашего сеанса истекло. Что вы делаете? Все просто, вы начинаете сначала.

Чтобы действительно ответить на вопрос напрямую, я бы ответил так:

Вам нужна семантика ACID, когда:

• Вы можете разумно ожидать, что несколько пользователей или процессов будут работать с одними и теми же данными в одно и то же время.

• Порядок, в котором отображаются транзакции, чрезвычайно важен;

• Вы никогда не сможете допустить, чтобы устаревшие данные отображались пользователю.

• Незавершенные транзакции сопряжены со значительными и / или прямыми издержками (например, в финансовой системе, где несбалансированные итоговые данные могут иметь серьезные последствия).

С другой стороны, вам не нужна семантика ACID, если:

• Пользователи, как правило, выполняют обновления только для своих личных данных или не выполняют обновления вообще (просто добавляют).

• Отсутствует неявный (определяемый бизнесом) порядок транзакций. Например, если два клиента конкурируют за последний товар на складе, для вас действительно не имеет значения, кто на самом деле его получит.

• Пользователи, как правило, находятся на одном экране в течение нескольких секунд или минут за раз, и поэтому в любом случае будут просматривать устаревшие данные (это фактически описывает большинство приложений).

• У вас есть возможность просто отказаться от незавершенных транзакций; нет никаких негативных последствий от того, что они временно или, в некоторых случаях, постоянно хранятся в базе данных.

Суть в том, что очень немногим приложениям действительно везде требуется семантика ACID. Однако многим приложениям они где-то потребуются — часто в изолированных ячейках, таких как состояние saga или очереди сообщений.

В следующий раз, когда вы будете разрабатывать новое приложение или функцию, попробуйте подумать о том, возможно ли смоделировать атомарную / изолированную «транзакцию» как асинхронную «цепочку событий» с небольшим дополнительным состоянием, чтобы связать их все вместе. В некоторых случаях ответом будет нет, но вы можете быть удивлены тем, как часто ответом будет да.

Парадокс в том, что каждый специалист по СУБД думает, что без ACID небо рухнет, но большинство специалистов по NoSQL с радостью развертывают и поддерживают приложения конечного пользователя, даже не думая «мое приложение было бы лучше с ACID». Вопреки ответу Марка Б. Базы данных NoSQL не являются базами данных, в которых обновления случайным образом теряются или данные случайным образом повреждаются. Ключевое отличие заключается в том, что в базах данных NoSQL вы можете использовать ограниченные версии atomicity amp; isolation и т.д., Но для реализации транзакций произвольной сложности требуется экспоненциальное количество усилий.

Нет причин, по которым вы не можете реализовать банковскую систему с использованием базы данных, отличной от ACID. Большинство баз данных NoSQL позволяют использовать микротранзакции, которые снимают деньги с одного счета и добавляют их на другой, с вероятностью 0% от общей суммы денег в системе, изменяющейся.

Чтобы обсудить этот вопрос в контексте реальных примеров, я опишу наше приложение. Моя компания продает программное обеспечение для средних школ, в первую очередь для составления расписаний, а также для переклички, управления отсутствием / заменой учителей, экскурсий и бронирования комнат. Наше программное обеспечение основано на разработанном собственными силами не-ACID движке базы данных под названием Mrjb (доступно только внутри компании), который имеет ограничения, типичные для баз данных NoSQL.

Примером разницы между ACID и NoSQL, имеющей отношение к конечному пользователю, является то, что если 2 пользователя попытаются отметить один и тот же рулон в одно и то же время, существует (очень) небольшая вероятность того, что конечным результатом будет комбинация данных, представленных обоими пользователями. База данных ACID гарантирует, что конечным результатом будут данные либо одного пользователя, либо другого, или, возможно, что обновление одного пользователя завершится ошибкой и вернет пользователю сообщение об ошибке.

В этом случае я не думаю, что наших пользователей будет волновать, соответствуют ли статусы «отсутствия» отдельных студентов всем обновлениям одного пользователя или сочетанию обоих, хотя они были бы обеспокоены, если бы мы присвоили статусы отсутствия, которые противоречат вводимым данным обоих пользователей. Этот пример не должен встречаться на практике, а если и встречается, то это «состояние гонки», когда, по сути, нет правильного ответа о том, какому пользователю мы верим.

В связи с нашей базой данных Mrjb был поднят вопрос о том, можем ли мы реализовать ограничения, такие как «не должно допускаться существование объекта Student без соответствующего объекта Family». (‘C’ в ‘ACID’ = согласованность). На самом деле мы можем поддерживать и поддерживаем это ограничение — еще один пример микротранзакции.

Другим примером является загрузка новой версии циклического школьного расписания (обычно 2-недельный цикл), на котором основано ежедневное расписание. Нам было бы сложно сделать эту транзакцию обновления атомарной или разрешить другим транзакциям выполняться изолированно от этого обновления. Таким образом, у нас в принципе есть выбор: либо «остановить мир» на время выполнения этой крупной транзакции, что занимает около 2 секунд, либо допустить возможность того, что учащийся распечатает расписание, содержащее комбинацию данных до обновления и после обновления (вероятно, существует окно в 100 мс, в котором это может произойти). Вариант «остановить мир», вероятно, лучший вариант, но на самом деле мы делаем последнее. Вы могли бы возразить, что смешанное расписание хуже, чем расписание с предварительным обновлением, но в обоих случаях нам нужно полагаться на то, что в школе есть процесс уведомления учащихся об изменении расписания — учащийся, работающий по устаревшему расписанию, является большой проблемой, даже если это согласованное расписание. Обратите также внимание, что учащиеся обычно просматривают свое расписание онлайн, и в этом случае проблема значительно уменьшается.

Я также написал «базу данных больших двоичных объектов на основе файловой системы» для http://brainresource.com для хранения их снимков мозга. Это важная база данных, которая не обладает свойствами ACID, хотя они используют СУБД для других данных о своих объектах.

Для справки, наша компания описана здесь:http://edval.com.au и наша технология NoSQL описана здесь (описана как техника): http://www.edval.biz/memory-resident-programming-object-databases . Было опасение, что этот пост был спамом, подставляющим нашу компанию, но я бы сказал, что (а) на заданный вопрос нельзя ответить исключительно теоретически — вам нужны реальные примеры, и (б) сокрытие любой идентифицирующей информации о продукте или технологии базы данных неуместно.

Вы платите высокую цену за семантику ACID. В случаях, когда вы управляете очень большим объемом данных и можете допускать случайные несоответствия (например, вы не переводите деньги), решения без ACID (такие как большинство решений NoSQL) могут быть предпочтительнее.

http://www.schoonerinfotech.com/solutions/general/what_is_nosql

Facebook была одной из нескольких известных компаний, которые рано пошли на этот компромисс. Фактически, они написали Cassandra как хранилище данных, более подходящее для их потребностей в данных, и Cassandra явно не поддерживает семантику ACID.

Эрик Брюер о том, почему банки являются базовыми, а не ACID — Доступность — это доход

Тема здесь

Приложения, которым нужен ACID

Все, что основано на базе данных типа NoSQL, приносит в жертву соответствие требованиям ACID в обмен на что-то, обычно скорость.

Twitter, Facebook, Reddit, Digg и т.д… все они частично основаны не на acid