Архитектура Lakebase

Lakebase отделяет хранилище от вычислительных ресурсов. Движок Postgres, который выполняет ваши запросы, не имеет состояния, а ваши данные находятся в надёжном слое хранения, который сохраняется независимо. Именно это разделение делает возможным автомасштабирование, масштабирование до нуля, мгновенные ветвления, чтение реплик и быстрое отказное переключение.

Чтобы показать, что меняет Lakebase, эта страница начинается с традиционного одномашинного дизайна базы данных для контраста, затем объясняет, как Lakebase разделяет этот же дизайн на отдельные слои и что делает каждый элемент.

Как строится традиционная база данных

Прежде чем рассматривать Lakebase, подумайте о модели, которую он заменяет. Обычная база данных Postgres — это монолит. Одна машина запускает движок запросов и записывает как журнал вперёд (WAL ), так и файлы данных на диск, подключённый в локальной точке монтирования. Традиционно эти диски были действительно локальными, частью одной и той же машины, но по мере развития инфраструктуры они часто стали сетевыми носителями.

WAL и файлы данных выполняют две взаимодополняющие функции:

• WAL ускоряет запись. Postgres добавляет каждое изменение в журнал последовательно перед подтверждением коммита, который работает быстро и надёжно на одном диске.
• Файлы с данными ускоряют чтение. Postgres материализует текущую версию каждой страницы в файлы данных, чтобы запрос мог читать строку без повторного воспроизведения журнала.

Доступ ко всем данным через одну машину имеет свои недостатки:

• Долговечность напрямую связана с физической инфраструктурой машины. Также нужно заранее подготовить хранение и прогнозировать, насколько увеличится ваша нагрузка, что усложняет как управление затратами, так и планирование устойчивости.
• Высокая доступность и множество видов горизонтального масштабирования требуют физических клонов всей базы данных.
• Если эта машина выйдет из строя, можно потерять данные. Такие методы, как RAID-хранилище, снижают этот риск, но дополнительная избыточность может значительно повысить стоимость эксплуатации системы.

Архитектура Lakebase

Lakebase сохраняет те же обязанности, но разделяет их на два независимых слоя:

• Вычислительный слой, который запускает стандартный, бессостоянный Postgres.
• Слой хранения, состоящий из сейфкиперов, серверов страниц и облачного объектного хранилища.

Две роли из монолита напрямую соотносятся с новыми компонентами. WAL, который ускорил запись, становится сохранником, который записывает масштаб. Файлы данных, которые ускоряли чтение, становятся серверами страниц, которые масштабируют чтение.

Поскольку данные хранятся в облачном объектном хранилище, а не на одной машине, Lakebase обеспечивает эластичные, масштабируемые вычислительные и надёжные записи, воспроизводимые в разных зонах доступности. Нет никакого запаса: вы платите только за то хранилище, которое потребляете, и не нужно планировать варианты отказа, например, когда диск заканчивается.

Эта модель также улучшает производительность. Lakebase записывает каждое изменение напрямую в несколько точек, что позволяет избежать накладных расходов на традиционную защиту от torn-write и выравнивание блоков. Поскольку каждая запись уже идёт в несколько точек, производительность остаётся стабильной независимо от того, включена ли высокая доступность.

Следующая таблица отображает каждую часть монолита с её аналогом из Lakebase.

Традиционный монолит	Lakebase	Role
Одна машина	Вычисления без состояния	Запускает движок запросов Postgres
Локальный WAL диск	Хранители безопасности	Стабильно фиксирует каждое завершённое изменение
Локальные файлы данных	Серверы страниц и объектное хранилище	Материализуется и хранит версии страниц

Слой вычислений

Вычислительный слой запускает Postgres. Он содержит только временное состояние: общие буферы Postgres в памяти и локальный вычислительный кэш, поддерживаемый быстрым локальным диском. Он не владеет устойчивыми данными.

Потому что Compute не обладает устойчивым состоянием:

• Её можно заменить, перезапустить, автоматически масштабировать или масштабировать до нуля без перемещения и потери данных.
• Вместо записи в локальную файловую систему он транслирует WAL на уровень хранения.
• Несколько вычислительных экземпляров могут подключаться к одному и тому же слою хранения, именно так работают реплики чтения и быстрый резервный режим Lakebase.

Уровень хранилища

Слой хранения надёжен и работает независимо от вычислений. Он состоит из трёх компонентов.

Хранители безопасности

Сейфкиперы — это WAL, вытащённые из одной машины и сделанные очень доступными. Пока Postgres производит записи WAL, он передаёт их группе сейфкиперов, которые воспроизводят журнал по кворуму с помощью протокола консенсуса на базе Paxos.

Транзакция совершается, когда кворум сейфкиперов подтверждает запись WAL, а не когда одна машина завершает локальный fsync. Надёжность достигается за счёт репликации между узлами, а не с одного диска.

Серверы страниц

Серверы страниц — это файлы данных, которые извлекают и перестраиваются из WAL. Pageserver использует поток WAL от сейфкиперов и материализует версии страниц по запросу. Когда Compute запрашивает страницу с определённым номером последовательности журнала (LSN), сервер страниц восстанавливает и возвращает её.

Серверы страниц работают как кэш с записью над объектным хранилищем. Они асинхронно сохраняют материализованные страницы в облачном объектном хранилище, и реконструкция страниц не блокирует транзакционный коммит.

Хранилище облачных объектов

Облачное хранилище объектов — это основа долговечности всего слоя хранения. Он хранит данные страницы, которые сохраняют серверы страниц.

On Azure, Lakebase persists data to Хранилище BLOB-объектов Azure.

Объектное хранилище остаётся вне горячего запроса. Только серверы страниц читают с него. Для подробностей о том, как работает резервирование хранилища и почему оно не зависит от настройки высокой доступности вычислений, см. раздел Архитектура хранилища.

Как работает письмо

Запись проходит из вычисления через слой хранения:

1. Postgres изменяет затронутые страницы в памяти и создаёт записи WAL.
2. Compute передаёт записи WAL к сохранникам.
3. Когда кворум сохранников подтверждает эти записи, сделка совершается, и клиент получает успех.
4. Серверы страниц применяют WAL асинхронно и сохраняют обновлённые страницы в объектное хранилище.

Транзакция становится устойчивой, как только кворум сейфкиперов имеет запись WAL, потому что одного журнала достаточно для восстановления данных. Pageservers восстанавливают и сохраняют страницы данных вне пути коммита, поэтому записи остаются быстрыми, не подвергая риску никаких фиксированных изменений.

Как работает чтение

Чтение проверяет иерархию кэшей — от самого быстрого до медленного — и останавливается на первом слое, где находится страница:

1. Пул буферов (память): Postgres использовал общие буферы в вычислительной оперативной памяти.
2. Локальный вычислительный кэш: Кэш, защищённый диском на вычислительном узле, размер которого соответствует памяти вычислительной системы.
3. Pageserver: При кэше промах вычислительный запрос на страницу у pageserver, который восстанавливает её в запрошенном LSN.
4. Хранилище объектов: Pageserver читает данные из объектного хранилища внутри при необходимости. Запросы не доходят напрямую до объектного хранилища.

Что позволяет эта архитектура

Отделение вычислений без состояния от долговечного хранения делает возможными несколько функций Lakebase:

Функция	Что это позволяет
Автомасштабирование	Поскольку вычисления не имеют состояния, Lakebase масштабирует размер вычислительных данных вверх или вниз в ответ на нагрузку без перемещения данных.
Масштабирование до нуля	Вычисления могут полностью приостановиться, пока хранение сохраняется, и данные сразу доступны при возобновлении вычислений.
Мгновенные ветви	Создайте изолированную, пригодной к записи копию вашей базы данных за считанные секунды. Поскольку ветвление — это операция копирования при записи метаданных на общим хранилище, оно не дублирует данных.
Чтение реплик	Несколько вычислительных экземпляров читаются с одного и того же уровня хранения, поэтому репликам не нужны копии данных и они начинаются за секунды.
Запросы в точке времени	Поскольку слой хранения сохраняет историю, вычислительные системы могут прикрепляться к прошлой точке времени и читать базу данных в её тогдашнем виде, не копируя данные обратно.
Быстрое отказное переключение	Резервное переключение продвигает вторичный вычислительный экземпляр, который подключается к существующему хранилищу без перемещения данных.
RPO = 0 (нет фиксированной потери данных)	Lakebase тщательно фиксирует каждую совершённую транзакцию перед её подтверждением, поэтому вы не теряете фиксированные данные при сбоях вычислительных данных, перезапуске или масштабировании до нуля.

Как эта архитектура поддерживает LTAP

Поскольку Lakebase надёжно хранит каждое зафиксированное изменение в облачном объектном хранилище, те же данные могут выполнять аналитические нагрузки наряду с транзакциями без отдельного репликационного конвейера. Это основа для Lake Transactional and Analytical Processing (LTAP), где одна копия ваших данных поддерживает как транзакционные, так и аналитические системы. Чтобы узнать, как LTAP строится на этой архитектуре, см. статью LTAP architecture.

Дальнейшие действия

• Архитектура хранения: Узнайте, как работает резервирование хранения и почему оно не зависит от настройки высокой доступности вычислений. См. архитектуру хранилища.
• Ветки базы данных: Посмотрите, как ветки используют хранилище копирования при записи для создания мгновенных, изолированных сред. См. ветви.
• Читайте реплики: Добавьте вычислительные экземпляры только для чтения, которые используют один и тот же слой хранения. См. реплики чтения.
• Основные концепции: Ознакомьтесь с полным набором концепций, которые делают Lakebase уникальной. См. Основные концепции.