- Radar proporciona una infraestructura de geoinformación que procesa más de mil millones de solicitudes API al día y migró de Elasticsearch y MongoDB a su propio HorizonDB para resolver problemas de rendimiento y escalabilidad
- HorizonDB fue desarrollado en Rust y es una base de datos geoespacial de alto rendimiento que combina varias herramientas de código abierto como RocksDB, S2, Tantivy, FST, LightGBM y FastText
- En la arquitectura anterior, el costo y la complejidad de escalar Elasticsearch y MongoDB eran elevados, lo que complicaba la operación
- HorizonDB funciona sobre un proceso único multihilo, logrando ahorro de costos, mejor rendimiento y alta confiabilidad
- En general, la productividad de desarrollo y la eficiencia operativa mejoraron significativamente, lo que permitió la implementación rápida de nuevos datos o funcionalidades
- Los datos se preprocesan con Apache Spark y luego se guardan en AWS S3 por versión; además, los desarrolladores pueden ejecutar y probar fácilmente en entorno local
- Gracias a esto, se desactivaron los clústeres de Mongo y Elasticsearch, reduciendo costos de forma significativa y mejorando la velocidad de desarrollo de funcionalidades y la eficiencia de procesamiento de datos
Presentación y antecedentes
- Radar es una plataforma de infraestructura de geolocalización que procesa más de mil millones de llamadas API al día desde cientos de millones de dispositivos en todo el mundo
- APIs principales: Geocoding, Search, Routing, Geolocation compliance, entre otras
- A medida que aumentaban los volúmenes de datos y la expansión del producto, se volvió urgente resolver los problemas de alto rendimiento, escalabilidad y costo
- Para ello, implementaron HorizonDB en Rust, que ofrece múltiples funcionalidades de servicios de ubicación desde un único binario de alto rendimiento
- Capacidad de 1,000 QPS por núcleo
- Latencia media de geocodificación directa de 50ms, geocodificación inversa <1ms
- Escalado lineal en hardware de propósito general
Limitaciones del sistema anterior
- Estructura previa: la geocodificación directa se procesaba con Elasticsearch y la inversa con MongoDB
- Problemas:
- Elasticsearch distribuía cada consulta en todos los shards y requería actualizaciones batch periódicas
- MongoDB tenía dificultades con cargas masivas por lotes, asignación excesiva de recursos y carecía de una función de rollback confiable
Objetivos de la arquitectura de HorizonDB
- Eficiencia: operar en hardware estándar, escalado automático predecible y actuar como fuente única de datos para todas las entidades geográficas
- Operabilidad: construir y procesar activos de datos varias veces al día, facilitar cambios y rollbacks, simplificar la operación
- Experiencia de desarrollo: ejecutable en entornos locales, con cambios y pruebas sencillos
Stack tecnológico utilizado
Se utilizan varias soluciones open source como RocksDB, S2, Tantivy, FSTs, LightGBM y FastText; los datos se preprocesan con Apache Spark y se almacenan en S3 como archivos versionados desde Rust
-
Rust
- Lenguaje de programación de sistemas desarrollado por Mozilla
- Garantiza compilación y seguridad de memoria, y permite gestionar de manera predecible la memoria de índices a gran escala sin recolección de basura
- Soporta abstracciones de alto nivel como manejo de valores nulos y pattern matching, facilitando expresar de forma sencilla una lógica compleja de ranking de búsqueda
- Optimizado para procesar cientos de GB de datos en SSD con un proceso único multihilo
-
RocksDB
- Almacenamiento embebido de alto rendimiento basado en árboles LSM
- Respuestas a nivel de microsegundos y velocidad estable incluso con grandes volúmenes de datos
-
S2
- Biblioteca de indexación espacial de Google que divide la Tierra en cuadrantes para acelerar consultas punto-polígono
- Radar desarrolló su propio binding de Rust para la biblioteca C++ de S2 y planea publicarlo como código abierto próximamente
-
FSTs (Finite State Transducers)
- Estructura de datos de compresión eficiente de cadenas y búsqueda por prefijo
- Se aprovecha de que el 80% de las consultas sigue el “happy-path” regular, permitiendo cachear millones de rutas en solo unos MB de memoria
-
Tantivy
- Librería de índice invertido embebida similar a Lucene
- Motivos para elegirla en lugar de un servicio externo como Elasticsearch:
- Calidad de búsqueda: permite responder a búsquedas avanzadas como la expansión dinámica de palabras clave sin latencia de comunicación UML
- Simplificación operativa: procesamiento dentro de un solo proceso, expansión sencilla de índices grandes mediante memory mapping
-
FastText
- Utiliza un modelo FastText entrenado con su propio corpus y logs para generar representaciones vectoriales de palabras y usarlas en aplicaciones de ML
- Es robusto frente a errores tipográficos y palabras fuera de vocabulario, y mediante la similitud semántica entre vectores adyacentes permite lograr comprensión semántica de búsqueda
-
LightGBM
- Usa múltiples modelos LightGBM para clasificación de intención de consulta, etiquetado de atributos dentro de la consulta, entre otros
- Ej.: consultas de ubicación como “New York” omiten la búsqueda de direcciones, y en casos como “841 Broadway” se omite la exploración de POI/región
-
Apache Spark
- Procesa cientos de millones de puntos de datos en menos de 1 hora, mejorando continuamente el rendimiento de joins y agregaciones
- Los datos finales se guardan en S3, donde pueden explorarse resultados con base en SQL mediante Amazon Athena, DuckDB, entre otros
Resultados de la adopción de HorizonDB
- El servicio se volvió muy más rápido, con operaciones más simples y mejor confiabilidad
- El equipo de desarrollo puede aplicar y evaluar nuevas funciones y fuentes de datos en un solo día
- Se cerraron clústeres de gran escala como Mongo y Elasticsearch y varios microservicios, ahorrando decenas de miles de dólares mensuales
- Radar ya está preparado para afrontar una expansión a gran escala. El diseño de funcionalidades específicas se presentará en un blog posterior
Aún no hay comentarios.