Diseño de arquitectura API para lecturas rápidas de archivos de texto con etiquetas únicas de 150 m

Question

Suponga un archivo de texto con 150 millones de registros únicos.

Cada registro tiene dos columnas: (1) cadena y (2) entero.

La cadena es una etiqueta única y el número entero es el valor de la etiqueta.

La única consulta devolverá el valor entero para una etiqueta determinada.

Estamos explorando múltiples arquitecturas para exponer este archivo de texto como una API.

Este archivo de texto se regenera cada 72 horas. ~ 90% de los datos siguen siendo los mismos durante la regeneración, pero esta regeneración está controlada por un tercero. Simplemente obtenemos un nuevo archivo de texto cada 72 horas.

Nuestro objetivo es un rendimiento de consulta de 100 ms - 500 ms por lectura.

Arquitectura 1

• Guarde el archivo de texto en el disco. Consulta el archivo de texto. Caché las consultas en la memoria.
• Ventajas: Implementación simple. Fácil actualización de datos.
• Contras: Inelegant. Las consultas de lectura sin caché son lentas.

Arquitectura 2

• Analice el archivo de texto en una base de datos tradicional / NoSQL, con cada línea tratada como un registro / documento de base de datos. Ejecute consultas en la base de datos.
• Ventajas: parece una arquitectura estándar.
• Contras: Actualizar 150 millones de registros de bases de datos es lento y parece un desperdicio, especialmente porque ~ 90% de los registros siguen siendo los mismos.

Arquitectura 3

• Utilice Redis o la base de datos en memoria para almacenar el archivo de texto de 5GB. Ejecute consultas contra la base de datos en memoria.
• Ventajas: Consultas rápidas. Fácil actualización de datos.
• Desventajas: Caro.

Arquitectura 4

• Utilice ElasticSearch para consultar registros.
• Ventajas: ElasticSearch está diseñado para búsquedas.
• Contras: ES puede ser excesivo para consultas tan simples.

Preguntas:

1. ¿Deberíamos considerar otras arquitecturas o hay pros y contras que pasamos por alto?

2. Este desafío de ingeniería parece común: ¿cuál es la arquitectura más "estándar" para equilibrar costo / rendimiento cuando se intenta producir lecturas rápidas con un almacén de datos de 150 millones de registros que cambian?

Answer 1

En términos generales, esto parece un caso clásico para un flujo ETL: obtenga el nuevo archivo, extraiga los datos, transfórmelos a su formato y cárguelo en su base de datos. Algunas notas:

1. Lo importante que hay que recordar es que la carga y la consulta son operaciones diferentes y sin ninguna relación. Una pregunta es "cómo cargo de manera eficiente un archivo de registro diario de 150 m en un almacén de datos cuando el 90% de los registros son duplicados", y la otra es "cómo consulto un almacén de claves / valores de 150 m de manera eficiente". Responda estas dos preguntas por separado, porque son independientes.

2. Para su primera pregunta, le preocupa que cargar registros idénticos al 90% sea un desperdicio. ¿Ha medido el tiempo que tarda? La lectura de 150 millones de registros de un archivo de texto debería llevar unos segundos , y un buen almacén de claves / valores debería poder optimizar las operaciones de ACTUALIZACIÓN redundantes. Alternativamente, compare el nuevo archivo con el anterior para crear una lista de cambios real como parte de su flujo ETL, luego proceda a cargar. Defina métricas para esta solución (tiempo total de lectura, diferencia, carga, interrupción de la operación de consulta durante la carga, etc.) para que pueda evaluar su solución.

3. Para la pregunta n. ° 2, evite implementar soluciones personalizadas cuando existan opciones listas para usar. ElasticSearch puede ser excesivo porque solo está almacenando números enteros con clave, pero hay muchas tiendas clave / valor que le brindarán un buen rendimiento para las lecturas, incluido el almacenamiento en caché de memoria respaldada en disco, almacenamiento en caché MRU o diferentes estrategias de almacenamiento en caché según su uso. quizás la operación UPDATE sin operación mencionada anteriormente, y más. Nuevamente, como en la pregunta # 1, defina métricas para el éxito. Dijiste "cargar 5 GB en RAM es caro. ¿Lo es? ¿Cuánta RAM tiene tu servidor? Consideras almacenar en caché las consultas comunes. ¿Es necesario? ¿Qué tan rápido son las lecturas no almacenadas en caché? ¡Mide! ¿Necesitas una estrategia de almacenamiento en caché personalizada como almacenar en caché los registros relacionados? ? Examine su patrón de uso.

No puedo decirte cuál es el mejor enfoque. Hay demasiadas variables que solo usted conoce: su presupuesto y su patrón de uso, planes futuros para el sistema y potencial de extensibilidad, relación con fuentes de datos de terceros (p. Ej., ¿Se les puede convencer para que generen solo diferencias o agregue marcas de tiempo / etiquetas de versión? para registros, etc.). Todo lo que puedo hacer es sugerir patrones centrales: separar los flujos de ingestión de los flujos de consulta, usar herramientas probadas y, sobre todo, medir, medir y medir.

Answer 2

Puede considerar el enfoque adoptado por el cdb de DJBernstein , que es:

cdb es un paquete simple, rápido y confiable para crear y leer bases de datos constantes. Su estructura de base de datos proporciona varias características:

Búsquedas rápidas: una búsqueda exitosa en una base de datos grande normalmente requiere solo dos accesos al disco. Una búsqueda fallida solo requiere una.

Baja sobrecarga: una base de datos usa 2048 bytes, más 24 bytes por registro, más el espacio para claves y datos.

Sin límites aleatorios: cdb puede manejar cualquier base de datos de hasta 4 gigabytes. No hay otras restricciones; los registros ni siquiera tienen que caber en la memoria. Las bases de datos se almacenan en un formato independiente de la máquina.

Reemplazo rápido de bases de datos atómicas: cdbmake puede reescribir una base de datos completa dos órdenes de magnitud más rápido que otros paquetes hash.

Volcados rápidos de base de datos: cdbdump imprime el contenido de una base de datos en formato compatible con cdbmake.

cdb está diseñado para usarse en aplicaciones de misión crítica como el correo electrónico. El reemplazo de la base de datos es seguro contra fallas del sistema. Los lectores no tienen que hacer una pausa durante una reescritura.

Probablemente querrás una implementación más moderna, que no tenga el límite de 4GiB, como esta .