На самом деле, моржи — это действительно неплохой проект, который постоянно работает над хранением. В настоящее время хранение дефицитно и имеет большие перспективы.
WAL "Пространственно-временной каркас" системы данных.
При построении системы данных мы легко можем впасть в заблуждение: считать, что данные в таблицах базы данных являются "сущностью". Однако для высокоуровневого архитектора таблицы — это всего лишь кэш, а логи — это истина.
Вот суть WAL (предварительно записанный лог). Он не только является страховкой для восстановления после сбоев, но и оружием против физических законов и универсальным языком распределенных систем.
1. Противодействие обману физики дисков.
Ключевое противоречие в базах данных заключается в войне между нестабильностью памяти и медленной работой дисков.
Если каждый раз при изменении данных обращаться к дисковым страницам, случайные перемещения головки могут затормозить производительность системы. Гениальность WAL заключается в том, что он "обманывает" систему: он превращает дорогостоящую случайную запись в чрезвычайно дешевое последовательное добавление.
Система сообщает пользователю "сохранено", на самом деле просто быстро записывается строка лога. Реальное сброс грязных страниц на диск откладывается на фоновые процессы. Эта стратегия **"сэкономить время за счет пространства"** является основой всех высокопроизводительных систем хранения.
2. fsync: Игра между операционной системой и базой данных.
Записав лог, можно считать, что это безопасно? Не обязательно. Операционная система ради производительности часто оставляет данные в кэше страниц и не сбрасывает их на диск сразу. Чтобы гарантировать D (постоянство) из ACID, WAL должен пробить ложь операционной системы с помощью дорогостоящего системного вызова fsync, принудительно сбрасывая данные на физический диск.
Конечная цель оптимизации производительности базы данных часто сводится к выбору частоты вызова fsync: делать это при каждом коммите, даже жертвуя производительностью для обеспечения долговечности, или позволить потерять секунду данных в обмен на максимальную пропускную способность?
3. Копирование состояния машины: от одиночной машины к бесконечности.
Когда WAL выходит за пределы одиночной машины, он становится душой распределенного консенсуса.
Будь то репликация от мастера к слейву в MySQL или протокол Raft, по сути, это **"копирование состояния машины"**. Главное узловое устройство отправляет не данные, а поток WAL. Узлы-слейвы воспроизводят эти логи, восстанавливая в удаленном месте полностью идентичное состояние с главным узлом.
Этот механизм в современных архитектурах далее эволюционирует в CDCWAL, который освобождается и направляется в Kafka, в хранилище данных, становясь связующим звеном между гетерогенными островами данных.
