Ответ
Durability (Долговечность) — это свойство транзакций в ACID, гарантирующее, что после успешного завершения (COMMIT) все внесённые изменения сохраняются в базе данных на постоянном носителе (например, на диске) и не будут потеряны даже в случае системного сбоя, отключения питания или перезапуска сервера.
Как это обеспечивается на практике? Основной механизм — журнал транзакций (Write-Ahead Log, WAL). Перед тем как изменения будут записаны в основные таблицы на диске, они сначала фиксируются в специальном журнале. Этот журнал организован так, чтобы его запись была последовательной и атомарной, что делает её очень быстрой и надёжной. В случае аварии СУБД может восстановить состояние данных, "проиграв" (replay) записи из этого журнала.
Пример настройки в PostgreSQL для строгой гарантии:
-- Гарантирует, что транзакция не будет считаться завершённой,
-- пока её запись не будет записана на диск.
ALTER SYSTEM SET synchronous_commit = ON;Важные нюансы и компромиссы:
- Производительность vs. Надёжность: Самые строгие настройки durability (например,
innodb_flush_log_at_trx_commit=1в MySQL) требуют синхронной записи журнала на диск для каждой транзакции, что снижает пропускную способность. Более слабые настройки (0или2) могут повысить производительность, но рискуют потерей последних транзакций при сбое. - Зависимость от оборудования: Гарантии durability также зависят от корректной работы оборудования (например, дисков с кэшированием без батарейной поддержки могут сбросить кэш при отключении питания, потеряв данные).
- Распределённые системы: В распределённых БД обеспечение durability усложняется и часто связано с консенсус-алгоритмами (например, Raft), которые реплицируют журнал на несколько узлов перед подтверждением записи.
Ответ 18+ 🔞
Ну слушай, тут про долговечность транзакций, а звучит как инструкция к вечному двигателю. Durability, блядь. Это такая штука из ACID, которая гарантирует, что если транзакция сказала «окей, я всё сделала» (это и есть COMMIT), то твои изменения уже никуда не денутся. Даже если серверу на голову упадёт кирпич, отключится свет или админ, ёпта, случайно зальёт его кофе — данные останутся на диске. Не как в оперативке, которая всё забывает после перезагрузки, а именно на постоянной памяти. Волнение ебать — представляешь, отвечать за такое?
А как это, спрашивается, работает? Хитрая жопа, конечно. Основной фокус — это журнал транзакций, он же Write-Ahead Log (WAL). Суть в чём: прежде чем данные запишутся в сами таблицы на диск (а это может быть долго и муторно), все изменения сначала стрелой летят в этот специальный журнал. Запись в него — быстрая и последовательная, потому что он просто дописывает всё в конец. И только потом, не спеша, данные интегрируются в основные файлы. Если случается пиздец, система просто открывает этот журнал после перезагрузки и доделывает всю работу заново, «проигрывая» записи. Гениально и просто, я сам от себя охуел, когда впервые понял.
Вот, смотри, как в PostgreSQL можно включить параноидальный режим, чтобы спать спокойно:
-- Эта штука гарантирует, что транзакция не соврёт тебе про успех,
-- пока её следы не будут выжжены на диск.
ALTER SYSTEM SET synchronous_commit = ON;Но тут, конечно, доверия ебать ноль к компромиссам. Вся соль в настройках:
- Надёжность vs. Скорость: Самый жёсткий режим (в MySQL, например,
innodb_flush_log_at_trx_commit=1) заставляет систему сбрасывать данные на диск после каждой транзакции. Это надёжно, но терпения ноль ебать — производительность проседает, потому что дисковая операция медленная. А если поставить0или2, то всё летает, но есть риск потерять последние секунды данных при фатальном сбое. Выбирай: либо быстро, либо чтобы ни хуя себе не пропало. - Железо — твой друг или враг: Тут можно наступить на грабли. Если у тебя диск с кэшем, но без батарейки (BBU), и свет вырубится, то этот кэш может накрыться медным тазом, и прощай, часть данных из журнала, которую ты считал уже сохранённой. Подозрение ебать чувствую ко всему, что без автономного питания.
- А в распределённых системах вообще ёклмн. Там одной записи на локальный диск мало — надо, чтобы ещё несколько узлов в кластере подтвердили, что они тоже получили твои данные. Используют всякие консенсус-алгоритмы вроде Raft, чтобы реплицировать этот самый журнал. Пока большинство узлов не кивнут, транзакция не считается по-настоящему «долговечной». Удивление пиздец, насколько всё усложняется, когда одна база данных размазана по десяти серверам.
