Итоги 5 главы (Генерация данных в исходных системах)

Т.к. всю главу прочли сами, начали сразу с ее обсуждения.
——————————————————————
Оставался вопрос на обсуждение - отличие ACID (при уровне изоляции read uncommitted) от BASE (согласованность в конечном счете). И есть ли уровни для прочих свойств, кроме Isolation в ACID.

расшифровочка:
ACID - Atomicity (Атомарность), Consistency (Согласованность), Isolation (Изолированность) и Durability (Долговечность).

BASE - basically available, soft-state, eventual consistency (базовая доступность, неустойчивое состояние, согласованность в конечном счете).

Итак-с, начнем с ACID.

ACID - это свойства транзакции. И вот Isolation вызвал у нас вопросики.

Isolation (Изолированность):
Каждая транзакция выполняется как бы “в вакууме”, изолированно от других параллельных транзакций. В идеале изолированность предотвращает "грязные" и "фантомные" чтения. Откуда же взялись уровни?

В общем, в реальных СУБД этот принцип достигается через уровни изоляции (основные - read uncommitted, read committed, repeatable read, serializable). И вот уровень изоляции read uncommitted - самый слабый: запрос может читать грязные данные, т.е. изменения, которые ещё не закоммичены и могут откатиться.

Насколько я поняла, пока читала всякое-разное, полный вакуум (serializable - самый строгий уровень изоляции) это, конечно, ✨красева✨, но более медленно. База начинает чутка тормозить, всё блокируется и мы превращаемся в 🐌.

Однако, только уровень serializable наиболее строго соответствует ACID. Остальные уровни - это компромиссы между производительностью и строгостью соблюдения ACID. (Но при этом база всё равно считается ACID-совместимой, потому что разработчики СУБД допускают такие реализации ради баланса)...

Но важно: как только транзакция закоммитилась, данные становятся видимы и они согласованы по ACID-правилам. В итоге у БД будет чёткое и согласованное состояние.

Подытожим: read uncommitted сильно ослабляет изолированность и потому почти не используется; строгое понимание ACID соответствует serializable. Ну и про "уровни" для остальных принципов - формально их не выделяют отдельно, как для изоляции, но если они появляются - это уже и не то чтобы ACID, а какое-то подобие...🥲😅

Теперь вернемся к BASE.

BASE - ☝️философия☝️ (а не формализованный стандарт) NoSQL: жертвуем мгновенной строгой согласованностью ради масштабируемости и доступности.

(Маленькое уточнение: BASE не обязательно означает только eventual consistency, бывают и другие подходы (например, causal consistency или read-your-writes, но в них не разбиралась, только увидела, что такое есть). В общем, мы тут разбираем BASE с позиции согласованности в конечном счете.

В отличие от строгого ACID-вакуума, BASE - это такой расслабленный режим: главное, чтобы сервис был доступен, а с консистентностью разберёмся потом.

При eventual consistency узлы системы могут какое-то неопределенное время хранить разные версии данных. Мы можем прочитать “устаревшее” значение, хотя оно было уже изменено где-то в другом месте.

Но гарантия такая: рано или поздно все реплики придут к одному состоянию (если нет новых изменений).

Если есть, что уточнить/добавить по теме (особенно из практики), делитесь в комментах, будет полезно👾
——————————————————————
Планы на встречу 14 сентября:
• Домашнее задание: прочитать на неделе ещё одну часть главы "Хранение" (с 243 по 267 стр).
• До конца главу прочтем вместе при встрече

Начнем в 12 по мск💛
P.S. Если что, присоединиться можно в любой момент