Vi presentiamo Hanzo Datastore: un motore OLAP pronto per il post-quantistico

Oggi rilasciamo Hanzo Datastore — la metà OLAP della piattaforma dati di Hanzo. È un fork di ClickHouse 26.6, senza il marchio originale e ricostruito intorno a come eseguiamo davvero l'analitica: archiviazione separata dal calcolo su Hanzo S3, un binario ottimizzato più snello e la vecchia superficie RPC tolta. L'immagine è già live su ghcr.io/hanzoai/datastore:26.6.1.1.

Non abbiamo scritto un database nuovo. ClickHouse è il miglior motore colonnare al mondo e ci appoggiamo ad esso. Quello che abbiamo cambiato sono le parti che contano per far girare una flotta: il substrato di archiviazione, la build, il trasporto e la roadmap del coordinamento.

Archiviazione e calcolo, separati

Le parti di una tabella MergeTree sono oggetti immutabili. Datastore le memorizza come oggetti su Hanzo S3 — il nostro strato di archiviazione derivato da SeaweedFS — invece che su un disco locale saldato a un server. Le repliche di calcolo senza stato condividono poi una sola copia fisica dei dati tramite replicazione zero-copy.

È dimostrato, non è una promessa. Nel nostro test di scale-out una tabella da 5 milioni di righe, la cui policy di storage punta a S3, riporta il disco seaweed in system.parts, e due nodi di calcolo scalano su quella singola copia. Aggiungere un nodo di lettura non copia i dati; vi si aggancia. È la proprietà che vuoi quando un carico analitico schizza e devi aggiungere capacità di query in pochi secondi, senza rimescolare terabyte.

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

Metà della memoria, un binario più piccolo

La build di release esegue ottimizzazione guidata dai profili, ottimizzazione leggera al link time e un passaggio BOLT dopo il linking. Il risultato è circa metà della memoria residente della build di serie e un binario decisamente più piccolo. Far funzionare BOLT su aarch64 ha voluto dire spegnere la strumentazione XRay, che era accesa di default e bloccava in silenzio la riscrittura post-link — quella correzione è nell'albero. L'effetto pratico: lo stesso piano di query, meno gigabyte e un binario che parte più in fretta.

gRPC non c'è più

Un datastore deve avere esattamente un percorso di query, non tre. Abbiamo rimosso del tutto il server gRPC — niente contrib/grpc, niente definizioni di servizio protobuf, niente percorso di build ENABLE_GRPC — e nello stesso passaggio abbiamo cancellato il blocco <grpc> morto dalla configurazione predefinita, così il prodotto distribuito coincide con la build. Datastore parla TCP nativo (9000), HTTP (8123) e replicazione tra server (9009). È tutta la superficie.

Il trasporto previsto più avanti è ZAP, il nostro RPC derivato da Cap'n Proto. Lo stub del server è atterrato; non è ancora il percorso di query attivo. Preferiamo dirti con esattezza dove sta quella linea piuttosto che lasciar intendere che sia finita.

Dove va il coordinamento

Le tabelle Replicated* oggi si coordinano tramite Raft incorporato, il Keeper compatibile con ZooKeeper che viaggia dentro il processo del server — nessun demone separato. Funziona, ed è quello che esegui in produzione adesso.

La direzione è sostituire quel backend Raft con Quasar, il consenso senza leader e post-quantistico di Lux, collegato in modo nativo nel server C++. La giuntura è reale: un programma C++ guida già il motore di consenso nativo attraverso il suo C ABI — aprire una catena, accodare una voce del log di replicazione, guidare i voti di confidenza, osservare la finalità — con zero Raft e zero macchinario zero-knowledge. È la prova che lo scambio è un problema di linking, non una riscrittura. Non è ancora lo strato di coordinamento di produzione, e non faremo finta del contrario.

L'altra metà

Datastore è OLAP. La metà OLTP della piattaforma è un motore SQL decentralizzato costruito su SQLite/Base — progettato, in costruzione, non ancora rilasciato. Se oggi vuoi la storia dei dati local-first e a file singolo, quel lignaggio compare già in Hanzo Brain, e il substrato di archiviazione su cui viaggiano entrambe le metà è quello che abbiamo lanciato in Hanzo Storage.

Eseguilo

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

• Sorgente: github.com/hanzoai/datastore
• Prodotto: hanzo.ai/datastore
• Documentazione: docs.hanzo.ai

L'immagine arm64 è pubblicata ora; la build amd64 arriva dopo, tramite la CI. Questo è il backend di analitica e insight che eseguiamo noi — punta i tuoi eventi verso di esso e rileggili a velocità colonnare.