Что такое консистентность данных
Консистентность данных
Консистентность данных
Консистентность данных (англ. data consistency или data validity) — это согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость. Множество всех условий, налагаемых на данные определяется моделью (структурой) данных.
Содержание
Условия консистентности данных в ER-модели
Если данные представляют собой связанные отношениями узлы различного типа, в которых хранятся какие-то данные, то в модели данных могут быть оговорены условия: какие именно данные там могут хранится, и узлы каких типов могут быть связаны заданными в модели отношениями (связями) (см. w:en:Entity-relationship model, ER-модель данных).
Например, в базе данных людей, отношение «родитель» направленное от узла X к узлу Y подразумевает, что узел Y связан с X либо отношением «дочь» либо отношением «сын», причём это непосредственно зависит от значения атрибута «пол» узла X. Другим очевидным условием консистентности базы данных людей является требование, чтобы один узел был связан не более, чем с двумя другими узлами отношением «родитель», причём атрибут «пол» у этих узлов должен различаться.
Условия консистентности могут включать в себя указание того, какие значения могут принимать атрибуты узлов, какие отношения могут устанавливаться между узлами, каково минимальное и максимальное число отношений определённого типа, в котором может участвовать один узел, а также другие типы условий.
Консистентность в базах данных
Понятие консистентности впервые появилось в области систем управления базами данных.
Условия целостности данных (integrity constraints) стали записывать в виде правил и ввели триггеры — процедуры, которые вызывались до и после выполнения запроса. До запроса (триггер типа BEFORE) проходила проверка того, что данные имеют состояние, которое позволяет осуществить данный тип запроса. А после выполнения запроса (триггер типа AFTER) проверялось, что состояние базы данных удовлетворяет условим целостности. Если один из триггеров не срабатывал (возвращал НЕУСПЕХ или срабатывал с ошибкой), то транзакция откатывалась (отменялась).
Kонсистентность является важнейшим понятием теории управления данными (data management) и входит в четвёрку ACID (Atomicity, Consistency, Isolation, и Durability) — Атомарность, Консистентность, Замкнутость и Живучесть (стойкость).
Консистентность в теории алгоритмов и структур данных
Консистентность структуры данных в теории алгоритмов имеет важное значение.
Задачи, решаемые алгоритмистами и программистами, в большей части связаны с поиском эффективной структуры данных и реализацией механизмов поддержки её консистентности.
Например, условие консистентности двоичного дерева поиска — это возрастание ключей в узлах дерева слева направо, а именно ключ в корневом узле должен быть меньше ключей узлов правого поддерева и больше ключей узлов левого поддерева. Если в каждом узле дерева поиска хранится также указатель parent на родительский узел, то возникает дополнительное условие консистентности двоичного дерева поиска: в каждом узле X указатель на родительский узел должен указывать на такой узел, в котором ровно один из указателей на детей (left или right) указывает на узел X.
Проблема поддержки консистентности данных
Проблема поддержки консистентности данных остро стоит в задачах управления большими базами данных. Одним из способов избавится от проблем, связанных с поддержкой консистентности, является устранения дублирования информации. Одна и та же информация может быть записана с базе данных в нескольких местах (но, возможно в разном виде) или частично повторяться. Это требует синхронизации кусочков повторяющейся информации друг с другом.
С другой стороны, дублирование информации в различных местах позволяет писать более простые и эффективные алгоритмы поиска данных (алгоритмы выполнения различных запросов). При решении проблемы поддержки консистентности данных необходим разумный баланс между скоростью (сложностью алгоритмов) извлечения данных и скоростью (сложностью алгоритмов) хранения и модификации данных.
Требования ACID на простом языке
Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.
Когда речь идёт о базах данных, могут всплыть магические слова «Требования ACID». На собеседовании или в разговоре разработчиков — не суть. В этой статье я расскажу о том, что это такое, как расшифровывается ACID и что означает каждая буква.
Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?
Давайте пройдемся по каждой букве ACID и посмотрим на примерах, чем архив лучше 10 разных файлов. И чем транзакция лучше 10 отдельных запросов.
Atomicity — Атомарность
Атомарность гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем. Не допускаются промежуточные состояния.
Друг познается в беде, а база данных — в работе с ошибками. О, если бы всё всегда было хорошо и без ошибок! Тогда бы никакие ACID были бы не нужны. Но как только возникает ошибка, атомарность становится очень важна.
Допустим, вы решили отправить маме деньги. Когда вы делаете перевод внутри банка, что происходит:
У вас деньги списались
И допустим, что у нас 2 отдельных запроса. А теперь посмотрим, что будет при возникновении ошибок:
1. У вас на балансе нет нужной суммы — система вывела сообщение об ошибке, но катастрофы не произошло, атомарность тут не нужна.
2. У мамы заблокирована карточка, истек срок годности — деньги ей не поступили. Запрос отменен. Но минуточку. У вас то они уже списались!
Ошибка на первом этапе никаких проблем в себе не таит. А вот ошибка на втором. Приводит к потере денег, что явно недопустимо.
Если мы отправляем отдельные запросы, система не может связать их между собой. Запрос упал с ошибкой? Система его отменяет. Но только его, ведь она не знает о том, что запрос «у меня деньги спиши» связан с упавшим «сюда положи»!
Транзакция же позволяет сгруппировать запросы, то есть фактически показывает базе на взаимосвязи между ними. База сама о связях ничего не знает! Это знаете только вы =)
И если падает запрос внутри транзакции, база откатывает всю транзакцию. И приходит в состояние «как было до начала транзакции». Даже если там внутри было 10 запросов, вы можете спать спокойно — сломался один, откатятся все.
Consistency — Согласованность
Транзакция, достигающая своего нормального завершения (EOT — end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты wikipedia
Это свойство вытекает из предыдущего. Благодаря тому, что транзакция не допускает промежуточных результатов, база остается консистентной. Есть такое определение транзакции: «Упорядоченное множество операций, переводящих базу данных из одного согласованного состояния в другое». То есть до выполнения операции и после база остается консистентной (в переводе на русский — согласованной).
Например, пользователь в системе заполняет карточку:
Телефон — отдельно код страны, города и номер
Что такое ACID в базах данных?
В частности, ACID имеет отношение к тому, как БД может восстанавливаться после ошибок, возникающих в процессе выполнения транзакции.
В базах данных, следующих принципу ACID, данные остаются целостными и консистентными, несмотря на любые ошибки.
Определение ACID
Atomicity (атомарность)
Атомарность гарантирует, что каждый запрос в транзакции будет выполнен успешно, либо вообще никакой, в случае ошибки одного. Не получится так, что часть запросов выполнятся успешно, а часть с ошибкой. Если хоть одна часть транзакции выполнится с ошибкой, вся транзакция не выполнится. Другими словами под атомарностью можно понимать «всё или ничего».
Consistency (консистентность, согласованность)
Это свойство даёт гарантию того, что все данные будут целостны. Данные будут корректны в соотвествии со всеми предопределёнными правилами, ограничениями, каскадами и триггерами, применёнными к БД.
Isolation (изолированность)
Гарантирует, что все транзакции будут выполняться изолированно. Ни одна транзакция не зааффектит на другую транзакцию. Другими словами, одна транзакция не сможет прочитать данные второй транзакции, которая ещё не выполнилась.
Durability (стойкость)
Durability означает, что когда транзакция будет применена, она останется в системе, даже если БД упала сразу после выполнения этой транзакции. Любые изменения, внесённые транзакцией, должны оставаться навсегда. Если БД сообщила об успешном выполнении транзакции, то она должна быть действительно применена.
Когда пригодится ACID?
Свойства ACID спроектированы для transaction-ориентированные баз данных.
ACID предлагает принципы, которым должны придерживаться базы данных, чтобы быть уверенным в том, что данные не будут повреждены в результате какой нибудь ошибки.
Транзакция это единая логическая операция, которая может состоять из одного или нескольких шагов. Например, транзакцией может быть перевод денежных средств между банковскими аккаунтами (снятие денег из одного и пополнение другого). Если в середине такой транзакции возникнет ошибка, может возникнуть большая неконсистентность в данных. Деньги будут вычтены с одного счёта, но не зачислены в другой.
Вот тут и должны быть применены принципы ACID.
Следуя принципу ACID, база данных будет целостна тогда и только тогда, когда она будет содержать все результаты успешно выполненных запросов, выполненных в транзакции. Любая ACID совместимая БД гарантирует, что будут применены изменения только успешных транзакций. В случае ошибки в транзакции, данные не будут изменены.
Таким образом, СУБД, совместимые с ACID, дают организациям уверенность в том, что данные в их базе данных будут целостны, даже если произойдёт какой-либо сбой в середине выполнения транзакции.
Типы сбоев
Ошибка транзакции
Эта ошибка может произойти из-за некорректных входных данных или любых других нарушений целостности. Она так же возникает в результате тайм-аута, либо в результате deadlock.
Системный сбой
Системный сбой может быть из-за ошибки в коде СУБД, либо аппаратного сбоя.
Медийные сбои
Эти сбои случаются, когда запись или чтение из хранилища невозможны (например сбой в работе жёсткого диска, либо ошибки в работе операционной системе). Эти ошибки возникают намного реже, чем первые 2 типа.
Следование ACID принципам
Все популярные реляционные базы данных следуют принципам ACID. Все они имеют инструменты, обеспечивающие целостность данных при сбоях программного и аппаратного обеспечения, а также при любых неудачных транзакциях.
Но с NoSQL базами данных ситуация обстоит немного по-другому. Эти базы данных часто предназначены для обеспечения высокой доступности в кластере, а обычно это означает, что в некоторой степени жертвуют консистентностью и/или стойкостью. Однако большинство NoSQL баз данных в некоторой степени могут обеспечить атомарность.
Но всё же, большинстве NoSQL баз данных заложены основы целостности данных, что означает, что данные могут быть не синхронизированы какое-то время, но в конечном итоге они всё таки будут синхронизированы.
Вдобавок, некоторые разработчики, такие как MarkLogic, OrientDB и Neo4j, предлагают ACID-совместимые системы управления базами данных NoSQL.
Согласованные в конечном счете (Eventually Consistent)
Введение
В основе облачных вычислений Amazon лежат инфраструктурные сервисы. Такие, как Amazon S3, SimpleDB и EC2. Они позволяют строить масштабируемые вычислительные платформы и приложения. Требования к этим сервисам весьма жесткие. Они должны обеспечивать отличную безопасность, масштабируемость, доступность, производительность и эффективное использование ресурсов. И всё это – во время обслуживания миллионов клиентов со всего мира.
Внутри эти сервисы представляют собой огромные распределенные системы, работающие в мировом масштабе. Что создаёт дополнительные сложности, поскольку при обработке триллионов и триллионов запросов, события, которые обычно случаются с весьма низкой вероятностью, теперь гарантированно случаются. И это нужно учитывать при проектировании и разработке системы. В мировых масштабах мы используем репликацию повсеместно, чтобы обеспечить требуемую производительность и высокую доступность. Хотя репликация и приближает нас к нашим цели, она всё же не позволяет нам прозрачно достичь их. Существует ряд нюансов, с которыми столкнутся пользователи сервисов, использующих репликацию.
Один из таких нюансов – тип согласованности данных, обеспечиваемый системой. В частности, многие распространенные распределенные системы используют модель «согласованность в конечном счете» (eventual consistency) в контексте репликации данных. При разработке больших масштабируемых систем в Amazon мы использовали набор правил и абстракций, связанных с репликацией данных в больших масштабируемых системах. Мы сфокусировались на поиске компромисса между высокой доступностью (high availability) и согласованностью данных. В этой статье я рассмотрю часть информации, сформировавшей наш подход к построению надежных распределенных систем, работающих в мировом масштабе.
Историческая перспектива
В идеальном мире существовала бы только одна модель согласованности: после выполнения обновления данных, все наблюдатели увидят обновления. Первые трудности с достижением этого возникли в СУБД в конце 70х. Лучшая работа на эту тему – «Notes on Distributed Databases» Брюса Линдсей. Он излагает основные принципы репликации баз данных и обсуждает ряд техник, связанных с достижением согласованности. Множество из этих техник пытается достичь прозрачности распределения – чтобы с точки зрения пользователя это выглядело как единая система, а не как множество связанных систем. Многие системы того времени следовали подходу, что лучше сбой всей системы, чем нарушение прозрачности.
В средине 90х, с ростом систем в интернете, эта практика была пересмотрена. В это время люди начали склоняться к мнению, что доступность – наиболее важное свойство, но они не могли решить, чем пожертвовать в качестве компромисса. Эрик Брюэр (Eric Brewer), профессор Беркли, который в то время был главой Inktomi (компания, выпустившая успешный поисковик, которая потом была поглощена Yahoo – прим. пер.), собрал все компромиссы воедино в докладе на конференции PODC в 2000 году. Он представил теорему CAP, которая утверждает, что из трех свойств систем с распределенными данными – согласованность данных (consistency), доступность системы при сбое одного из узлов (system availability) и устойчивость к потере связи между сегментами сети (partition tolerance) (здесь и далее под сегментированием сети подразумевается потеря связи между частями распределенной системы, когда каждая часть отдельно работоспособна, но они «не видят» друг друга – прим. пер.) – одновременно можно достичь только два. Более формализованное подтверждение опубликовано в статье Сета Гилберта и Ненси Линча в 2002.
Система, не обеспечивающая устойчивости к потере связи между сегментами сети, может достичь согласованности данных и доступности, что зачастую достигается использованием протокола транзакций. При этом, определенные ситуации обрабатываются как сбой системы. Например, если клиент не видит часть узлов. Стоит отметить, что в больших масштабируемых системах зачастую присутствует сегментирование, потому согласованность данных и доступность не достижимы одновременно. Это значит, что у нас есть два выбора: ослабить согласованность, что позволит создать систему с высокой доступностью в условиях сегментирования сети, или же акцентироваться на согласованности, что приведет к недоступности системы в определенных ситуациях.
Оба варианта требуют внимания разработчика клиентской части к возможностям системы. Если система акцентируется на целостности, то разработчик должен иметь ввиду, что система может оказаться недоступной, например, для записи и соответственно обрабатывать эту ситуацию, чтобы не потерять данные. Если же система акцентирует внимание на доступности, то она может всегда обеспечивать запись, но чтение данных в некоторых случаях не будет отражать результат недавно осуществленной записи. Разработчику приходится решать, действительно ли клиенту необходимы самые-самые последние изменения. Во многих случаях допустимо использовать слегка устаревшие данные.
В принципе, согласованность в транзакционных системах, соответствующих ACID, – это несколько другой вид обеспечения согласованности. В ACID под согласованностью подразумевается гарантия, что по завершению транзакции база данных находится в согласованном состоянии. Например, при переводе денег между счетами, сумма денег на счетах не должна измениться. В системах, соответствующих ACID, этот вид согласованности, как правило, обеспечивается использованием транзакций и средств базы по обеспечению целостности данных.
Согласованность – клиент и сервер
Существует два взгляда на согласованность. Один с точки зрения разработчика/клиента: как они видят обновления данных. Второй – со стороны сервера: как проходят обновления в системе и что система может гарантировать относительно апдейтов.
Согласованность с точки зрения клиента
С точки зрения клиента у нас есть следующие компоненты:
Система хранения. На данный момент мы рассматриваем её как черный ящик. Но учитываем, что внутри нечто в высокой степени масштабируемое и распределенное, построенное для обеспечения устойчивости и доступности.
Процесс А. Процесс, который пишет в систему хранения и читает из неё.
Процессы В и С. Два процесса, не зависящие от процесса А, которые также пишут систему хранения и читают из неё. Не важно, являются ли они процессами или потоками одного процесса. Важно лишь то, что они независимы и должны взаимодействовать для обмена информацией.
Клиентская (client-side) согласованность определяет, как и когда наблюдатели (в нашем случае процессы А, В и С) видят изменения объекта данный в системе хранения. В следующих примерах, иллюстрирующих различные типы согласованности, процесс А выполнил обновление (update) данных.
Сильная согласованность (Strong consistency). После завершения обновления, любой последующий доступ к данным (Процессом А, В или С) вернет обновленное значение.
Слабая согласованность (Weak consistency). Система не гарантирует, что последующие обращения к данным вернут обновленное значение. Перед тем, как будет возвращено обновленное значение, должен выполниться ряд условий. Период между обновлением и моментом, когда каждый наблюдатель всегда гарантированно увидит обновленное значение, называется окном несогласованности (inconsistency window).
Согласованность в конечном счете (Eventual consistency). Частный случай слабой согласованности. Система гарантирует, что, при отсутствии новых обновлений данных, в конечном счете, все запросы будут возвращать последнее обновленное значение. При отсутствии сбоев, максимальный размер окна несогласованности может быть определен на основании таких факторов, как задержка связи, загруженность системы и количество реплик в соответствии со схемой репликации. Самая популярная система, реализующая «согласованность в конечном счете» – DNS. Обновленная запись распространяется в соответствии с параметрами конфигурации и настройками интервалов кэшированя. В конечном счете, все клиенты увидят обновление.
Согласованность в конечном счете (Eventual consistency) имеет множество вариаций, которые важно учитывать:
Причинная согласованность (Causal consistency). Если процесс А сообщил процессу В, что обновил данные, то последующие обращения процесса В к этим данным будут возвращать обновленные значения и запись гарантированно замещает более раннюю. Доступ процесса С, который не находится в причинной связи с процессом А, подчиняется обычным правилам eventual consistency.
Модель согласованности «Читай то, что записал» (Read-your-writes consistency). Это важная модель, в которой процесс А после обновления данных всегда при обращении получает обновленное значение и никогда не видит более старого. Это частный случай причинной согласованности (causal consistency).
Сессионная согласованность (Session consistency). Это практическая версия предыдущей модели, когда процесс получает доступ к хранилищу в контексте сессии. Пока сессия существует, система гарантирует Read-your-writes согласованность. Если же сессия завершается по причине какого-либо сбоя, то должна создаваться новая сессия, гарантированно не перекрывающаяся с другими.
Модель согласованности «однообразное чтение» (Monotonic read consistency). Если процесс увидел определенное значение, то, при последующих обращениях к этим данным, он никогда не получит более старое значение.
Модель согласованности «однообразная запись» (Monotonic write consistency). В этом варианте система гарантирует упорядоченность записи одного процесса. Системы, не обеспечивающие этот уровень согласованности, сложны в использовании.
Некоторые из этих вариаций могут быть скомбинированы. Например, можно объединить monotonic reads и сессионную согласованность. С практической точки зрения, monotonic reads и read-your-writes наиболее желанны в системах, реализующих «согласованность в конечном счете», но не всегда необходимы. Такая комбинация облегчает разработку приложений, позволяя при этом системе хранения ослабить согласованность и обеспечить высокую доступность.
«Согласованность в конечном счете» (Eventual consistency) не является какой-то эзотерической поэзией экстремальных распределенных систем. Многие современные реляционные СУБД, обеспечивающие надежность дублированием на резервный сервер (primary-backup reliability), реализуют работу механизма репликации в двух режимах: синхронном и асинхронном. В синхронном режиме обновление реплики является частью транзакции. В асинхронном режиме обновление доставляется как бекап, с некоторой задержкой, зачастую через доставку логов. В последнем случае, если основной сервер откажет до того, как лог был доставлен, то чтение с резервного сервера, поднятого вместо основного, вернет нам устаревшие данные. Также, для обеспечения лучшей масштабируемости чтения, реляционные СУБД начали предоставлять возможность чтения с резервного сервера, что является классическим случаем гарантий «согласованности в конечном счете», в котором размер окна несогласованности зависит от периодичности отправки лога.
Обмен данными. Консистентность vs Многопоточность
не должно быть такого валидного изменения системы А, которое приведет к тому, что обмен переведет систему Б в невалидное состояние
Какие же возможны варианты? Все богатство случаев с битыми ссылками, не хватающими остатками, разными ставками НДС и прочим и прочим можно свести к трем следующим вопросам:
Транзакционная последовательность
Этот уровень последовательности похож на то как SQL сервер делает бэкапы: он просто хранит лог транзакций и в случае необходимости накатывает их последовательно на БД.
Это единственный вариант, который гарантированно разрулит вообще все возможные недоразумения, включая перекрестные ссылки. Но в 1С он не достижим: мы не можем контролировать начало и фиксацию транзакции в 1С с тем, чтобы повторить тоже самое в источнике. Можно конечно попробовать опуститься на уровень SQL, но этот путь полон граблей и мы тут в общем про 1С, а не про MS SQL.
Хронологическая последовательность
Нужно складывать все версии всех объектов в отдельное место, не допуская никаких пропусков, подобно тому, как это делает подсистема Версионирование объектов и на стороне приемника воспроизводить эту последовательность.
Этот обмен с высокой долей вероятности разрулит перекрестный ссылки (если они организованы пользователем, а не кодом в одной транзакции). Также он справится с жесткими последовательными переходами (это пояснено чуть ниже).
Что вообще может пойти не так
На самом деле, случаев когда ни один уровень гарантии последовательности (кроме транзакционной или хронологической) не может обеспечить согласованность данных больше чем кажется.
Партионно-последовательная
Основным плюсом этой истории являет значительно оптимизированная ресурсоемкость при частых изменениях и нечастых обменах: не нужно хранить безумное число копий одного и того же объекта, не нужно записать в приемнике по 100 раз то, что можно записать однажды. Также, если говорить о переходе от логики «НомерСообщения меньше или равно» к логике «НомерСообщения равно» есть некое ослабление эффекта снежного кома: во-первых объекты имеют тенденцию к «утеканию» из ранних партий, во-вторых, ограниченность каждой партии способствует продвижению вперед при проблемах: валится один конкретный кусочек, вместо большого снежного кома.
Последовательность основанная на данных
Этот алгоритм точно знает, что бизнес-логика такова, что одни объекты надо прогружать раньше чем другие (например, номенклатуру раньше поступлений, поступления раньше реализаций) и гарантирует эту последовательность. Вообще, в «чистой» реализации, этот принцип должен быть доведен до следующего абсолюта:
На практике же, обмены редко бывают онлайновыми и скорее всего, последовательность основанная на данных будет применяться внутри какой-то сессии обмена (а это собственно и есть уровень гарантий Конвертации данных)
Реализовать довольно просто: нужно иметь табличку приоритетов и табличку изменений и грузить изменения, отсортированные по приоритетам. Номера сообщений при этом можно выкинуть, не обращать на них никакого внимания.
Последовательность Шредингера или согласованность в конечном счете
О транспортном уровне
Вообще, транспортный уровень не такая интересная тема, но скажем пару слом и о нем. Лучшие результаты достигаются при отделении друг от друга процессов транспорта и распаковки от процессов применения изменений т.е. в результате работы транспортного слоя мы уже должны видеть что нам предстоит сделать в части записи и иметь возможность манипулировать этими задачами не на уровне одной большой черной коробки. Фактически, если использовать складскую аналогию, принятая в 1С тактика такова:
Сами понимаете, на складах это так не работает. Работает так:
В этом смысле, алгоритм принимающий решение о том что грузить, в какой последовательности и что делать при фэйлах должен иметь перед собой картину того что предстоит сделать. Это может быть таблица (регистр сведений) вида: тип объекта, идентификатор объекта, данные объекта и всякая мета-информация вроде того откуда и когда этот объект пришел и сколько раз и с каким результатом его пытались записать.
Графовая согласованность
Так же как согласованность в конечном счете, с дополнительной проверкой ссылочной целостности
Высокая производительность (оценить выше/ниже согласованности в конечном счете не так просто, поскольку дополнительные затраты на проверку графа в одном случае могут нивелироваться отсутствием некоторого количества неудачных попыток в другом), учет связей между объектами при независимости реализации от условий конкретной конфигурации.
Это нереализуемо на 1С: реляционная БД не позволит выстраивать граф с приемлемой производительностью. Для этого потребуются noSQL решения вроде ElasticSearch.