Os nossos métodos de arquivamento @solana são até 20x mais rápidos do que qualquer outra coisa no mercado. Tornámos todo o stack de código aberto. Adicione aos favoritos isto 🔖 As consultas de arquivamento na Solana são notoriamente lentas e pouco fiáveis: blocos em falta, respostas atrasadas, dados perdidos. Aqui está como o resolvemos 🧵

A pilha de arquivamento padrão do Solana (Bigtable + nós RPC de validador) é fácil de implantar, mas difícil de escalar. É intensiva em CPU, consome muita memória e tem dificuldades com grandes solicitações em lote. Os dados históricos são onde a latência atinge o pior.

Tentámos otimizar o Bigtable. Adicionámos tabelas personalizadas, ajustámos consultas, levámo-lo ao limite. Mas cada alteração exigia reinícios completos dos nós. 30 minutos a várias horas cada vez. Por isso, descartámos tudo e reconstruímos tudo: ingestão, armazenamento e servidor RPC.

A nova pilha: → ArchivalRPC: inicia em segundos, não em horas. Escala para 200K RPS. → Ingestor personalizado: ingestão seletiva para reduzir custos e pontos de falha. → HBase sobre Bigtable: auto-hospedado, co-localizado, latência quase zero.

A velocidade não significa nada se os dados estiverem errados. Construímos uma ingestão tripla verificada: cada registro é escrito duas vezes, validado programaticamente e continuamente escaneado. Se uma lacuna for detectada, pipelines de auto-reparo re-ingestam e corrigem automaticamente.

O resultado, por região: • 100.000 RPS para getTransaction • 50.000 RPS para getSignaturesForAddress • 2.000 RPS para getBlock Até 20x mais rápido do que qualquer outra solução no mercado.