En solo unos años, el software MongoDB NoSQL ha asumido un papel destacado en el big data. Una razón es que se construyó desde cero para el paralelismo y la escala horizontal, según Dwight Merriman, presidente y cofundador de la empresa. Vio la necesidad de tal paralelismo en una estadía anterior notable en el gigante de anuncios en línea DoubleClick, que también cofundó. Aquí, habla sobre las raíces de MongoDB y hacia dónde se dirige.
Cuando surgió MongoDB en 2007 y las aplicaciones web estaban en pleno apogeo, el desarrollo de software ágil también iba en aumento. Eso significó esquemas de datos más dinámicos. ¿Está bien?
Dwight Merriman: Bueno, si nos fijamos en la forma en que escribimos el código hoy en día, ya no estamos hablando de la gestión del ciclo de vida en cascada, estamos haciendo un desarrollo ágil. Estamos hablando de muchas iteraciones, muchos lanzamientos realmente pequeños. Tenemos un lanzamiento cada día; luego, lo cambiamos. El gerente de producto dice: ‘No, eso no es exactamente lo que quería’, y lo cambiamos una vez más.
Dwight Merriman
Esta noción de iteración tiene implicaciones interesantes para la base de datos y la capa de datos. Si tuviera una migración de esquema nuevo todos los días, sería doloroso. Pero, si tenemos algo fluido en términos de lo que se almacena, eso encaja muy bien con esta noción de iteración. Esa ha sido una buena cola de milano para nosotros, debido a la naturaleza dinámica de MongoDB en términos de esquema.
¿Fue el caso de que las bases de datos establecidas no escalaran de manera efectiva en la Web? ¿Fue la escalabilidad el gran criterio de diseño en la creación de la base de datos?
Merriman: Pienso en MongoDB como una base de datos operativa. Un caso común es que alguien está escribiendo una aplicación y es la tienda de respaldo detrás de ella. Es como OLTP [online transaction processing] con una ‘T’ minúscula. Con eso quiero decir que no tenemos grandes transacciones.
En MongoDB, no tiene una semántica transaccional compleja. Pero puede realizar transacciones atómicas dentro del alcance de un solo documento. Hay algunas nociones sólidas de coherencia en MongoDB. Y eso fue intencional.
Pero lo hicimos de la manera que lo hicimos porque queríamos mucho escalar horizontalmente con máquinas más pequeñas, no escalar verticalmente con máquinas cada vez más grandes.
Cuando inventó esto junto con sus colegas, el almacenamiento en caché se estaba generalizando en la Web. ¿Intentó incorporar algo en ese sentido en la creación de su base de datos?
Merriman: Bueno, en el momento en que comenzamos, hubo dificultades para escalar. Vimos los mismos problemas apareciendo una y otra vez. Las arquitecturas informáticas estaban cambiando. Las velocidades del reloj no subían. La forma en que escalamos en estos días es diferente, es más a través del paralelismo.
Sabes, el almacenamiento en caché a veces es muy válido. Pero se estaba convirtiendo en una muleta. La base de datos era demasiado lenta. Para nosotros fue una señal. La gente tenía 30 servidores de caché, cada uno con tanta RAM, ¿por qué no 30 servidores de base de datos, cada uno con tanta RAM?
Aún así, el software altamente agrupado no es fácil de configurar. La gente quiere ser como Google, pero eso puede ser difícil a medida que crece el grupo de máquinas.
Merriman: Una gran prioridad ahora en nuestra I + D son las operaciones de solución alternativa, lo que facilita a DevOps, DBA, administradores de sistemas, esa esfera de TI. Necesita automatización porque hay muchas máquinas. Por lo tanto, estamos escribiendo MongoDB Service Suite, que tiene capacidades de monitoreo, software de respaldo y software de automatización para la implementación.
Jack Vaughan es el editor de noticias y sitios de SearchDataManagement. Envíele un correo electrónico a [email protected]y síguenos en Twitter: @sDataManagement.
