Espresso (LinkedIn)
in Posts
Espresso es una base de datos NoSQL altamente distribuida con tolerancia ante fallos para diferentes servicios de LinkedIn. Usa cerca de 100 clusters, almacenando unos 420 terabytes de datos de la fuente de verdad (Source of Truth en inglés) y manejando más de dos millones de queries por segundo en los picos de carga.
LinkedIn decidió migrar uno de sus servicios internos (Babylonia) de usar Oracle a Espresso, con el requerimiento principal de mantener corriendo Babylonia ininterrumpido en producción durante la migración para que esta transición no afectase a los usuarios finales. El uso del modelo relacional (Oracle) era poco adecuado para resolver el problema planteado con Babylonia porque a medida que el sistema crecía, ellos estaban almacenando más datos en la base de datos y lanzando más queries contra ella. Los trabajos (jobs) periódicos que necesitaban para correr las tablas de la base de datos se estaban volviendo pesados.
LinkedIn buscaba mayor escalabilidad sin la necesidad de adquirir más licencias o contratar a más administradores de Oracle. Migrar significaba resolver sus problemas inmediatos de escalabilidad así como reducir costes para LinkedIn mientras construían su propia plataforma interna (Espresso).
Es recomendable Espresso (modelo de base de datos NoSQL como solución) porque ofrece un mejor rendimiento, disponibilidad y escalabilidad. Una vez se creó la base de datos Espresso vacía con el nuevo esquema de datos, lo que hicieron fue cargarla con todos los datos en Oracle y con los cambios en tiempo real como espejo. Se dividieron el trabajo (job) en dos partes: para la carga inicial a Espresso se usaron capturas de la base de datos relacional traduciendo todos los registros (records) del formato de Oracle al de Espresso, y haciendo un volcado de records a Espresso. Esta copia funcionó pero se perdieron las actualizaciones que tuvieron lugar después de la captura.
Para manejar los cambios recientes y en tiempo real de la base de datos relacional, implementaron un Databus listener. Cada cambio en la base de datos relacional genera un mensaje en el Databus. Este listener consume esos mensajes y los traduce en escritos (writes) dentro de Espresso. Después de completar esta carga, hicieron rolled back del listener para consumir los eventos empezando por el timestamp del final de la captura del ETL. El listener continuaría replicando las actualizaciones que sucedieran hacia Espresso en cuestión de segundos. Para validar que los datos que vivían en Espresso se alineaban con los de Oracle, añadieron una sombra de lectura para su validación monitoreando cualquier petición procesada por Babylonia y siendo procesada al mismo tiempo por Espresso para comparar resultados. Cualquier discrepancia se etiquetaba para investigarlo. Una vez confirmaron las coincidencias, permitieron a Babylonia escribir a Espresso directamente mientras lo hacía también a Oracle. Para evitar duplicados e inconsistencia en datos, añadieron un campo adicional al esquema de datos de Espresso llamado MigrationControl. Cuando el proceso llama a Espresso lo hace en forma de un bulk loader, databus listener o Babylonia. Ellos añadieron lógica que examina el campo de MigrationControl para validar teniendo un record existente. Si el databus listener encuentra que el record ha sido escrito recientemente en Babylonia, aborta la operación. Ellos entonces pueden atacar los datos corruptos redefiniendo la lógica para permitir el databus listener o al bulk uploader sobreescribir en Babylonia.
Declararon esta nueva base datos NoSQL como fuente de verdad haciendo que el servicio de Babylonia lea peticiones solo de Espresso. Aunque Babylonia ya no es dependiente de Oracle en este punto, LinkedIn aún no puede cargarse la base de datos relacional hasta que los otros sistemas/servicios de LinkedIn que usan el Oracle Databus y las capturas ETL se hayan migrado a Espresso.
El número de datos a almacenar y procesar de LinkedIn es cada vez mayor y se decidió que no era la base de datos relacional el mecanismo más adecuado para procesar estos tipos de datos en este contexto de alta distribución. Espresso engloba una serie de características que la hacen mejor diseñada para crecer de forma horizontal siendo más versátil y aumentando su disponibilidad. No obstante, cabe destacar que Oracle como base de datos relacional continúa siendo útil en algún caso dentro de LinkedIn.
Fuentes consultadas:
- Migrating to Espresso: https://engineering.linkedin.com/blog/2017/08/migrating-from-oracle-to-espresso
- Data Infrastructure at LinkedIn: http://www.pitt.edu/~viz/classes/infsci3350/resources/linkedin_icde12.pdf
- On Brewing Fresh Espresso: LinkedIn’s Distributed Data Serving Platform https://www.cs.cmu.edu/~pavlo/courses/fall2013/static/papers/p1135-qiao.pdf
