ACID требования, CAP- теорема, BASE архитектура

3. ACID требования, CAP- теорема, BASE архитектура 2

ACID – требования надежности к транзакционной системе Atomicity - Атомарность. Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Достигается реализацией транзакции и откатами. Consistency - Согласованность. Каждая успешная транзакция по определению фиксирует только допустимые результаты – согласованные данные. Достигается полнотой необходимых действий внутри одной транзакции. Isolation - Изолированность. Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Достигается блокировками. Durability - Надежность. Устойчивость к сбоям тех данных, которые изменялись в успешных транзакциях. 3

CAP теорема (теорема Брюера) эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: Согласованность / целостность данных (англ. Consistency) во всех вычислительных узлах в один момент времени данные не противоречат друг другу; Доступность (англ. Availability) любой запрос к распределённой системе завершается корректным откликом; Устойчивость к разделению / разделяемость (англ. Partition tolerance) расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций. 4

CAP-теорема, кейс «позвони- напомним» 1. У меня есть записная книжка и телефон (-Разделяемость) 2. Не справляюсь с потоком(-Доступность), прошу жену. 3. У нее своя книжечка, клиент звонит то мне, то ей, конфликты (- Целостность). 3. Договариваемся при внесении изменений вносить в обе книжечки. Много времени уходит на синхронизацию, упала скорость приема звонков (-Доступность). 4. … 5. Profit--; ((( 5

CA – Целостность и доступность Система, во всех узлах которой данные согласованы и обеспечена доступность, жертвует устойчивостью к распаду на секции. Такие системы возможны на основе технологического программного обеспечения, поддерживающего транзакционность в смысле ACID. Примерами таких систем могут быть решения на основе кластерных систем управления базами данных или распределённая служба каталогов LDAP. 6

CP – целостность и разделяемость Распределённая система, в каждый момент обеспечивающая целостный результат и способная функционировать в условиях распада, в ущерб доступности может не выдавать отклик. Устойчивость к распаду на секции требует обеспечения дублирования изменений во всех узлах системы, в этой связи отмечается практическая целесообразность использования в таких системах распределённых пессимистических блокировок для сохранения целостности. 7

AP – Доступность и Разделяемость Распределённая система, отказывающаяся от целостности результата. Хотя системы такого рода известны задолго до формулировки принципа CAP (например, распределённые веб-кэши или DNS), рост популярности систем с этим набором свойств связывается именно с распространением теоремы CAP. Так, большинство NoSQL-систем принципиально не гарантируют целостности данных, и ссылаются на теорему CAP как на мотив такого ограничения. Задачей при построении AP-систем становится обеспечение некоторого практически целесообразного уровня целостности данных, в этом смысле про AP-системы говорят как о «целостных в конечном итоге» 8

Разделяемость + …? 9 Целостност ь CP Доступност ь AP

Различные решения для различных требований 10

BASE-архитектура Basically Available, Soft-state, Eventually consistent базовая доступность, неустойчивое состояние, согласованность в конечном счёте Противопоставляется ACID. Под базовой доступностью подразумевается такой подход к проектированию приложения, чтобы сбой в некоторых узлах приводил к отказу в обслуживании только для незначительной части сессий при сохранении доступности в большинстве случаев. Неустойчивое состояние подразумевает возможность жертвовать долговременным хранением состояния сессий (например, промежуточные результаты выборок), при этом концентрируясь на фиксации обновлений только критичных операций. Целостность / согласованность в конечном счёте, трактующейся как возможность противоречивости данных в некоторых случаях, но при обеспечении согласования в практически обозримое время. 11

Согласованность в конечном счете или слабая согласованность Eventually consistent, weak consistent (слабая целостность) Неформально гарантирует, что при отсутствии новых апдейтов ячейки все чтения данной ячейки будут когда-нибудь возвращать одинаковые результаты. Рассогласованность может возникать при оптимистичных (ленивых) репликациях. Репликам какое-то время позволяется иметь различные данные. Конфликты могут устранять при помощи метки времени. Новее – лучше. Конфликты разрешаются при: При чтениях При записи для оптимизации – что реже? Плановая синхронизация 12