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