CAP рассматривает несовместимые гарантии при разделении. PACELC добавляет цену согласования при исправной связи. Сценарий штатной задержки нужен наряду с испытанием разделения сети.
Распределённые данные
Принцип PACELC
Определение
Принцип PACELC — правило, по которому распределённую базу оценивают дважды: при разделении сети — доступность против согласованности, без него — задержка против согласованности. Он напоминает, что согласование узлов стоит времени и в обычной работе.
Также ищут: PACELC · PACELC principle · partition availability consistency else latency consistency
Зачем это знать
Даже исправная удалённая реплика отвечает не мгновенно. Если операция обязана дождаться её подтверждения, размещение площадок влияет на время ответа. PACELC помогает составить условия приёмки: что ждём, какой результат обещаем и как меняется режим при потере связи.
Связи из словаря
Карта понятия
Принцип PACELC
Доказательная часть
Что подтверждено
PACELC соединяет два вопроса: при разделении сети — компромисс доступности и согласованности, иначе — компромисс задержки и согласованности. Штатный режим рассмотрен отдельно, потому что межузловое согласование влияет на обычные операции и без аварии.
Граница применимости: Принцип PACELC Даниэля Абади; это схема анализа, а не числовая формула задержки.
Одной меткой PACELC нельзя заменить описание режима конкретной операции. Настраиваемая база может ждать удалённое подтверждение в одном режиме записи и не ждать в другом; выбранный путь чтения также имеет свои гарантии.
Граница применимости: Применение PACELC к настраиваемой репликации; режимы PostgreSQL служат конкретным примером, а не классификацией всех продуктов.
В учебном сценарии запись ждёт обязательного подтверждения удалённой реплики. Передача до неё занимает 40 мс, ответ обратно — ещё 40 мс. Один такой обмен занимает не менее 80 мс даже без отказа; обработка, запись на носитель и очереди могут добавить время.
Граница применимости: Один обязательный последовательный обмен запросом и подтверждением; заданные односторонние задержки, без обходного пути и исключения ожидания из ответа клиенту. Учебные числа, не паспортная задержка СУБД.
Ожидание сохранения записи на удалённой реплике не тождественно ожиданию её применения там. В PostgreSQL режим remote_apply отдельно дожидается применения, чтобы изменения стали видимы запросам на подтверждающей реплике. Поэтому режим записи и путь последующего чтения разбирают вместе.
Граница применимости: PostgreSQL 18, синхронная репликация и remote_apply; видимость конкретного запроса дополнительно ограничена его снимком.
Задержка синхронной записи зависит от того, чьи подтверждения обязательны. PostgreSQL позволяет ждать заданное число синхронных реплик; наличие ещё одной удалённой копии не означает, что каждая операция обязательно ждёт именно её.
Граница применимости: PostgreSQL 18, настройка синхронной репликации; точное правило выбора реплик и ожидаемый этап задаются конфигурацией.
Если при потере синхронной реплики запись начинает завершаться без её подтверждения, меняется условие успешного завершения. Такой переход нужно явно описать: меньшая задержка ответа не доказывает сохранение прежней гарантии удалённой записи.
Граница применимости: Сравнение синхронного и асинхронного режима подтверждения на примере PostgreSQL; автоматическое переключение без настройки не обещается.
Граница терминов
Не путать
Синхронная репликация — конкретный механизм ожидания подтверждений. PACELC помогает оценить, чем выбранное ожидание оплачивается по задержке и что происходит при его недоступности.
Перед спецификацией
Что проверить
- Выберите одну операцию и назовите требуемый результат её успешного ответа.
- Запишите обязательные удалённые подтверждения и этап, которого ждёт запись.
- Сопоставьте размещение реплик с задержкой пути до обязательного подтверждения и обратно.
- Проверьте свежесть чтения на той реплике, куда действительно направляется клиент.
- Измерьте время ответа и его разброс при обычной рабочей нагрузке.
- Повторите проверку при недоступной реплике и разрыве межплощадочной связи.
- Любой переход к завершению без прежнего подтверждения запишите как изменение гарантии.
Открытые основания
Первоисточники
- Consistency Tradeoffs in Modern Distributed Database System Design
Вводит PACELC: partition tradeoff и отдельный normal-operation latency/consistency tradeoff.
- PostgreSQL 18 Documentation: Transaction Isolation
Определяет isolation phenomena и фактическое поведение PostgreSQL levels, включая Serializable.
Утверждения: 04
- Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
Формализует CAP impossibility для atomic consistency и availability в asynchronous network model.