Utilización del servidor: Couchbase vs MongoDB

Cuando empecé a utilizar MongoDB en 2012 como responsable de operaciones y arquitectura, tenía algunos problemas clave con su arquitectura. Con el paso del tiempo, he observado que otros tienen problemas similares. Un problema fundamental es que MongoDB no utiliza plenamente la potencia de los servidores/instancias que tiene, por diseño. Odio aprovisionar tres buenos servidores/instancias, pero luego la aplicación sólo utiliza realmente una fracción de los recursos. Eso es lo que hace MongoDB. Sólo puedes escribir en el primario de un conjunto de réplicas. Entonces para escalar las lecturas, tienes que leer desde los nodos secundarios, y esas lecturas pueden ser eventualmente consistentes. Si debes tener consistencia total, sólo puedes interactuar con el nodo primario de un conjunto de réplicas.

Couchbase, por otro lado, te permite escalar hacia fuera, hacia arriba, o ambos. No tendrás servidores infrautilizados por diseño. Todos los servidores del clúster contribuyen al rendimiento de la aplicación Y siguen ofreciendo alta disponibilidad.

Veamos cómo gestionan esto ambas bases de datos.

Escalado con MongoDB

La raíz del problema es la arquitectura "maestro-esclavo" de MongoDB. Si tienes tres servidores físicos, por ejemplo, y ejecutas un clúster de MongoDB como un conjunto de réplicas (con la arquitectura recomendada un MongoDB por servidor), la aplicación sólo puede escribir en uno de estos tres servidores, el que ejecuta el primario. Los otros dos servidores en el conjunto de réplica son puramente esclavos ("secundarios" en términos de MongoDB) y sólo están ahí en caso de que el primario se caiga. Podrías leer datos de esos dos secundarios para escalar las lecturas, pero entonces tus lecturas dejarían de ser fuertemente consistentes. Así que, en el enfoque recomendado por MongoDB, esos servidores secundarios están infrautilizados (fuera de las tareas de mantenimiento de la base de datos en segundo plano) y apenas son queridos por la aplicación.

Los servidores secundarios solitarios deben configurarse con los mismos recursos que el primario en caso de que se necesiten para become una Primaria. Mientras tanto, apenas son utilizados por su aplicación. Entonces digamos que su sitio web está funcionando fantásticamente, pero el rendimiento de la base de datos está empezando a sufrir un poco y las escrituras están tardando más de lo que permite su SLA. Ha llegado el momento de escalar. Con MongoDB necesitas añadir como mínimo otro cuatro pero la mejor práctica es seis servidores. De acuerdo con las mejores prácticas de MongoDB, es necesario añadir otro conjunto de réplicas (Shard #2). Eso son tres servidores, pero luego están los servidores de configuración que contienen la información sobre dónde vive cada documento; así que según las mejores prácticas eso es tres más servidores.

Bueno, al menos con todos esos nuevos servidores tendrás mucha más capacidad de escritura, ¿verdad? No tan rápido. Incluso añadiendo seis servidores más, ahora sólo tienes dos servidores en los que escribir, no nueve. Tienes el primario original (conjunto de réplicas #1) y ahora un nuevo primario (conjunto de réplicas #2). Todo esto y todo lo que has hecho es aumentar significativamente la complejidad y la sobrecarga de mantenimiento de tu clúster. Si necesitas añadir otro shard para un mayor rendimiento de escritura, necesitas añadir otro tres nodos. Tu aplicación ni siquiera llega a jugar con dos de cada uno de esos servidores en cada conjunto de réplicas.

Una forma de evitar la infrautilización de los servidores bare metal que he observado es poner montones y montones de procesos mongod en el mismo servidor, en contra de la propia Mongo recomendaciones. Dejando a un lado los problemas de rendimiento, e incluso si se utilizan servidores virtuales, ¿qué ocurre cuando uno de los nodos se cae? ¿Cuántos primarios y secundarios perderás? ¿Has hecho un seguimiento de dónde están todos los primarios y secundarios para asegurarte de que el conjunto de réplicas está adecuadamente repartido entre los servidores del clúster? Hablas de aumentar la complejidad, ¡y vaya si lo hace!

Escalado con Couchbase

Veamos el mismo escenario de tres servidores que comenté antes, pero esta vez con Couchbase en mente. Tu aplicación puede leer y escribir en los tres servidores con discos aislados, memoria, red, núcleos de CPU, etc. En Couchbase tus datos se distribuyen uniformemente entre los tres servidores y se replican entre ellos. El SDK de Couchbase que usa tu aplicación sabe cómo acceder a tus datos, dónde están los servicios de Couchbase en el cluster, y cómo acceder a todos ellos. Tomemos el mismo escenario de escalado anterior y veamos tus opciones en Couchbase. Puedes añadir rápidamente otro servidor al cluster con dos clics desde la Consola de Administración O con un comando CLI.

Compárelo con el pasos necesarios para añadir un conjunto de réplicas con MongoDB. Con Couchbase, cuando necesitas más capacidad, sólo tienes que añadir uno o dos servidores más y reequilibrar. La semana siguiente, si necesitas más capacidad, puedes añadir más y reequilibrar de nuevo. ¿Ves lo fácil que es? Tus aplicaciones siempre están usando todos de los servidores del clúster. Ni siquiera tiene que cambiar su aplicación y puede añadir uno o más servidores cuando lo desee sin tiempo de inactividad. La conclusión es que no está desperdiciando servidores ni recursos de servidores. Puede utilizar cada bit de cada uno de los servidores si lo desea, y escalar horizontalmente. Puedes escribir tu aplicación en un nodo de Couchbase en tu ordenador y desplegarla en un cluster de producción sin esfuerzo extra.

Couchbase también tiene réplicas de datos, por supuesto, pero las réplicas de datos se usan sólo para Alta Disponibilidad. ¿Por qué renunciar a la consistencia por el rendimiento como en MongoDB, cuando puedes conseguir ambos en Couchbase? Y cuando se trata de reducir la complejidad cuando quieres usar VMs con Couchbase, puedes usar Rack/Zone Awareness.

A continuación se muestra una rápida comparación visual de lo que estamos hablando aquí. Observa que en el cluster MongoDB con todos esos servidores, sólo hay tres servidores en los que puedes escribir de los catorce listados. 

Compara esto con el lado de Couchbase y verás cuánto más simple, limpio y fácil de manejar es realmente. Para más información en este sentido, ver Entrada del blog de Manuel Hurtado que contrasta la configuración de un clúster listo para producción en Couchbase frente a MongoDB. También hay comparaciones independientes de arquitecturas de terceros que abordan el problema, tales como éste.

Resumen

Si no es obvio por ahora, MongoDB tiene algunos problemas serios en cómo una aplicación puede utilizar completamente todos esos costosos servidores/instancias. Sí, hay algunas soluciones, pero la mayoría de la gente de operaciones le aconsejará en contra de apilamiento de esa manera, incluso con la virtualización, ir tan densa no es una buena idea. Además, esto no es algo que MongoDB vaya a solucionar pronto, ya que está integrado en su arquitectura principal. Couchbase, por otro lado, está diseñado para utilizar al máximo cada servidor que le des, distribuyendo los datos y la carga uniformemente por todo el clúster. Todo ello con facilidad de gestión y la capacidad de operar a cualquier escala.

La utilización de los servidores es una cuestión importante porque los costes combinados de las licencias de bases de datos, el hardware, los gastos generales de gestión y los costes de las instalaciones pueden descontrolarse rápidamente. Dejando a un lado los gastos generales de gestión, cuesta más de 1.000 millones de euros. $700 al año sólo para alimentar (no refrigerar) un servidor básico medio en tu propio centro de datos. Y si decides recurrir a la nube para obtener capacidad, el coste total puede acercarse a $8-10.000 por instancia, al año. Se trata, pues, de un ejemplo en el que las consideraciones arquitectónicas pueden tener implicaciones significativas en términos de costes y complejidad. Así que si te animas, ir a la descarga Couchbase, cárgalo y comprueba lo fácil que es exprimir la potencia de esos servidores y del propio Couchbase.