Простыми словами объясним эти подходы к масштабированию систем хранения данных. На понятном примере и без использования сложной терминологии.
Теоремы CAP и PACELC — ограничения в распределённых системах
Распределённые системы — это набор независимых серверов, взаимодействующих через сеть для достижения общей цели. Они используются в основе практически всех популярных современных сервисов. Однако проектирование таких систем сопряжено с неизбежными компромиссами, которые описывают теоремы CAP и PACELC.
CAP‑теорема
CAP‑теорема утверждает, что в системе можно одновременно обеспечить не более двух из трёх свойств:
- Согласованность (Consistency)
- Доступность (Availability)
- Устойчивость к разделению (Partition Tolerance)
Типы систем по CAP‑теореме
CP‑системы (Consistency + Partition Tolerance) — жертвуют доступностью ради согласованности, применяются там, где критична точность данных (например, в финансовой сфере).
AP‑системы (Availability + Partition Tolerance) — жертвуют согласованностью ради доступности, применяются там, где временная несогласованность данных вполне допустима (например, в развлекательной сфере).
CA‑системы (Consistency + Availability) — возможны только при исключении возможности сетевого разделения, то это системы, которые не являются распределёнными.
Распределённые системы по определению должны быть устойчивы к возможному разделению — исключить сетевые сбои невозможно, поэтому при разрывах связи между узлами эти системы должны продолжать работать, пусть и с ожидаемыми ограничениями.
Согласованность или доступность при сетевых сбоях
Трактовка CAP‑теоремы для распределённых систем формулируется в следующем виде: при возникновении сетевого разделения распределённая система может гарантировать либо согласованность (C+P), либо доступность (A+P).
Важно понимать, что этот компромисс актуален только при сетевом разделении, а в нормальных условиях работы (без сетевых сбоев) распределённая система вполне может одновременно обеспечивать и согласованность, и доступность.
Однако, всё несколько сложнее — обеспечение согласованности в условиях штатной работы (при отсутствии сетевых разделений) всё же требует дополнительного компромисса в быстродействии, который не следует из CAP‑теоремы, но вполне объясняется теоремой PACELC.
PACELC‑теорема
Теорема PACELC является логическим развитием CAP‑теоремы и устраняет её ключевое ограничение — игнорирование компромиссов в условиях отсутствия сетевых разделений. Первые 3 буквы в аббревиатуре PACELC идентичны по значению CAP (их порядок просто другой), а вот следующие 3 буквы (ELC) добавляют ещё один аспект: в нормальных условиях (E, Else) выбор между низкими задержками (L, Latency) и согласованностью (C, Consistency).
PAC: Partition → Availability (A) OR Consistency (C) — в условиях разделения выбираем или доступность, или согласованность.
ELC: Else → [Low] Latency (L) OR Consistency (C) — в штатном режиме выбираем или согласованность, или высокую скорость работы (снижение задержек).
Если рассматривать в качестве примера репликацию в СУБД, то высокая согласованность потребует синхронной репликации, что увеличит задержки; а применение асинхронной репликации снизит задержки, но допустит временную несогласованность.
Eventual Consistency
На самом деле, когда при сбоях мы жертвуем согласованностью ради доступности (AP-системы) или когда в штатном режим выбираем низкие задержки в ущерб согласованности, то мы вовсе не должны терять согласованность полностью и навсегда. Мы не имеем гарантии постоянной согласованности, но вполне можем получить согласованность «в конечном счёте» (Eventual Consistency) — согласованность в случае разделения настанет после устранения сбоя, а в случае штатной работы с низкими задержками — просто через какое‑то время.
Зачем нужны теоремы CAP и PACELC?
Это теоремы стоит воспринимать как руководство для проектировщиков распределённых систем. Понимание компромиссов позволяет выбирать оптимальную архитектуру, создавая распределённые системы, адаптирующиеся не только к сбоям, но и к повседневным нагрузкам.
Тематические статьи
СУБД — это очень часто «узкое место» в производительности веб‑приложений. В момент, когда сервер баз данных не может справится с нагрузками, производится масштабирование. В современных высоконагруженных системах эффективное управление данными невозможно без использования методов масштабирования и обеспечения отказоустойчивости. Репликация, партиционирование и шардирование — ключевые подходы, которые позволяют распределять данные, повышать производительность и гарантировать доступность. Разберем каждый из них подробно.
Базы данных служат для хранения и обработки данных. Бывают реляционные (SQL) и нереляционные (NoSQL) системы управления базами данных. Реляционные системы управления базами данных (SQL) хранят данные в таблицах и наиболее часто используются в качестве основного хранилища для веб‑приложений. Они очень стабильны и их надёжность проверена временем. Нереляционные СУБД (NoSQL) заметно отличаются по структуре хранения данных и работе с ними. Большинство нереляционных хранилищ превосходят классические SQL СУБД по скорости доступа или при работе со специфическими типами данных, но обычно эта скорость достигается за счёт снижения надёжности хранения.
PostgreSQL — это популярная объектно-реляционная система управления базами данных. PostgreSQL базируется на языке SQL, отличается высокой надёжность и имеет широкие возможности. В PostgreSQL нет ограничений на максимальный размер базы данных, количество записей и индексов таблицах. В СУБД встроены мощные и надёжные механизмы транзакций, есть возможности для репликации, шардинга и партиционирования. СУБД отличает легкая расширяемость и возможность тонкой настройки.
MySQL — это реляционная система управления базами данных с открытым исходным кодом. В настоящее время эта СУБД одна из наиболее популярных в веб‑приложениях — подавляющее большинство CMS использует именно MySQL (часто только её, без альтернатив), а почти все веб‑фреймворки поддерживают MySQL уже на уровне базовой конфигурации (без дополнительных модулей).
MariaDB — ответвление реляционной СУБД MySQL, разрабатываемое сообществом под лицензией GPL. MariaDB полностью совместима с приложениями, использующими MySQL, а переход на эту СУБД оправдан тем, что MySQL уже не так активно развивается.
MongoDB — это NoSQL хранилище данных, крайне удобное для хранения информации, которая не может быть нормально структурирована в рамках реляционных баз данных. MongoDB — это СУБД с открытым исходным кодом, не требующая описания схемы таблиц. Документы в MongoDB хранятся в JSON или BSON, работа с такой моделью проще кодируется и проще управляется, а внутренняя группировка релевантных данных обеспечивает дополнительный выигрыш в быстродействии.