Golpeamos los 6 mil millones de documentos de MongoDB (y sobrevivimos para contarlo)

Golpeamos los 6 mil millones de documentos de MongoDB y sobrevivimos para contarlo

Administrar una base de datos a escala real es una lección que nadie te explica hasta que estás en medio del barro. En Avluz.com superamos los 6.2 mil millones de documentos este año y lo que vino fue una mezcla entre pánico y curiosidad técnica. Empezamos en AWS como casi todo el mundo, pero cuando la factura mensual llegó a 7,500 USD y el rendimiento empezó a degradarse, supimos que había que tomar decisiones drásticas. Migramos a OVH, optimizamos durante cuatro meses con el apoyo de GenSpark AI y hoy pagamos 2,180 USD al mes con mejor rendimiento. Aquí cuento lo que realmente nos pasó y lo que aprendimos.

El momento Oh crap: eran las 2AM, Slack explotando con timeouts, y nuestra colección principal acababa de alcanzar 4.8 mil millones de documentos. Índices que hasta entonces parecían perfectos dejaron de ser útiles. En dos semanas las latencias p95 se fueron a 8 segundos y supimos que había que actuar. Las facturas de AWS dolían, pero ver consultas críticas tardando tanto era lo que realmente nos forzó a movernos.

Por qué cambiamos AWS por OVH: AWS ofrece servicios administrados excelentes, pero cuando ejecutas instancias dedicadas de MongoDB y sabes lo que haces, la diferencia de coste es brutal. Nosotros comparamos especificaciones idénticas: 32 cores, 256 GB RAM por nodo, almacenamiento NVMe. Resultado: AWS 7,500 USD/mes, GCP 6,800 USD/mes y OVH 2,180 USD/mes. La contra es que OVH no te toma de la mano, pero nosotros ya gestionábamos muchas cosas manualmente. Además la red privada vRack de OVH entre servidores es gratis; en AWS estábamos pagando cientos de dólares al mes solo por tráfico de replicación dentro del mismo datacenter.

El desastre del sharding y la recuperación: cuando llegas a miles de millones de documentos, sharding no es opcional. Nuestra primera estrategia fue shardear por user_id porque la mayor parte de las consultas filtraba por ese campo. Error: tenemos power users que generan 10 veces más datos y en pocos días algunos shards estaban a 900 GB y otros a 120 GB. El balancer se volvió loco moviendo chunks y degradando el rendimiento. Tras días de documentación y pruebas, una estrategia de clave compuesta con hash en user_id y timestamp como clave secundaria equilibró la carga. Reshardear 6 mil millones de documentos tomó 72 horas, pero los resultados fueron inmediatos: tamaños de shard mucho más parejos, latencia p95 de 2.4 s a 78 ms y el balancer por fin se calmó.

Auditoría de índices infernal: teníamos 47 índices entre colecciones. Había índices inútiles, redundantes y otros con campos en orden incorrecto para nuestros patrones de consulta. Analizar logs manualmente hubiera sido semanas de trabajo. Tras generar estadísticas y analizar accesos descubrimos que 12 índices no se habían usado en 30 días, 8 eran redundantes y 6 tenían el orden de campos mal planteado. Eliminarlos y reordenar algunos compuestos redujo el almacenamiento de índices de 840 GB a 380 GB y mejoró el rendimiento de escritura en 28 por ciento. Lo que nos llevó cuatro horas con ayuda de automatización nos habría consumido semanas manualmente.

Cuando derretimos la cache: WiredTiger por defecto usa 50 por ciento de la RAM. Con 256 GB por servidor eso deja 128 GB de cache, pero nuestra tasa de aciertos estaba en 72 por ciento y las consultas promediaban 145 ms. Subir la cache a 80 por ciento de RAM mejoró la tasa de aciertos a 94 por ciento, redujo IOPS en disco en 77 por ciento y la latencia a 78 ms. A veces la solución más simple es la que más impacto tiene, siempre con pruebas controladas y reinicios graduales de nodos.

Problemas con pools de conexión: 200 servidores de aplicación con pools de 100 conexiones hicieron que la base de datos intentara manejar 20,000 conexiones simultáneas. MongoDB empezó a rechazar conexiones alrededor de 15,000 y las consultas fallaban aleatoriamente. Reducir el pool por cliente a 25 y ajustar límites de conexiones en MongoDB estabilizó la plataforma: unas 5,000 conexiones totales, CPU 40 por ciento menos y latencias 35 por ciento menores. No necesitas pools gigantescos por defecto, necesitas un tamaño sensible para la concurrencia real.

El dashboard que importa: después de todo esto filtramos el ruido y diseñamos un tablero principal con solo cinco métricas críticas: tiempo de consulta p95, tasa de aciertos de cache, conexiones activas, lag de replicación y espacio en disco por shard. Con esas cinco métricas resolvemos el 95 por ciento de los incidentes a primera vista. El resto de métricas vive en paneles secundarios para investigaciones profundas.

Cómo la IA nos salvó semanas: GenSpark no reemplazó a nuestro equipo, pero actuó como un ingeniero senior disponible 24/7 para chequear ideas, analizar EXPLAINs, proponer claves de shard y optimizaciones de índices. Tareas que habrían sido 7 a 8 semanas de trabajo se comprimieron en una semana y media: optimización de índices, rediseño de esquema, tuning de conexiones y recomendaciones prácticas para consultas complejas. La clave es saber qué preguntar y cuándo.

Cosas raras que nadie te advierte: agregaciones grandes pueden fallar silenciosamente si no permites uso de disco, así que siempre usar allowDiskUse en agregaciones masivas; el balancer puede causar golpes de rendimiento sorprendentes, programar ventanas de balanceo es vital; los backups a esta escala son enormes (nuestro backup completo comprimido ocupa 14.5 TB y una restauración toma 8 horas), así que probar restauraciones regularmente es obligatorio; y el soporte de proveedores económicos requiere que estés preparado para investigar por tu cuenta, que es el tradeoff por reducir costos masivamente.

Qué haríamos distinto: empezar con claves de sharding compuestas y hashadas desde temprano, auditar índices trimestralmente usando $indexStats, integrar herramientas de IA y automatización antes para reducir errores de diseño y considerar proveedores de infraestructura alternativos en cuanto la carga crezca. Para etapas iniciales AWS aporta mucha comodidad, pero a escala real el ahorro puede justificar migrar a soluciones más económicas y manejadas por el equipo.

Sobre Q2BSTUDIO: en Q2BSTUDIO somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con experiencia en inteligencia artificial, ciberseguridad y servicios cloud aws y azure. Ayudamos a empresas a diseñar soluciones escalables, desde arquitecturas de bases de datos hasta agentes IA y proyectos de inteligencia de negocio con Power BI. Si necesitas una solución de desarrollo personalizada visita nuestra página de aplicaciones a medida y software a medida o conoce nuestras capacidades en inteligencia artificial e IA para empresas para ver cómo podemos acelerar tu proyecto.

Conclusión: correr 6 mil millones de documentos nos enseñó que escalar no es cuestión de tener la arquitectura perfecta ni un presupuesto infinito. Es tomar decisiones inteligentes, automatizar y preguntarle a quien te puede dar contexto, incluso si ese apoyo viene de una IA. Monitorea la tasa de aciertos de la cache, audita índices con regularidad, piensa bien tu clave de sharding y ajusta pools de conexión según la concurrencia real. Con esos principios y un buen equipo, la escala deja de ser una pesadilla y pasa a ser una ventaja competitiva.