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

Записаться

Немного терминологии. Традиционные базы данных - это инструменты, которые реализовывали принцип ACID или ACID требования к надежности транзакционной системы. Расшифровывается, как аббревиатура слов Atomicity (Атомарность), Consistency (Согласованность или целостность), Isolation (Изолированность) и Durability (надежность).

Что под этим понимается? Под Атомарностью понимается, что данные внутри одной транзакции не могут быть изменены частично. Либо вся целиком транзакция исполняется, либо вся целиком транзакция откатывается в случае неуспеха её завершения.

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

Изолированность. Мы говорим, что на данные не может повлиять никакой другой процесс, если мы касаемся их, что-то с ними делаем внутри текущей транзакции. Реализуется это простыми блокировками. В этом и есть головная боль. Но, скажем, искусство администраторов, как не потерять производительности базы данных при множественных операциях записи и вставки изменения и несовпадание взаимной блокировки.

Надёжность. Мы говорим, что, если у нас единожды транзакция была отмечена, как успешно, то после этого какой бы сбой в системе не происходил: пропало питание, что-то случилось с памятью, ещё какие-то проблемы, то у нас данные бы сохранились именно в том виде, в котором они были после завершения успешной транзакции.

При масштабировании, а именно при горизонтальном масштабирование, при распределённости, стало бы понятно, что транзакционный системы, либо очень неэффективный, медленны за счет обмена между серверами, это именно та узкая часть, которая привносит распределенность, либо мы не удовлетворяем всем требованиям ACID.

Возникла такая теорема. Была сформулирована Брюером, явно слышали, называется «CAP-теорема». Она про то, что есть три требования: согласованность, целостность, доступность и устойчивость к разделению, разделяемость. Все эти требования невозможно реализовать в едином хранилище, то есть до сих пор базы данных делали упор на согласованность и доступность. Высокая доступность - это количество операций или объемов на чтение, на запись. Если мы обеспечиваем согласованность и доступность, то у нас нету разделяемости. Если мы обеспечим разделяемость, мы должны жертвовать чем-то еще.

Наверно, встречали, на пальцах объясняется «CAP-теорема» через кейс «позвони-напомним». Это как, если бы вы создали стартап по оказанию услуги - просто напоминалки. Человек один раз вам звонит, просит запомнить. Второй раз звонит, просит напомнить, а вы сидите на телефоне записывайте в книжечку, каким-то образом структурируя эти данные. Представим, что у вас всё идет хорошо до тех пор, пока клиентов не становится слишком много и вы просто не успевает отвечать всем на звонки, и они не дожидаются вашего ответа. Тогда вы берёте в долю жену. Садите её еще с одним телефоном на параллельный номер, на тот же номер, но со своей книжечкой. Вы справляетесь до тех пор, пока какой-то из клиентов не позвонил, вы взяли трубку и записали его информацию, а потом он позвонил снова, попросил напомнить и трубку взяла ваша жена, и не нашла в своей книжечки ничего, что ему нужно было напомнить. Клиент недоволен, вы понимаете, что в данный момент у вас начинается проблема. Ну да, первый случай, мы говорим, что у нас нет никакой разделяемости, мы делаем всё в одной записной книжечке. Второй случай, когда вы не справитесь с потоком, это у вас нету требования доступности. И третий случай, когда вы работаете с женой, у вас не выполняются требования целостности. Если же вы понимаете, что вам нужно вносить изменения в лобби книжечки и каким-то образом организуйтесь, либо после каждого звонка, либо каждый час, либо в конце рабочего дня, то в конечном итоге у на эти синхронизации уходит столько времени, что вы снова работайте, как один человек, который обрабатывает звонки, в худшем случае, то есть вы снова теряйте доступность, ну и так далее.

Какие из этой теоремы можно получить следствия? Ну, это знать, что система распадается на три больших класса, которые реализуют попарно два требования. Есть класс систем, который реализует целостность и доступность, это значит, что мы жертвуем разделяемостью, это стандартные базы данных или все системы, которые реализуют требования ACID. Мы про это говорили. Появляется классы, которые жертвуют доступностью, но ориентируются на целостность данных и на разделяемость. То есть это уже распределенная точная система, которая говорит, что мы лучше не ответим на чьи-то запросы, чем потеряем данные. И третий класс задач и втрой, которые реализуют распределенность, разделяемость, это те решения, которые ориентируются на реализацию доступности, увеличение количества пользователей, увеличение количества запросов, но при этом они говорят, не то что мы можем потерять данные, но мы можем точно не во всё время обладать целостностью, согласованностью данных. То есть мы представляем, что, если у нас есть распределенные решение и мы в один из серверов записали какое-то значение, а считали вдруг с другого сервера, то они могут различаться, тогда, в этом случае, говорят о согласованности в конечном счете. Это такое мягкое требование, что в рациональные сроки, с точки зрения приложения или бизнеса, эти два значения синхронизуются и все чтения данной информации, если не было операций записи в эту ячейку, они выдадут одно и то же значение. Так запоминаем, слабая целостность, вид консистенции, или целостность в конечном итоге.

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

Дальше мы поговорим, какие приложения реализуются, как с точки зрения требования приложений выбирать то или иное. Ну и стандартная диаграмма в совокупности исключающих требований. На пересечении двух из них как раз находятся различные решения. Будем подробно разговаривать об этих решениях и о том, как из них выбирать.

Итак, фиксируем, что от требований ACID решение по хранению данных переходят на требование BASE, которые сформулированы именно для разделяемых систем. В этом смысле они противопоставляются требованиям ACID. BASE - тоже аббревиатура от Basically Available, Soft-state и Eventually consistent. Об Eventually consistent мы уже говорили, это слабая согласованность или согласованность в конечном итоге, конечном счете. Soft-state - это неустойчивое состояние, так называемое, подразумевает возможность жертвовать долговременным хранением состояния сессии, и в этом смысле сессии могут завершаться неуспешно, и не все сессии могут быть откатаны. Базовая доступность говорит, что мы иногда жертвуем доступностью, если у нас есть другое требование. Даже, наверное, не стоит уже повторяться про согласованность в конечном счете. Можно только сказать, что все возникающие конфликты согласованности все равно разрешаются. Это происходит либо при операциях чтения, то есть запрашивания ячейки, мы можем проверить, насколько она согласована в наших репликах, либо при операциях записи. Здесь, обычно, выбирают для оптимизации ресурсов ту операцию, которая происходит реже. То есть, если мы редко изменяем, но очень часто читаем, то, конечно, нам правильней синхронизоваться на операциях записи. Если же мы очень часто записываем, изменяем данные, но редко читаем, то есть данный меняется очень быстро, но в промежутке до того момента, когда мы начали их читать, они, конечно, на все эти промежуточные значения не нужны, поэтому они могут быть разными на наших репликах, но тот момент, когда мы читаем, мы синхронизуем. В этом смысле пытаемся получить самые актуальные. Ну и как разрешаются эти конфликты, самое простое решение - это временная метка, то есть данные, которые новее, считаются более хорошими.