Присоединяйтесь к бете Hanzo и получите скидку 50% на любой платный тариф

Представляем Hanzo Datastore: OLAP-движок, готовый к постквантовой эпохе

Колоночное хранилище на основе ClickHouse, пересобранное вокруг разделения хранения и вычислений на Hanzo S3, с профильной оптимизацией и оптимизацией на этапе компоновки примерно до половины памяти, без gRPC и с путём к постквантовой координации без лидера.

На этой странице

Сегодня мы выпускаем Hanzo Datastore — OLAP-половину платформы данных Hanzo. Это форк ClickHouse 26.6 со снятой маркой, собранный заново вокруг того, как мы на самом деле гоняем аналитику: хранение отдельно от вычислений на Hanzo S3, более лёгкий оптимизированный бинарник и снятая старая поверхность RPC. Образ уже доступен по адресу ghcr.io/hanzoai/datastore:26.6.1.1.

Мы не писали новую базу данных. ClickHouse — лучший колоночный движок в мире, и мы опираемся на него. Мы изменили то, что важно, когда крутишь флот: основу хранения, сборку, транспорт и дорожную карту координации.

Хранение и вычисления порознь

Куски таблицы MergeTree — неизменяемые объекты. Datastore хранит их объектами на Hanzo S3 — нашем слое хранения на базе SeaweedFS — а не на локальном диске, приваренном к одному серверу. Реплики вычислений без состояния делят одну физическую копию данных через репликацию с нулевым копированием.

Это уже проверено, а не план на будущее. В тесте на горизонтальное масштабирование таблица из 5 миллионов строк, чья политика хранения смотрит на S3, показывает диск seaweed в system.parts, и два вычислительных узла масштабируются на этой единственной копии. Узел на чтение данные не копирует — он к ним подключается. Именно это свойство нужно, когда аналитическая нагрузка подскакивает и ёмкость запросов надо добавить за секунды, не перекладывая терабайты.

-- parts live on S3, not on a node's local disk
SELECT name, disk_name FROM system.parts WHERE table = 'events' LIMIT 1;
-- ┌─name──────┬─disk_name─┐
-- │ all_1_1_0 │ seaweed   │
-- └───────────┴───────────┘

Вдвое меньше памяти, бинарник меньше

Релизная сборка проходит профильную оптимизацию, тонкую оптимизацию на этапе компоновки и проход BOLT после линковки. Резидентная память — примерно половина от стоковой сборки, а бинарник заметно меньше. Чтобы BOLT заработал на aarch64, пришлось выключить инструментацию XRay: она по умолчанию была включена и тихо блокировала перезапись после линковки. Это исправление уже в дереве. На практике тот же план запроса, меньше гигабайт, и бинарник стартует быстрее.

gRPC больше нет

У хранилища должен быть ровно один путь запроса, не три. Сервер gRPC мы сняли целиком — нет contrib/grpc, нет описаний сервисов protobuf, нет пути сборки ENABLE_GRPC — и за тот же проход из конфигурации по умолчанию вычистили мёртвый блок <grpc>, чтобы то, что мы отдаём, совпадало со сборкой. Datastore говорит нативным TCP (9000), HTTP (8123) и межсерверной репликацией (9009). Это и есть вся поверхность.

Дальше по транспорту — ZAP, наш RPC на основе Cap'n Proto. Серверная заготовка уже в дереве; живым путём запроса она пока не стала. Лучше честно сказать, где эта черта, чем намекнуть, что всё готово.

Куда движется координация

Таблицы Replicated* сегодня координируются встроенным Raft: это совместимый с ZooKeeper Keeper, он живёт внутри процесса сервера, отдельного демона нет. Так оно работает, и именно это сейчас крутится в продакшене.

Направление — заменить этот бэкенд Raft на Quasar, постквантовый консенсус без лидера из Lux, нативно влинкованный в сервер на C++. Шов настоящий: программа на C++ уже ведёт нативный движок консенсуса через его C ABI — открыть цепочку, дописать запись в журнал репликации, провести голоса уверенности, увидеть финальность — без Raft и без механизмов нулевого разглашения. Это доказательство, что замена — вопрос линковки, а не переписывания. Производственным слоем координации это ещё не стало, и мы не будем делать вид, что стало.

Другая половина

Datastore — это OLAP. OLTP-половина платформы — децентрализованный SQL-движок на SQLite/Base: он спроектирован, его строят, он ещё не вышел. Если история данных local-first в одном файле нужна уже сегодня, эта линия уже видна в Hanzo Brain, а основа хранения, на которой едут обе половины, — та, что мы запустили в Hanzo Storage.

Запустите

docker run -d --name datastore \
  -p 8123:8123 -p 9000:9000 \
  ghcr.io/hanzoai/datastore:26.6.1.1

Образ arm64 уже опубликован; сборка amd64 придёт следом через CI. Это тот бэкенд аналитики и выводов, на котором работаем мы сами: направьте в него события и забирайте их обратно на колоночной скорости.

Комментарии

Войдите с Hanzo ID, чтобы комментировать.

Загрузка комментариев…

Читать далее