Como substituímos o Elasticsearch e o MongoDB por Rust e RocksDB

• A Radar fornece uma infraestrutura geoespacial que processa mais de 1 bilhão de requisições de API por dia e migrou do Elasticsearch e MongoDB existentes para o HorizonDB de desenvolvimento próprio para resolver problemas de desempenho e escalabilidade
• O HorizonDB foi desenvolvido em Rust e é um banco de dados geoespacial de alto desempenho que combina várias ferramentas open source, incluindo RocksDB, S2, Tantivy, FST, LightGBM e FastText
• Na arquitetura anterior, os custos e a complexidade de expansão do Elasticsearch e MongoDB eram altos, o que tornava a operação difícil
• O HorizonDB opera com base em um processo único multithread, alcançando redução de custos, melhoria de desempenho e alta confiabilidade
• A produtividade de desenvolvimento e a eficiência operacional melhoraram significativamente, tornando possível a aplicação rápida de novos dados e funcionalidades
• Os dados são pré-processados no Apache Spark e armazenados com versionamento no AWS S3, e os desenvolvedores conseguem executar e testar localmente com facilidade
• Isso permitiu desativar o cluster Mongo e Elasticsearch, reduzir custos substancialmente e melhorar a velocidade de desenvolvimento de recursos e a eficiência de processamento de dados

---

Introdução e contexto

• A Radar é uma plataforma de infraestrutura de geolocalização que processa mais de 1 bilhão de chamadas de API por dia em centenas de milhões de dispositivos em todo o mundo
  • Principais APIs: Geocoding, Search, Routing, Geolocation compliance etc.
• À medida que a escala de dados e de produtos crescia, tornou-se urgente resolver problemas de alto desempenho, escalabilidade e custo
• Para isso, foi introduzido o HorizonDB escrito em Rust, disponibilizando várias funcionalidades de serviços de localização em um único binário de alto desempenho
  • 1.000 QPS por core
  • Latência mediana de geocodificação forward de 50 ms, reverse geocoding <1 ms
  • Escala linear em hardware genérico

Limitações do sistema anterior

• Estrutura anterior: forward geocoding processado pelo Elasticsearch, reverse geocoding pelo MongoDB
• Problemas:
  • O Elasticsearch distribui a consulta em todos os shards e exige atualizações de lote periódicas
  • O MongoDB tem dificuldade com ingestão de lote em larga escala, exige alocação excessiva de recursos e não possui rollback confiável

Objetivos da arquitetura do HorizonDB

• Eficiência - operar em hardware comum, autoescala previsível e funcionar como fonte de dados única para todas as entidades geográficas
• Operabilidade - construir e processar os dados várias vezes ao dia, com mudanças e rollback fáceis, simplificando a operação
• Experiência de desenvolvimento - possível executar no ambiente local, com alterações e testes fáceis

Pilha de tecnologias utilizadas

São utilizadas várias ferramentas open source, incluindo RocksDB, S2, Tantivy, FSTs, LightGBM e FastText; os dados são pré-processados com Apache Spark e salvos no S3 como arquivos com controle de versão em Rust

• Rust

  • Uma linguagem de programação de sistema desenvolvida pela Mozilla
  • Garante segurança de compilação e memória, permitindo gerenciamento de memória de índice de grande escala previsível sem coleta de lixo
  • Suporta abstrações de alto nível como tratamento de nulos e pattern matching, tornando fácil expressar a lógica complexa de ranking de busca
  • Otimizado para um processo único multithread para processar centenas de GB em SSD

• RocksDB

  • Armazenamento in-process de alto desempenho baseado em árvore LSM
  • Resposta em microssegundos e desempenho estável mesmo para grandes volumes de dados

• S2

  • Biblioteca de indexação espacial do Google que acelera consultas ponto-polígono ao dividir a Terra em quadrantes
  • A Radar desenvolveu sua própria binding em Rust da biblioteca S2 em C++, com previsão de publicação open source em breve

• FSTs (Finite State Transducers)

  • Estrutura de dados para compactação eficiente de strings e busca por prefixo
  • Reflete que 80% das consultas seguem a “happy path” regular, permitindo armazenar centenas de milhões de caminhos com poucos MB de memória

• Tantivy

  • Biblioteca de índice reverso em processo semelhante ao Lucene
  • Motivos para adotar em vez de serviço externo como Elasticsearch:
    • Qualidade de busca - resposta a processamento de busca avançado, como expansão dinâmica de palavras-chave, sem latência de comunicação UML
    • Simplificação operacional - processamento dentro de um processo único, e expansão fácil de índices grandes com memory-mapping

• FastText

  • Usa um modelo FastText treinado com corpus e logs próprios para gerar representações vetoriais de palavras e usar em aplicações de ML
  • É robusto contra erros de digitação e termos não registrados, permitindo entendimento semântico de busca por meio da similaridade de significado entre vetores adjacentes

• LightGBM

  • Utiliza vários modelos LightGBM para classificação de intenção da consulta, etiquetagem de atributos na consulta e outros
  • Ex.: consultas regionais como “New York” pulam a busca de endereço; “841 Broadway” pula a busca de POI/região

• Apache Spark

  • Processa centenas de milhões de pontos de dados em menos de 1 hora, com melhoria contínua do desempenho de joins/agregações
  • Os dados finais são armazenados no S3, permitindo exploração de resultados por SQL com ferramentas como Amazon Athena ou DuckDB

Resultados da adoção do HorizonDB

• O serviço ficou consideravelmente mais rápido, com operação simplificada e confiabilidade aprimorada
• A equipe de engenharia consegue aplicar e validar novos dados e funcionalidades em um dia
• Fechamento de clusters de grande escala de Mongo, Elasticsearch e diversos microsserviços, com economia de dezenas de milhares de dólares por mês

• A Radar finalizou a preparação para lidar com uma expansão de grande escala no futuro. O processo de design de funcionalidades específicas será apresentado em um próximo post no blog

[GN⁺]

Comentários do Hacker News

• Senti falta de mais detalhes e fiquei com a impressão de que não há um plano de open source; se você clicou neste post procurando uma alternativa ao ES (ElasticSearch), recomendo typesense.org e duckdb.org (especialmente com o plugin spatial). Os dois serviços têm ótimo desempenho para dados espaciais, e o DuckDB parece ideal até para produção com dados com poucas alterações. Também são totalmente open source mesmo em configurações de cluster/sharding. Não tenho nenhuma relação com isso, é só uma recomendação baseada puramente na minha experiência de uso.

  • Esses dois projetos são realmente excelentes; nossa equipe também usa DuckDB de forma ativa para inspeção de data lake e transformação simples de dados. Em breve, vamos adicionar posts no blog que detalham várias partes do sistema. Decidimos dividir o conteúdo para evitar concentrar muita coisa em um único post, o que pode dificultar a leitura.

  • Sempre fui grato por existirem projetos open source assim, mas integrar isso no meu projeto não pareceu fácil. No passado tentei compilar duckdb, spatial e extensões do SQLite com linkagem estática e percebi que é bem trabalhoso porque o build falhava por causa de símbolos de SQLite de versões diferentes.

  • O DuckDB não tem sharding ou clustering, certo? Não tem servidor separado (a não ser a HTTP Server Extension)

  • O Typesense tem desempenho realmente excelente e a experiência de desenvolvimento também é muito boa.

  • Não sei bem o que faz sentido ser open-sourced: código em Rust? Ele se anuncia como DB, mas parece uma descrição do stack inteiro.

• Achei engraçado que o primeiro benefício no site de vagas seja a "cultura de trabalho no escritório"; fiquei realmente curioso sobre como o deslocamento pode ser um benefício.

  • A diferença entre deslocamento e home office não é só tempo de trajeto; envolve ambiente de trabalho, equilíbrio entre vida pessoal e profissional, entre outros fatores. Na prática, quando o deslocamento fica abaixo de 30 minutos e dá para ir a pé ou de bicicleta, foi uma experiência muito agradável: dá para se exercitar, organizar as ideias e fazer a transição entre casa e trabalho. Quando fiz home office total em 2020, estava ficando cada vez mais difícil trabalhar e descansar no mesmo espaço, e eu me recuperava bastante mentalmente caminhando uma hora por dia após o trabalho. Só que, quando tinha que pegar ônibus/transporte público ou pegar a rodovia por mais de uma hora de ida e volta, foi bem difícil.

  • Penso que, para a cultura de escritório realmente ter vantagens, precisa haver oportunidades de aprender com pessoas inteligentes, fazer amigos, comida/bebidas grátis, uma máquina de DDR etc. Na minha última experiência em escritório, isso não existia e a sensação era de um ambiente triste, uma versão em escala da rotina de trabalhar em casa.

  • Algumas pessoas podem gostar de ir ao escritório; depende de cada pessoa.

  • Eu prefiro deslocamento do que home office; isto é, certamente há gente para quem o "deslocamento é um benefício".

• Fiquei curioso para saber se esse sistema ajudaria no Photon, um mecanismo open source do ElasticSearch/OpenSearch para dados do OSM (OpenStreetMap). A experiência de busca da maioria dos apps de OSM é ruim, e também fraca em erros de digitação, mas o Photon trouxe uma pequena inovação nisso; link do GitHub do Photon

  • Nesse caso, acho que um sistema baseado em LMDB combina melhor do que o RocksDB; aliás, o OSM Express já usa LMDB, link da wiki do OSM Express

• Opinião meio "meta", mas fica bom ver mais uma vez o design de armazenamento próprio ou query engine e posts de blog ganhando fôlego novamente. Em 2010 houve uma onda desse tipo e, recentemente, veio uma tendência de foco em AI.

  • Penso que aquela onda não foi por causa da AI, e sim porque ficou evidente que a maioria não é útil. Como ajustes ou expansão do sistema existente geralmente conseguem atingir o desempenho necessário, no fim uma stack interna hiperespecializada acabou não sendo necessária. Um sistema interno de armazenamento/consulta sem plano de virar produto é, no fim, o famoso síndrome NIH (Not Invented Here) de empresas com excesso de recursos.

  • O hype de NoSQL/bancos de dados alternativos se espalhou um dia como febre, mas acabou diminuindo quando ficou claro que PostgreSQL já é suficiente para a maioria das empresas.

  • Não sei se ainda falta inovação por vir; prefiro produtos confiáveis e validados em vez de storage experimental.

• Achei estranho o próprio título incluir a linguagem "Rust"; penso que leitores podem ficar confusos sobre o que o Rust está substituindo — se é o ElasticSearch ou o MongoDB.

• O artigo é com poucos detalhes; faltam vários pontos-chave, como método de sharding de dados, latência entre indexação e serviço, tratamento de nó com falha, latência em sistemas distribuídos, entre outros.

• Como alguém da área de busca, estou observando com interesse quantas empresas, recentemente, têm como alvo "substituir o ElasticSearch".

  • Sou o autor! Do ponto de vista de operação, fiquei motivado a migrar problemas de "sistema distribuído" para "sistema monolítico"; recentemente considerei que o hardware já dá conta, então escolhi sistemas de storage embutido como RocksDB e Tantivy. O memory-mapped foi suficiente para cobrir cenários globais, e como a nuvem permite expandir RAM livremente, backfill e updates ficam simples: reindexo tudo do zero no novo nó com o mesmo binário e envio para o S3, sem precisar acompanhar separadamente o estado atual de ES/Mongo.

  • Em muitos momentos, o esforço e o tempo para operar e gerenciar um cluster ElasticSearch parecem bem maiores do que os de um banco de dados operacional comum. Por isso, em diversas situações, bate mais forte a vontade de usar uma alternativa mais simples, que oferece apenas um subconjunto do que o ES traz e quebra menos.

• É interessante ver casos de empresas montando um conjunto de soluções que combine exatamente com suas necessidades, e em especial o fato de que elas começam usando ferramentas open source prontas em vez de desenvolver uma solução própria do zero; aliás, o Quickwit me chamou atenção quando conheci o Tantivy. Parece algo similar ao ES baseado em Lucene, link do GitHub do Quickwit

  • É o tantivy :)

• Rocks é fork do Level, e o Level é conhecido por bugs como corrupção de dados. Ambos foram muito usados em produção, mas quando eu usei Level a equipe de operação teve de se esforçar demais para manter o serviço funcionando por causa de tratamento de erros. Esse tipo de post de empresa nunca é completamente honesto ao falar de desvantagens ou problemas sérios de uma stack nova; até o tech talk de empresas de "big name" acaba sendo publicidade da própria história.

  • O RocksDB já se separou do LevelDB há muito tempo e passou por melhorias de escala na indústria e na academia. Agora ele deixou de ser um banco de brinquedo como o LevelDB. Pode haver desvantagens ainda não descobertas, mas acho que é improvável haver algum problema grave no RocksDB.

  • Minha experiência também é diferente: nos últimos 4 anos, rodei RocksDB em milhares de servidores (com alguns terabytes por servidor) e não vi erro nenhum vindo do próprio RocksDB.

• Cliquei porque a keyword Elasticsearch chamou atenção, e achei curioso não conhecer o radar.com; vi uma funcionalidade de autocomplete em um preço que eu considero adequado e fiquei interessado.