При каких обстоятельствах сопровождение сделки не так важно?

Question

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

Поэтому мне интересно, при каких обстоятельствах транзакции не так важны, чтобы масштабируемость была более предпочтительной, чем поддержка транзакций?

Answer 1

Ну, во-первых, я бы сказал, что NoSQL лучше масштабирует в некоторых ситуациях, но не во всех.

Полные транзакции ACID являются атомарными, последовательными, изолированными и надежными. Если вы потеряете транзакции, вы потеряете часть или всю ACID в хранилище данных.

Есть много способов восстановить эти функции с помощью других асинхронных систем, таких как очереди сообщений, которые сами по себе долговечны. Вы можете помещать данные в надежную очередь сообщений, извлекать данные и обрабатывать их в своем NoSQL, а затем, когда вы сможете подтвердить, что они сохранены до требуемого минимума, вы можете пометить сообщение как использованное. Это D в ACID, но распределенный и асинхронный. Существуют способы обеспечить других, но они часто приносятся в жертву в некоторой степени или перемещаются в другое место в системе. С некоторыми решениями NoSQL вам просто нужно перенести согласованность в приложение, чтобы оно не пыталось хранить недействительные данные.

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

Практически нет ситуаций, когда транзакции и ограничения не важны в системе, которая имеет требования как для чтения, так и для записи. Если бы это было не так, вы бы вообще не заботились о своих данных (а некоторые люди не заботятся об этом, но сожалеют об этом позже). Однако существуют уровни «заботы». Это просто вопрос того, как вы оказались в ACID или в псевдо-ACID, который «достаточно хорош». RDMBS делает заботу о ваших данных дешевой. NoSQL делает заботу о ваших данных дорогостоящей, но делает масштабирование дешевым (в некоторых случаях). В РСУБД существует много компаний с многотерабайтной базой данных, поэтому в одностороннем порядке сказать, что «они не масштабируются», просто неточно. Однако многотерабайтные базы данных SQL могут стоить много денег, в зависимости от варианта использования (в конце концов, вы можете просто подключить массив RAID 10 с несколькими дисками по 3 ТБ к компьютеру и запустить на нем механизм базы данных. Может потребоваться несколько минут, чтобы несколько часов, чтобы выполнить любой вид сканирования таблицы на большой таблице или даже индексированный поиск, но если вам все равно, это дешево и несколько терабайт).

Answer 2

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

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

Так что вместо этого или закажите это, зарядите мою карту и покажите мне мой текущий баланс.

Вы пытаетесь заказать это, если заряд моей карты есть на складе, и если моя карта получает текущийИзвестный баланс будет таким.Существует риск того, что заказ будет размещен, оплата не удастся, поэтому с этим нужно разобраться.Существует риск того, что предлагаемый баланс карты может быть не совсем точным, поэтому добавьте слова ласки и покажите потенциальный эффект платежа, а не результат.

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

Answer 3

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

То есть «Я хочу заказать один виджет, зарядить мою кредитную карту» должно бытьправильная транзакция: я не хочу, чтобы моя карта была списана, если виджет не заказан, а поставщик не хочет, чтобы виджет был отправлен, если карта не будет снята.«Отчет о статусе отправки заказа xyz» не обязательно должен быть транзакционным - если я не получу ответ, я могу нажать «перезагрузить».