Как далеко вы действительно можете пойти с & # 8220; eventual & # 8221; согласованность и отсутствие транзакций (ака SimpleDB)?

Question

Я действительно хочу использовать SimpleDB, но я волнуюсь, что без реальной блокировки и транзакций вся система имеет серьезные недостатки. Я понимаю, что для приложений с высоким уровнем чтения / низкого уровня записи это имеет смысл, поскольку в конечном итоге система становится согласованной, но что насчет этого промежутка времени? Похоже, что правильный запрос в несогласованной базе данных увековечит хаос во всей базе данных, и его очень сложно отследить. Надеюсь, я просто беспокойная бородавка ...

Answer 1

Это довольно классическая битва между согласованностью, масштабируемостью и - в некоторой степени - доступностью. Некоторые данные не всегда должны быть такими согласованными. Например, посмотрите на digg.com и количество diggs против истории. Есть большая вероятность, что значение дублируется в " digg " записывать, а не заставлять БД выполнять объединение с " user_digg " Таблица. Имеет ли значение, что это число не совсем точно? Возможно нет. Тогда можно использовать что-то вроде SimpleDB. Однако, если вы пишете банковскую систему, вы, вероятно, должны ценить последовательность превыше всего. :)

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

Я бы предпочел получить сайт с нуля и потратить несколько недель на устранение проблем с масштабированием при увеличении трафика, а затем потратить столько времени на беспокойство о масштабах, что мы никогда не доберемся до производства, потому что у нас заканчиваются деньги. :)

Answer 2

Если вы говорите о этой SimpleDB , вы не беспокойтесь; есть реальные причины не использовать ее как реальную СУБД.

Свойства, которые вы получаете от поддержки транзакций в СУБД, могут быть сокращены аббревиатурой «A.C.I.D.»: атомарность, согласованность, изоляция и долговечность. A и D в основном связаны с системными сбоями, а C и я - с обычной работой. Это все, что люди считают само собой разумеющимся при работе с коммерческими базами данных, поэтому, если вы работаете с базой данных, в которой нет ни одного, ни нескольких из них, вас может ожидать множество неприятных сюрпризов.

Атомарность . Любая транзакция будет либо полностью завершена, либо не завершена вовсе (т.е. она будет либо полностью зафиксирована, либо отменена). Это относится к отдельным операторам (таким как «таблица UPDATE ...»), а также к более длинным и сложным транзакциям. Если у вас этого нет, то все, что идет не так (как, например, переполнение диска, сбой компьютера и т. Д.), Может привести к неполным результатам. Другими словами, вы никогда не можете полагаться на СУБД, которая действительно делает то, о чем вы ей говорите, потому что на пути может возникнуть любое количество реальных проблем, и даже простой оператор UPDATE может быть частично выполнен.

Согласованность . Любые правила, установленные вами для базы данных, всегда будут применяться. Например, если у вас есть правило, которое гласит, что A всегда равно B, то никто ничего не делает с системой баз данных, чтобы нарушить это правило - он потерпит неудачу при любой попытке. Это не так важно, если весь ваш код совершенен ... но на самом деле, когда это когда-либо имело место? Кроме того, если вам не хватает этой сети безопасности, все становится очень неприятным, когда вы проигрываете ...

Изоляция . Любые действия в базе данных будут выполняться так, как если бы они происходили последовательно (по одному за раз), даже если в действительности они происходят одновременно (чередуются друг с другом). Если несколько пользователей одновременно получат доступ к этой базе данных, а у вас ее нет, то вещи, о которых вы даже не мечтали, пойдут не так; даже атомарные утверждения могут взаимодействовать друг с другом непредвиденными способами и облажаться.

Долговечность . Если вы теряете мощность или происходит сбой программного обеспечения, что происходит с транзакциями в базе данных, которые выполнялись? Если у вас есть долговечность, ответ «ничего» - все они в безопасности ». Базы данных делают это с помощью так называемого «Undo / Redo Logging», где каждая мелочь, которую вы делаете с базой данных, сначала регистрируется (обычно на отдельном диске для безопасности) таким образом, что вы можете восстановить текущее состояние после сбоя , Без этого другие свойства, приведенные выше, бесполезны, потому что вы никогда не можете быть на 100% уверены, что после сбоя все останется согласованным.

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

Также обратите внимание, что удаление всех этих средств защиты не означает, что ваша база данных будет работать лучше; на самом деле, скорее всего, наоборот. Это связано с тем, что в реальном программном обеспечении СУБД также есть тонны кода для оптимизации производительности запросов. Таким образом, если вы напишите запрос, объединяющий 6 таблиц в SimpleDB, не думайте, что он определит оптимальный способ выполнения этого запроса - вы можете закончить часами ожидания его выполнения, когда коммерческая СУБД может использовать Индексированное хеш-соединение и получить его за .5 секунд. Есть миллион маленьких хитростей