Какие приложения не нуждаются в ACID?

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

Twitter, Facebook, Reddit, Digg и т. д. — все они частично не основаны на кислоте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эрик Брюэр о том, почему банки являются БАЗОВЫМИ, а не КИСЛОТНЫМИ – Доступность – это доход

Тема здесь

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