- 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
1 comentarios
Comentarios de Hacker News
Me da pena que parezca que faltan detalles y que no haya un plan de código abierto, y si llegaste a este artículo buscando una alternativa a ES (Elasticsearch), te recomendaría typesense.org y duckdb.org (especialmente con el plugin spatial). Ambas ofrecen muy buen rendimiento con datos geoespaciales, y DuckDB parece ideal para usar en producción con datos que cambian poco; también es completamente open source incluso en configuraciones de clúster/sharding. No tienen relación entre sí, solo es una recomendación basada en experiencia propia.
Estos dos proyectos son excelentes. Nuestro equipo también usa DuckDB activamente para inspecciones de data lake y transformaciones simples de datos. Planeamos publicar más entradas de blog que detallen distintas partes del sistema; decidimos repartir el contenido porque si concentramos demasiado en una sola publicación, cuesta más leerla.
Siempre es agradable ver que existan proyectos de código abierto así, pero integrar algo así en mi proyecto no parece tan fácil. En el pasado intenté compilar enlazando estáticamente duckdb, spatial y extensiones de SQLite, y descubrí que era complejo porque los símbolos de SQLite tenían versiones diferentes.
¿DuckDB realmente no tiene sharding ni clustering? Tampoco tiene un servidor separado (salvo la extensión HTTP Server Extension).
Typesense tiene un rendimiento excelente y la experiencia de desarrollo es realmente satisfactoria.
No estoy seguro de qué es lo que se vuelve open source; ¿el código en Rust? Aunque se declara como BD, da la sensación de que describe todo el stack.
Me parece gracioso que una página de reclutamiento destaque como primer beneficio la 'cultura de trabajo en oficina'; realmente me intriga cómo puede considerarse un beneficio el desplazamiento diario.
Ir a la oficina vs. trabajar remoto no solo depende del tiempo de traslado, sino de muchos otros factores como el entorno de trabajo y el equilibrio entre vida personal y laboral. En mi experiencia, cuando el commute era de 30 minutos o menos y podía hacerlo caminando o en bici, era una experiencia muy agradable: hacías ejercicio, ordenabas ideas y marcabas la transición entre casa y trabajo. En 2020, cuando estaba en remoto completo, con el tiempo se volvió cada vez más difícil trabajar y descansar en el mismo lugar, así que caminaba una hora todos los días después de salir de la oficina para recuperar energía mentalmente; sin embargo, cuando el viaje a casa y de regreso duraba más de una hora en transporte público o autopista, sí era duro.
Para que la cultura de oficina sea realmente una ventaja, creo que debe haber oportunidades de aprender con gente inteligente, hacer amigos, comida/bebidas gratis y cosas como una máquina DDR. En mi última experiencia de oficina no había ninguna de esas ventajas y era un ambiente gris, como una versión amplificada de trabajar desde casa.
A algunas personas les puede gustar ir a la oficina; depende de cada uno.
Yo prefiero el traslado al trabajo sobre el trabajo remoto; es decir, ciertamente hay personas para quienes el 'viaje al trabajo' sí se percibe como beneficio.
Me pregunto si este sistema podría ayudar al motor Photon (open source) de Elasticsearch/OpenSearch para datos de OSM (OpenStreetMap). En la mayoría de apps de OSM la experiencia de búsqueda no es buena y es débil ante errores de tipeo, pero Photon trae una pequeña innovación allí: Enlace de GitHub de Photon
Desde una perspectiva más general, me alegra ver de nuevo que se reactiven las publicaciones sobre diseño de almacenes de datos o motores de consulta propios; en los 2010 hubo un auge similar y últimamente la atención se centró en IA.
Creo que ese auge no fue por IA, sino porque al final se demostró que la mayoría de esas ideas no servían mucho. Si puedes ajustar o extender un sistema existente para alcanzar el rendimiento necesario, un stack propietario excesivamente especializado termina no siendo realmente necesario. Un sistema interno de almacenamiento/consulta que no esté pensado para venderse como producto acaba siendo, en empresas con recursos, el síndrome NIH (Not Invented Here).
Las bases de datos NoSQL/alternativas se expandieron un tiempo como moda; luego se fue enfriando cuando quedó en evidencia que para la mayoría de las compañías una sola Postgres era suficiente.
No sé si aún queda espacio para innovar; prefiero productos confiables y comprobados en lugar de almacenamientos de datos experimentales.
Me parece extraño que el propio título incluya el lenguaje "Rust"; como lector, alguien podría confundirse sobre qué reemplaza Rust: si Elasticsearch o MongoDB.
Al artículo le falta mucha información de detalle: por ejemplo, el método de sharding de datos, el desfase entre indexado y servicio, el manejo de nodos fallidos y la latencia en sistemas distribuidos, entre otros puntos clave.
Desde el punto de vista de búsqueda, es interesante observar cuántas empresas últimamente tienen como objetivo "reemplazar Elasticsearch".
Yo soy la persona que escribió el post. Desde el lado operativo, lo que me motivó fue pasar de los problemas de un "sistema distribuido" a un "sistema monolítico"; y al creer que hoy en día el hardware era suficiente, optamos por sistemas de almacenamiento embebidos como RocksDB y Tantivy. Gracias al memory mapping pudimos cubrir situaciones globales, y al ser la nube tan flexible para escalar RAM, el backfill y las actualizaciones de datos eran simples: en lugar de preocuparse por mantener estado sincronizado aparte de ES/Mongo, se reindexaba todo en un nuevo nodo con el mismo binario y luego se enviaba a S3.
He tenido varias veces la sensación de que el esfuerzo y el tiempo para operar y administrar un clúster de ElasticSearch son mucho mayores que con una base de datos de operación normal, y por eso en muchos escenarios quiero usar alternativas más simples, con menos cosas que puedan romperse, ofreciendo solo unas pocas funcionalidades en vez de todo ElasticSearch.
Es interesante ver cómo muchas compañías combinan soluciones que les quedan bien. Lo veo positivo que hayan empezado a trabajar con herramientas open source comerciales en lugar de desarrollar desde cero su propia solución. Por cierto, al conocer Tantivy, me llamó la atención Quickwit, que se siente similar a ES basado en Lucene: Enlace de GitHub de Quickwit
RocksDB es un fork de Level, y Level es conocido por errores como corrupción de datos. Ambos se usaron mucho en producción, pero cuando yo usé Level, el equipo de operaciones se rompía el lomo corrigiendo errores para mantener el servicio. Los posts de blog de este tipo nunca explican con honestidad las desventajas o incidencias graves de un stack nuevo; el tech talk de una 'gran empresa' termina siendo publicidad de su propia historia.
RocksDB se separó de LevelDB hace tiempo y hoy tiene mejoras a gran escala en la industria y academia; ya no lo veo como una BD de juguete como LevelDB. Es posible que haya desventajas que aún no se hayan detectado, pero creo que la probabilidad de un problema 'grave' en RocksDB es baja.
Mi experiencia también es distinta: durante 4 años ejecuté RocksDB en miles de servidores (terabytes por servidor), y nunca vi un error en RocksDB.
Hice clic por la palabra clave Elasticsearch y me sorprendió no conocer radar.com; llamó mi atención porque vi una función de autocompletado a un precio razonable para lo que necesito.