Классика баз данных - статьи
что уровень согласованности должен быть
В [3] утверждается, что уровень согласованности должен быть гибким, и что должен существовать компромисс между объемом расходов и согласованностью данных. Кроме того, в [16] и [3] приводятся доводы в пользу применения при разработке крупномасштабных распределенных систем определения уровней согласованности в духе предложений [15], а не определений, содержащихся в стандарте языка SQL и реализуемых в коммерческих системах баз данных текущего поколения. Опять же, эта точка зрения диктуется важностью SOA как принципа разработки.
Требование стопроцентной доступности данных по чтению и записи для всех пользователей также отодвигает на задний план важность парадигмы ACID как золотого стандарта согласованности данных. В крупных Web-приложениях (например, Amazon, eBay, expedia и т.д.) не допускается блокировка ни одного пользователя; в частности, ни один пользователь не может быть блокирован из-за действий какого-либо другого пользователя. И это требование также более приоритетно, чем достижение строгой согласованности. В результате оказывается лучше разрабатывать систему, которая умеет обращаться с несогласованными данными и помогает устранять их несогласованность, чем систему, которая предотвращает несогласованность в любых ситуациях. Неприятности случаются и при использовании ACID, и игнорирование этих соображений ограничивает возможности системы. В результате в современных IT-системах согласованность данных является целью оптимизации, а не ограничением, как в традиционных системах баз данных.
Гибкость. Гибкость – это возможность настройки программной системы к индивидуальным требованиям пользователя. Гибкость также облегчает, ускоряет и удешевляет выпуск новых версий системы. Таким образом, гибкость системы измеряется числом ее внедренных вариантов. Гибкость особенно важна для приложений с разнотипным контингентом пользователей; типичными примерами являются корпоративные приложения, такие как SAP R/3 и Oracle Finance. По мере усложения приложений гибкость как цель разработки становится все более важной.На важность этого требования, в частности, указывает успех технологии AppExchange компании Salesforce. В традиционных системах OLTP, таких как системы поддержки кредитных и дебетовых транзакций 1970-х, это требование отсутствовало, так что гибкость не являлась настоятельной целью оптимизации в традиционных системах управления данными. Очевидно, что гораздо проще обеспечить должные производительность и масштабируемость, если система не обладает гибкостью.
