Как далеко вы действительно можете зайти с «возможной» последовательностью и без транзакций (также известной как SimpleDB)?

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Ничто из этого не означает стук в SimpleDB; возьмите его у автора программного обеспечения : «Хотя это отличный инструмент обучения, я не могу себе представить, что кто-то захочет использовать его для чего-то другого».