Presentamos Hanzo Datastore: un motor OLAP preparado para lo poscuántico

Hoy publicamos Hanzo Datastore — la mitad OLAP de la plataforma de datos de Hanzo. Es una bifurcación de ClickHouse 26.6, sin la marca de origen y reconstruida alrededor de cómo ejecutamos de verdad la analítica: almacenamiento separado del cómputo en Hanzo S3, un binario optimizado más ligero y la superficie RPC heredada fuera. La imagen ya está disponible en ghcr.io/hanzoai/datastore:26.6.1.1.

No hemos escrito una base de datos nueva. ClickHouse es el mejor motor columnar del mundo y nos apoyamos en él. Lo que hemos cambiado son las piezas que importan para operar una flota: el sustrato de almacenamiento, la compilación, el transporte y la hoja de ruta de la coordinación.

Almacenamiento y cómputo, por separado

Las partes de una tabla MergeTree son objetos inmutables. Datastore las guarda como objetos en Hanzo S3 — nuestra capa de almacenamiento derivada de SeaweedFS — en lugar de un disco local soldado a un servidor. Las réplicas de cómputo sin estado comparten entonces una sola copia física de los datos mediante replicación de copia cero.

Esto está demostrado, no es una aspiración. En nuestra prueba de escalado horizontal, una tabla de 5 millones de filas cuya política de almacenamiento apunta a S3 informa del disco seaweed en system.parts, y dos nodos de cómputo escalan sobre esa única copia. Añadir un nodo lector no copia los datos; se engancha a ellos. Esa es la propiedad que quieres cuando una carga analítica se dispara y necesitas añadir capacidad de consulta en segundos sin reordenar terabytes.

-- 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 mitad de la memoria, un binario más pequeño

La compilación de la versión aplica optimización guiada por perfiles, optimización ligera en tiempo de enlace y una pasada BOLT posterior al enlace. El resultado es aproximadamente la mitad de la memoria residente de la compilación de serie y un binario sensiblemente más pequeño. Conseguir que BOLT funcionara en aarch64 obligó a desactivar la instrumentación XRay, que venía activada por defecto y bloqueaba en silencio la reescritura posterior al enlace: esa corrección está en el árbol. El efecto práctico: el mismo plan de consulta, menos gigabytes y un binario que arranca más deprisa.

gRPC ha desaparecido

Un almacén de datos debe tener exactamente una vía de consulta, no tres. Hemos eliminado el servidor gRPC por completo — sin contrib/grpc, sin definiciones de servicio protobuf y sin la ruta de compilación ENABLE_GRPC — y, en la misma pasada, hemos borrado el bloque <grpc> muerto de la configuración por defecto para que el producto publicado coincida con la compilación. Datastore habla TCP nativo (9000), HTTP (8123) y replicación entre servidores (9009). Esa es toda la superficie.

El transporte que viene después es ZAP, nuestro RPC derivado de Cap'n Proto. El stub del servidor ya ha aterrizado; todavía no es la vía de consulta en vivo. Preferimos decirte exactamente dónde está esa línea antes que dar a entender que está terminada.

Adónde va la coordinación

Las tablas Replicated* se coordinan hoy mediante Raft embebido, el Keeper compatible con ZooKeeper que viaja dentro del proceso del servidor: ningún demonio aparte. Eso funciona, y es lo que ejecutas en producción ahora.

La dirección es sustituir ese backend de Raft por Quasar, el consenso sin líder y poscuántico de Lux, enlazado de forma nativa en el servidor C++. La juntura es real: un programa C++ ya conduce el motor de consenso nativo a través de su C ABI — abrir una cadena, añadir una entrada al registro de replicación, impulsar los votos de confianza, observar la finalidad — con cero Raft y cero maquinaria de conocimiento cero. Esa es la prueba de que el cambio es un problema de enlazado, no una reescritura. Todavía no es la capa de coordinación de producción, y no vamos a fingir lo contrario.

La otra mitad

Datastore es OLAP. La mitad OLTP de la plataforma es un motor SQL descentralizado construido sobre SQLite/Base: diseñado, en construcción, aún sin publicar. Si quieres hoy la historia de datos local-first y de un solo fichero, ese linaje ya aparece en Hanzo Brain, y el sustrato de almacenamiento sobre el que cabalgan ambas mitades es el que lanzamos en Hanzo Storage.

Ponlo en marcha

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

• Código: github.com/hanzoai/datastore
• Producto: hanzo.ai/datastore
• Documentación: docs.hanzo.ai

La imagen arm64 ya está publicada; la compilación amd64 llega después por CI. Este es el backend de analítica y conocimiento que ejecutamos nosotros: apunta tus eventos hacia él y consúltalos de vuelta a velocidad columnar.