El escenario infantil del afiche para big data:necesita filtrar una gran cantidad de datos para extraer una pequeña " pepita” de información. Además, debe hacerse en el menor tiempo posible, tu negocio depende de ello. Históricamente, al utilizar la tecnología tradicional del sistema de administración de bases de datos relacionales (RDBMS), este tipo de escenario requería un gran equipo y una inversión de tiempo y dinero. La mayoría de los RDBMS tradicionales solo se escalan verticalmente, por lo que debe seguir comprando máquinas cada vez más grandes para reducir el tiempo de respuesta. La llegada de las nubes públicas y las bases de datos NoSQL como MongoDB ha revolucionado por completo la forma en que los equipos están pensando en este escenario.
Uno de nuestros clientes se acercó recientemente a nosotros con un problema interesante. Periódicamente necesitaban ejecutar una consulta realmente compleja que escaneaba todo su conjunto de datos. Esta consulta fue más o menos un análisis de la colección que tocó todos los documentos de la colección e incluyó estos detalles:
- El total de datos fue de aproximadamente 100 GB.
- La seguridad de los datos no fue un problema ya que la copia maestra de los datos residía en otro lugar.
- La velocidad de consulta era extremadamente importante. El objetivo era poder ejecutar la consulta completa en 10 a 15 minutos.
- El sistema necesitaba estar activo solo cuando la consulta se está ejecutando (minimizar el costo).
Debido al último requisito, tenía sentido ejecutar todo el sistema en una nube pública. Las máquinas se encienden solo unas pocas horas cada semana para que los datos se actualicen y se ejecute la consulta. El cliente ya se sentía cómodo con Amazon EC2, por lo que se tomó la decisión de crear un prototipo del sistema en AWS.
La mejor configuración para lograr este objetivo fue una implementación de MongoDB "fragmentada". Esta es la configuración que decidimos:
- 3 fragmentos:cada fragmento tiene una instancia independiente (r3.xlarge) con 30 GB de RAM
- 1 servidor de configuración
- 1 enrutador de fragmentos (m3.xlarge) con 15 GB de RAM
Un par de cosas para señalar sobre nuestras elecciones:
-
Conjunto independiente o réplica
La seguridad de los datos no es un requisito importante aquí, ya que los datos maestros se almacenan en un sistema separado. Por lo tanto, elegimos servidores independientes en lugar de un conjunto de réplicas para ahorrar costos.
-
3 servidores de configuración frente a 1 servidor de configuración
una razón como la anterior. La seguridad de los datos no es un tema importante. En un entorno de producción típico, habríamos optado por tres servidores de configuración.
La verdadera belleza de esta configuración es que, debido a la configuración fragmentada, casi todos los 100 GB de datos se almacenan completamente en la memoria. Entonces, esencialmente lo que está ejecutando es un escaneo "en memoria". Esto redujo drásticamente el tiempo de ejecución de la consulta de unas pocas horas a menos de 10 minutos. El uso de la nube pública también redujo drásticamente la inversión de capital, ya que solo paga por las máquinas cuando están en funcionamiento.
Este es un cambio bastante dramático en la forma en que los equipos han estado manejando este escenario durante la última década. Entonces, si está en el negocio de "encontrar una aguja en un pajar", ¡piense en Cloud + NoSQL!
Como siempre, si tiene alguna pregunta, puede comunicarse con nosotros en [email protected].
