Voici Hanzo Datastore : un moteur OLAP prêt pour le post-quantique

Aujourd'hui, nous publions Hanzo Datastore — la moitié OLAP de la plateforme de données Hanzo. C'est un fork de ClickHouse 26.6, débarrassé de la marque d'origine et reconstruit autour de la façon dont nous faisons vraiment tourner l'analytique : stockage séparé du calcul sur Hanzo S3, un binaire optimisé plus léger, et l'ancienne surface RPC retirée. L'image est en ligne sur ghcr.io/hanzoai/datastore:26.6.1.1.

Nous n'avons pas écrit une nouvelle base de données. ClickHouse est le meilleur moteur en colonnes au monde et nous nous appuyons dessus. Ce que nous avons changé, ce sont les parties qui comptent pour faire tourner une flotte : le substrat de stockage, la compilation, le transport et la feuille de route de la coordination.

Stockage et calcul, séparés

Les parts d'une table MergeTree sont des objets immuables. Datastore les stocke comme objets sur Hanzo S3 — notre couche de stockage dérivée de SeaweedFS — plutôt que sur un disque local soudé à un serveur. Des répliques de calcul sans état partagent alors une seule copie physique des données par réplication zero-copy.

C'est prouvé, pas une promesse. Dans notre test de montée en charge, une table de 5 millions de lignes dont la politique de stockage vise S3 signale le disque seaweed dans system.parts, et deux nœuds de calcul montent en charge sur cette copie unique. Ajouter un nœud de lecture ne copie pas les données ; il s'y attache. C'est la propriété que vous voulez quand une charge analytique s'envole et qu'il faut ajouter de la capacité de requête en quelques secondes, sans redistribuer des téraoctets.

-- 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   │
-- └───────────┴───────────┘

La moitié de la mémoire, un binaire plus petit

La compilation de la version applique l'optimisation guidée par les profils, l'optimisation légère à l'édition de liens et une passe BOLT après l'édition de liens. Le résultat est environ la moitié de la mémoire résidente de la compilation d'origine et un binaire nettement plus petit. Faire fonctionner BOLT sur aarch64 a exigé de désactiver l'instrumentation XRay, qui était activée par défaut et bloquait en silence la réécriture après le lien — ce correctif est dans l'arbre. L'effet concret : le même plan de requête, moins de gigaoctets, et un binaire qui démarre plus vite.

gRPC a disparu

Un datastore doit avoir exactement un chemin de requête, pas trois. Nous avons retiré entièrement le serveur gRPC — pas de contrib/grpc, pas de définitions de service protobuf, pas de chemin de compilation ENABLE_GRPC — et, dans la même passe, nous avons effacé le bloc <grpc> mort de la configuration par défaut afin que le produit livré corresponde à la compilation. Datastore parle TCP natif (9000), HTTP (8123) et réplication entre serveurs (9009). C'est toute la surface.

Le transport prévu ensuite est ZAP, notre RPC dérivé de Cap'n Proto. Le stub du serveur est arrivé ; ce n'est pas encore le chemin de requête en service. Nous préférons vous dire exactement où se situe cette ligne plutôt que de laisser entendre que c'est terminé.

Où va la coordination

Les tables Replicated* se coordonnent aujourd'hui par un Raft embarqué, le Keeper compatible avec ZooKeeper qui voyage dans le processus du serveur — aucun démon séparé. Cela fonctionne, et c'est ce que vous faites tourner en production aujourd'hui.

La direction est de remplacer ce backend Raft par Quasar, le consensus sans leader et post-quantique de Lux, lié nativement dans le serveur C++. La jointure est réelle : un programme C++ pilote déjà le moteur de consensus natif à travers son C ABI — ouvrir une chaîne, ajouter une entrée au journal de réplication, conduire les votes de confiance, observer la finalité — avec zéro Raft et zéro machinerie zero-knowledge. C'est la preuve que l'échange est un problème d'édition de liens, pas une réécriture. Ce n'est pas encore la couche de coordination de production, et nous ne prétendrons pas le contraire.

L'autre moitié

Datastore, c'est l'OLAP. La moitié OLTP de la plateforme est un moteur SQL décentralisé construit sur SQLite/Base — conçu, en cours de construction, pas encore livré. Si vous voulez aujourd'hui l'histoire des données local-first et à fichier unique, cette lignée apparaît déjà dans Hanzo Brain, et le substrat de stockage sur lequel reposent les deux moitiés est celui que nous avons lancé dans Hanzo Storage.

Lancez-le

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

• Source : github.com/hanzoai/datastore
• Produit : hanzo.ai/datastore
• Docs : docs.hanzo.ai

L'image arm64 est publiée maintenant ; la compilation amd64 suit via la CI. C'est le backend d'analytique et d'insights que nous faisons tourner nous-mêmes — pointez vos événements dessus et interrogez-les en retour à vitesse colonnaire.