Entre na beta da Hanzo e ganhe 50% de desconto em qualquer plano pago

Chegou o Hanzo Datastore: um motor OLAP pronto para o pós-quântico

Um armazém colunar derivado do ClickHouse, reconstruído em torno da separação entre armazenamento e computação no Hanzo S3, otimizado por perfil e em tempo de link até cerca de metade da memória, sem gRPC e com um caminho para a coordenação pós-quântica sem líder.

Nesta página

Hoje lançamos o Hanzo Datastore — a metade OLAP da plataforma de dados de Hanzo. É um fork do ClickHouse 26.6, sem a marca de origem e reconstruído em torno de como realmente rodamos a análise: armazenamento separado da computação no Hanzo S3, um binário otimizado mais enxuto e a superfície RPC antiga removida. A imagem já está no ar em ghcr.io/hanzoai/datastore:26.6.1.1.

Não escrevemos um banco de dados novo. O ClickHouse é o melhor motor colunar do mundo e nos apoiamos nele. O que mudamos são as partes que importam para rodar uma frota: o substrato de armazenamento, o build, o transporte e o roteiro da coordenação.

Armazenamento e computação, separados

As partes de uma tabela MergeTree são objetos imutáveis. O Datastore as guarda como objetos no Hanzo S3 — nossa camada de armazenamento derivada do SeaweedFS — em vez de um disco local soldado a um servidor. Réplicas de computação sem estado compartilham então uma única cópia física dos dados por replicação zero-copy.

Isso está provado, não é uma aspiração. No nosso teste de scale-out, uma tabela de 5 milhões de linhas cuja política de armazenamento aponta para S3 informa o disco seaweed em system.parts, e dois nós de computação escalam sobre essa única cópia. Adicionar um nó de leitura não copia os dados; ele se acopla a eles. Essa é a propriedade que você quer quando uma carga analítica dispara e você precisa somar capacidade de consulta em segundos, sem remexer 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   │
-- └───────────┴───────────┘

Metade da memória, um binário menor

O build de release roda otimização guiada por perfil, otimização enxuta em tempo de link e uma passagem BOLT depois do link. O resultado é cerca de metade da memória residente do build padrão e um binário bem menor. Fazer o BOLT funcionar em aarch64 exigiu desligar a instrumentação XRay, que vinha ligada por padrão e bloqueava em silêncio a reescrita pós-link — essa correção está na árvore. O efeito prático: o mesmo plano de consulta, menos gigabytes e um binário que sobe mais rápido.

O gRPC saiu

Um datastore deve ter exatamente um caminho de consulta, não três. Removemos o servidor gRPC por completo — sem contrib/grpc, sem definições de serviço protobuf, sem caminho de build ENABLE_GRPC — e na mesma passagem limpamos o bloco <grpc> morto da configuração padrão, para que o produto entregue combine com o build. O Datastore fala TCP nativo (9000), HTTP (8123) e replicação entre servidores (9009). Essa é toda a superfície.

O transporte daqui para a frente é ZAP, nosso RPC derivado do Cap'n Proto. O stub do servidor já chegou; ainda não é o caminho de consulta ao vivo. Preferimos dizer exatamente onde essa linha está, em vez de insinuar que está pronta.

Para onde a coordenação caminha

As tabelas Replicated* hoje se coordenam por Raft embutido, o Keeper compatível com ZooKeeper que vem dentro do processo do servidor — sem um daemon separado. Isso funciona, e é o que você roda em produção agora.

A direção é trocar esse backend Raft pelo Quasar, o consenso sem líder e pós-quântico do Lux, ligado de forma nativa no servidor C++. A junção é real: um programa C++ já conduz o motor de consenso nativo pela sua C ABI — abrir uma cadeia, anexar uma entrada do log de replicação, conduzir votos de confiança, observar a finalidade — com zero Raft e zero maquinaria de zero-knowledge. Essa é a prova de que a troca é um problema de linking, não uma reescrita. Ainda não é a camada de coordenação de produção, e não vamos fingir o contrário.

A outra metade

Datastore é OLAP. A metade OLTP da plataforma é um motor SQL descentralizado construído sobre SQLite/Base — desenhado, em construção, ainda sem lançamento. Se você quer hoje a história de dados local-first e de um único arquivo, essa linhagem já aparece em Hanzo Brain, e o substrato de armazenamento em que as duas metades rodam é o que lançamos em Hanzo Storage.

Rode

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

A imagem arm64 está publicada agora; o build amd64 vem em seguida pela CI. Este é o backend de análise e insights que nós mesmos rodamos — aponte seus eventos para ele e consulte-os de volta em velocidade colunar.

Comentários

Entre com seu Hanzo ID para comentar.

Carregando comentários…

Leia mais