ACID разбирает четыре свойства транзакций. CAP рассматривает конфликт формальной доступности и атомарной согласованности при разделении сети. Одинаковая буква C не делает это одной проверкой: корректность данных заказа и допустимый порядок сетевых операций проверяют отдельно.
Распределённые данные
Свойства ACID
Определение
Свойства ACID — четыре требования к транзакции базы данных: атомарность, согласованность, изоляция и долговечность. Каждое отвечает за своё: общий исход изменений, допустимость данных, поведение при параллельной работе и сохранность результата при предусмотренном отказе.
Также ищут: ACID properties · ACID · атомарность согласованность изоляция долговечность
Зачем это знать
Для одного заказа эти свойства дают четыре разные проверки. Запись заказа и резерв должны завершиться вместе; данные должны соблюдать правила продажи; две продажи не должны совместно нарушить эти правила; подтверждённый результат должен пережить оговорённый сбой. Название СУБД или более быстрый сервер ни одну из этих проверок не заменяют.
Связи из словаря
Карта понятия
Доказательная часть
Что подтверждено
ACID объединяет атомарность, согласованность, изоляцию и долговечность. Атомарность связывает общий исход изменений; согласованность — допустимость состояния; изоляция — взаимодействие параллельных транзакций; долговечность — сохранение зафиксированного результата при предусмотренных отказах.
Граница применимости: Классическая модель транзакций; конкретные уровни изоляции и ослабленные режимы подтверждения требуют отдельного описания.
Заявление об ACID у локальной базы не доказывает атомарность внешней оплаты, согласование реплик большинством или возможность восстановиться до ошибочного удаления. Для этих задач нужны собственные участники, протоколы и материалы восстановления.
Граница применимости: Граница локальной транзакции, распределённой координации и восстановления истории; вывод из сопоставления моделей.
Для заказа атомарность проверяют на связанных изменениях одной транзакции: при полном откате одновременно отменяются создание заказа и резерв. Успешное завершение каждой команды по отдельности не доказывает общий исход всей операции.
Граница применимости: Редакторский пример свойства A для двух транзакционно управляемых изменений; цена, остаток и внешний платёж не считаются автоматически включёнными.
Свойство C предполагает заданные правила допустимого состояния и корректную логику перехода. База может отклонить нарушение объявленного ограничения, но не распознаёт неописанное правило скидки, кредитного лимита или адресата платежа.
Граница применимости: Согласованность ACID и граница ограничений данных; деловые примеры иллюстрируют необходимость явно заданных правил.
Проверка одного заказа без конкурентов не проверяет изоляцию. Две транзакции могут читать только зафиксированные данные и всё же совместно дать результат, который нельзя получить при их последовательном выполнении; PostgreSQL 18 допускает такие аномалии ниже Serializable.
Граница применимости: Свойство I; аномалия сериализации в модели и уровнях PostgreSQL 18. Не утверждение, что каждая пара конкурентных операций ошибочна.
Для свойства D требуется назвать, какое событие считается подтверждением и какой отказ результат должен пережить. В PostgreSQL 18 ожидание устойчивой локальной записи WAL и ожидание синхронной реплики определяются настройками; сохранность локального носителя не доказывает сохранность после его полной утраты.
Граница применимости: Модель долговечности и условия подтверждения PostgreSQL 18; отказ носителя рассматривается при отсутствии другой пригодной копии.
Буква C обозначает разные условия в ACID и CAP. В ACID речь о сохранении правил допустимых данных. В формализации CAP — об атомарной согласованности операций, то есть их порядке, совместимом с реальным временем. Доказательство одного условия не доказывает второе.
Граница применимости: Редакторское сопоставление модели транзакций и формального условия согласованности Gilbert–Lynch; не перечень свойств конкретного продукта.
Граница терминов
Не путать
Долговечность сохраняет принятый результат при оговорённом отказе. Проверенное восстановление устанавливает, можно ли получить нужное состояние из сохранённых материалов. Ошибочное удаление может быть надёжно зафиксировано, поэтому требуется история, предшествующая ошибке.
Перед спецификацией
Что проверить
- Запишите для заказа конкретные требования A, C, I и D четырьмя отдельными проверяемыми предложениями.
- Для A остановите выполнение посередине и убедитесь, что полный откат убирает все изменения внутри заявленной границы.
- Для C отправьте неверный остаток, повторный номер и недопустимую скидку; установите, какое ограничение или участок кода отклоняет каждый случай.
- Для I одновременно выполните две продажи последнего доступного товара и проверьте совместный результат.
- Для D зафиксируйте настройки подтверждения и испытайте предусмотренный сбой на отдельном тестовом контуре.
- Проверьте обработку отказа транзакции: приложение должно корректно сообщать результат и повторять только разрешённую операцию.
- Отдельно подтвердите план внешней оплаты, сохранённую историю и успешную проверку восстановления до ошибки.
Открытые основания
Первоисточники
- PostgreSQL 18 Documentation: PREPARE TRANSACTION
Описывает prepared transaction, external transaction manager и operational risk forgotten prepared state.
Утверждения: 02
- In Search of an Understandable Consensus Algorithm (Extended Version)
Первичное описание Raft: leader election, replicated log, commit majority и safety.
Утверждения: 02
- PostgreSQL 18 Documentation: Continuous Archiving and Point-in-Time Recovery
Связывает base backup, непрерывный WAL archive и проверяемый recovery target.
Утверждения: 02
- PostgreSQL 18 Documentation: Transactions
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить границы BEGIN/COMMIT/ROLLBACK, отдельные транзакции без BEGIN, точки сохранения и оговорку о поведении клиентских библиотек.
Утверждения: 03
- PostgreSQL 18 Documentation: Constraints
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить CHECK и NULL, NOT NULL, UNIQUE и границу проверок одной строки; пример заказа — редакторское применение этих правил.
Утверждения: 04
- PostgreSQL 18 Documentation: Transaction Isolation
Определяет isolation phenomena и фактическое поведение PostgreSQL levels, включая Serializable.
Утверждения: 05
- PostgreSQL 18 Documentation: Write-Ahead Logging
Описывает порядок устойчивой записи WAL до изменённых страниц, восстановление страниц из журнала после сбоя и фиксацию транзакций без обязательного сброса всех изменённых страниц.
Утверждения: 06
- PostgreSQL 18 Documentation: Log-Shipping Standby Servers
Фиксирует async default, synchronous commit wait points и связь replication delay с data loss.
Утверждения: 06
- Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
Формализует CAP impossibility для atomic consistency и availability в asynchronous network model.
Утверждения: 07