AngaraBase: новая HTAP СУБД

Значимый прорыв формирует отрасль ИИ: anishukserg 8 минут назад AngaraBase: новая HTAP СУБД Сложный 19 мин 81 PostgreSQL * Базы данных * Rust * SQL * Системное администрирование * Это продолжение цикла статей про нашу СУБД на Rust. Предыдущие были про устройство ядра по подсистемам:Мы знаем как готовить БД. Но индустрия изменилась: что бы я заложил в OLTP-БД с нуляКонтракт вместо настроек: чего я жду от OLTP-БДКак я проектирую OLTP-БД с нуля: принципы, trade-off’ы и архитектурные решенияAPI-контракты между слоями ядраBuffer Pool с Clock-sweep и изоляцией скановВекторизованный исполнитель с многоверсионными индексамиMVCC без VACUUM: что нам дал UNDO-лог и какую цену мы заплатили (предыдущая статья цикла)Мы назвали наш проект AngaraBase.

Документация уже открыта на angarabase. dev; оттуда же можно поставить текущую версию и своими руками потрогать всё, о чём шёл разговор все эти месяцы. Весь цикл мы писали, не называя проект по имени.

Технические детали

С этой статьи все называем своими именами. Анонимность всё это время была не осторожностью, а осознанным выбором, и причин на то было несколько:Первая: организационная. Пока часть вопросов вокруг проекта не была улажена, выходить под именем было преждевременно.

Вторая: сначала архитектура. Мы хотели, чтобы проект пришёл к читателю не очередным «вот ещё одна база данных», а с уже разобранными контрактами, инвариантами и компромиссами, чтобы было видно, что и зачем устроено именно так. Третья: имя обязывает.

Назвать продукт публично значит начать отвечать за обратную совместимость: за имена, форматы, поведение. Пока имени нет, руки развязаны: что видели корявым, переписывали, от легаси уходили везде, где могли. Получилось не везде (у нас, например, ещё жив синхронный I/O (про это писали в API-контракты между слоями ядра), хотя и здесь мы методично двигаемся к async), но назови мы всё это раньше, пришлось бы тащить за собой каждое промежуточное решение.

Отраслевые последствия

Полный сравнительный сьют, с воспроизводимым стендом, прозрачной методикой и опубликованными артефактами, мы готовим отдельной статьёй (она уже почти готова): мешать манифест с простынёй замеров не на пользу ни тому, ни другому, а одной цифрой такую СУБД всё равно не описать. Здесь приведём только два ориентира, которые уже не стыдно назвать. Первый: точечное чтение по тёплому кэшу на одной ноде отвечает примерно за 0.

48 мс, против около 1 мс, которую мы видим на том же сценарии у PostgreSQL 18. Второй ниже, в разделе про HTAP. И сразу про обратную сторону, как есть: на тяжёлой полнотабличной агрегации и на транзакционном throughput под высокой конкуренцией мы пока заметно медленнее зрелых движков.

Важно, что мы понимаем причину и это не баг и не потолок архитектуры: и колоночный путь, и единый снапшот заложены ровно под эти сценарии. Отстаёт пока реализация, а не замысел: материализация в колонки ещё не подключена, часть путей I/O всё ещё синхронные. Мы как раз начинаем следующий мажорный релиз, где по планам эти куски и доделываются, и именно они должны изменить картину.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.