Wir stellen Hanzo Datastore vor: eine OLAP-Engine bereit für Post-Quanten-Kryptografie

Heute liefern wir Hanzo Datastore aus — die OLAP-Hälfte der Datenplattform von Hanzo. Es ist ein Fork von ClickHouse 26.6, von der fremden Marke befreit und rund um die Art neu gebaut, wie wir Analytik wirklich betreiben: Speicher getrennt von der Rechenleistung auf Hanzo S3, ein schlankeres optimiertes Binary, und die alte RPC-Oberfläche ist entfernt. Das Image liegt live unter ghcr.io/hanzoai/datastore:26.6.1.1.

Wir haben keine neue Datenbank geschrieben. ClickHouse ist die beste spaltenorientierte Engine der Welt, und wir bauen darauf auf. Geändert haben wir die Teile, auf die es ankommt, wenn eine Flotte läuft: das Speichersubstrat, den Build, den Transport und die Roadmap der Koordination.

Speicher und Compute, getrennt

Die Parts einer Tabelle MergeTree sind unveränderliche Objekte. Datastore legt sie als Objekte auf Hanzo S3 ab — unsere von SeaweedFS abgeleitete Speicherschicht — statt auf eine lokale Platte, die an einen Server geschweißt ist. Zustandslose Compute-Replikate teilen sich dann per Zero-Copy-Replikation eine einzige physische Kopie der Daten.

Das ist belegt, nicht bloß ein Anspruch. In unserem Scale-out-Test meldet eine Tabelle mit 5 Millionen Zeilen, deren Storage Policy auf S3 zielt, die Platte seaweed in system.parts, und zwei Compute-Knoten skalieren über diese eine Kopie. Ein weiterer Lese-Knoten kopiert die Daten nicht; er hängt sich daran. Genau das willst du, wenn eine Analytik-Last hochschnellt und du in Sekunden Abfragekapazität zulegen musst, ohne Terabytes umzuschichten.

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

Halb so viel Speicher, ein kleineres Binary

Der Release-Build fährt profilgeführte Optimierung, dünne Linkzeitoptimierung und einen BOLT-Pass nach dem Linken. Heraus kommt etwa die Hälfte des residenten Speichers des Standard-Builds und ein deutlich kleineres Binary. BOLT auf aarch64 zum Laufen zu bringen hieß, die XRay-Instrumentierung auszuschalten. Die war standardmäßig an und hat die Umschreibung nach dem Linken still blockiert — der Fix liegt im Baum. Praktisch heißt das: derselbe Abfrageplan, weniger Gigabytes, und ein Binary, das schneller startet.

gRPC ist weg

Ein Datastore soll genau einen Abfrageweg haben, nicht drei. Den gRPC-Server haben wir ganz entfernt — kein contrib/grpc, keine Protobuf-Service-Definitionen, kein Build-Pfad ENABLE_GRPC — und im selben Durchgang den toten <grpc>-Block aus der Standardkonfiguration gestrichen, damit das ausgelieferte Produkt zum Build passt. Datastore spricht natives TCP (9000), HTTP (8123) und Replikation zwischen Servern (9009). Das ist die ganze Oberfläche.

Der Transport, der folgen soll, ist ZAP, unser von Cap'n Proto abgeleitetes RPC. Der Server-Stub ist da; der lebendige Abfrageweg ist er noch nicht. Wir sagen dir lieber genau, wo diese Linie liegt, als zu tun, als wäre sie fertig.

Wohin die Koordination steuert

Tabellen Replicated* koordinieren sich heute über eingebettetes Raft, den ZooKeeper-kompatiblen Keeper, der im Serverprozess mitkommt — kein eigener Daemon. Das funktioniert, und genau das fährst du jetzt in Produktion.

Die Richtung: dieses Raft-Backend wird ersetzt durch Quasar, den Konsens ohne Leader und mit Post-Quanten-Kryptografie aus Lux, nativ in den C++-Server gelinkt. Die Naht ist echt. Ein C++-Programm steuert die native Consensus-Engine schon über deren C ABI — eine Chain öffnen, einen Eintrag ans Replikationslog hängen, Confidence-Votes treiben, Finality beobachten — mit null Raft und null Zero-Knowledge-Maschinerie. Das zeigt: der Tausch ist ein Link-Problem, keine Neufassung. Das ist noch nicht die Koordinationsschicht in Produktion, und wir tun nicht so, als wäre es das.

Die andere Hälfte

Datastore ist OLAP. Die OLTP-Hälfte der Plattform ist eine dezentrale SQL-Engine auf SQLite/Base — entworfen, im Bau, noch nicht ausgeliefert. Wenn du heute die local-first Geschichte in einer einzigen Datei willst, findest du diese Linie schon in Hanzo Brain, und das Speichersubstrat, auf dem beide Hälften fahren, ist das, das wir in Hanzo Storage gestartet haben.

Starten

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

• Quellcode: github.com/hanzoai/datastore
• Produkt: hanzo.ai/datastore
• Doku: docs.hanzo.ai

Das arm64-Image ist jetzt veröffentlicht; der amd64-Build folgt über die CI. Das ist das Backend für Analytik und Insights, das wir selbst fahren — richte deine Events darauf und frag sie mit spaltenorientierter Geschwindigkeit wieder ab.