MongoDB rige las implantaciones de nodo único y no escala

MongoDB publicó un referencia comparando el rendimiento de MongoDB, Apache Cassandra y Couchbase Server en despliegues de un solo nodo para contrarrestar la un publicamos comparando el rendimiento de MongoDB y Couchbase Server en despliegues de 9 nodos. MongoDB rinde bien cuando 1) se limita a un único nodo, 2) no almacena muchos datos y 3) no soporta muchos usuarios. Este es un punto dulce para MongoDB.

MongoDB dio a conocer las bases de datos NoSQL al facilitar a los desarrolladores la creación de pruebas de concepto o pequeñas aplicaciones. Sin embargo, MongoDB no puede satisfacer las rigurosas demandas de los despliegues de producción. Couchbase Server, por otro lado, brilla cuando se despliega como base de datos distribuida. Se escala con facilidad para almacenar más datos, dar soporte a más usuarios y proporcionar un mayor rendimiento y un acceso de menor latencia a los datos.

1) La prueba comparativa de nodo único no responde a los requisitos de escalabilidad

Si desea comprobar el rendimiento de una base de datos con un conjunto de datos pequeño y unos pocos usuarios, realice una evaluación comparativa con una implantación de un único nodo. Si desea comprobar su rendimiento en un entorno de producción con un gran conjunto de datos y muchos usuarios, realice una prueba de rendimiento con una implementación en clúster.

Es importante no sólo medir el rendimiento a escala, sino medir el rendimiento cumpliendo los requisitos de la empresa. Por ejemplo, la alta disponibilidad.

¿Por qué MongoDB no comparó el rendimiento de los despliegues distribuidos? Bueno, es difícil para MongoDB escalar más allá de un único nodo.

Como señala InformationWeek (enlace), el escalado no es lineal. Añadir nodos a un conjunto de réplicas MongoDB no aumentará el rendimiento de escritura porque cada escritura seguirá siendo ejecutada por un único nodo - el nodo primario. Lo mismo ocurre con los fragmentos de MongoDB: cada escritura seguirá siendo ejecutada por los nodos primarios. Si hay tres shards con tres nodos por shard, las escrituras serán ejecutadas por los tres nodos primarios.

2) La prueba comparativa aplicó un escenario de escritura diferente para Couchbase Server - No es una comparación de manzanas con manzanas.

MongoDB realizaba una operación por escritura - la actualización. Sin embargo, MongoDB inadvertidamente hizo que Couchbase Server realizara dos operaciones por escritura: una lectura, una actualización. Esto limitaba el rendimiento de escritura de Couchbase Server.

MongoDB (con WiredTiger) y Couchbase Server aprovechan el bloqueo a nivel de documento. Si dos clientes actualizan el mismo documento al mismo tiempo, uno de ellos fallará y tendrá que reintentar la actualización. Este es el caso tanto para MongoDB como para Couchbase Server. Fue el escenario de escritura para MongoDB en este benchmark, pero no para Couchbase Server.

Otro escenario de escritura es cuando necesitas asegurarte de que un cliente no puede actualizar un documento si ha sido actualizado antes por otro cliente. En este escenario de escritura, Couchbase Server soporta compare-and-swap mientras que MongoDB recomienda "Update Document if Current". patrón. Este era el escenario de escritura para Couchbase Server, pero no para MongoDB.

¿Por qué MongoDB hace que Couchbase Server realice la comparación y el intercambio, pero no implementa su propio patrón "Actualizar documento si es actual"?

3) La comparativa utilizó un cliente Couchbase obsoleto en lugar del actual

MongoDB eligió usar una librería cliente obsoleta lanzada en 2013 para Couchbase Server, que limitaba el rendimiento de Couchbase Server. El pasado mes de septiembre lanzamos una nueva biblioteca de clientes basada en Netty y RxJava, a la que siguieron versiones menores en febrero y marzo.

¿Por qué MongoDB haría un benchmark de Couchbase Server con una librería cliente obsoleta pero se haría un benchmark a sí mismo con su última librería cliente?

4) Durabilidad de un único nodo frente a durabilidad de una base de datos distribuida

El objetivo de la durabilidad es garantizar que los datos no se pierdan cuando falla un servidor. En este benchmark, como se realizó con despliegues de un solo nodo, los datos sólo pueden ser duraderos cuando se escriben en el disco. Es la misma limitación de las bases de datos relacionales tradicionales.

Hoy en día, las bases de datos distribuidas se basan en un enfoque moderno de la durabilidad que distribuye el riesgo de pérdida de datos: replican los datos en múltiples nodos. Couchbase Server es único en el sentido de que, aunque escribe en disco como una base de datos convencional, también aprovecha la replicación más rápida de memoria a memoria entre nodos. Los datos no sólo son duraderos, sino que están altamente disponibles. Se puede replicar a nodos en diferentes servidores, diferentes bastidores o diferentes centros de datos.

Dicho esto, si MongoDB hubiera usado la última librería cliente, el rendimiento de escritura de Couchbase Server habría sido al menos 10 veces mayor. La librería cliente de hace dos años (1.1.8) esperaba un mínimo de 100ms antes de comprobar si la escritura se había escrito en disco. En una versión posterior (1.4.x), 10ms. En la última versión (2.x), 10µs. Esta es la razón por la que siempre debes comparar las bases de datos con sus últimas librerías cliente, no con las de hace dos años.

Reglas MongoDB Despliegues de nodo único

MongoDB es adecuado para una prueba de concepto o una pequeña aplicación que tiene un pequeño conjunto de datos y un puñado de usuarios. Couchbase Server es más adecuado para aplicaciones con más datos, más usuarios y mayores requisitos de rendimiento / menor latencia, aquellas que se benefician de un despliegue distribuido. De hecho, Couchbase Server es a menudo seleccionado para alimentar aplicaciones de misión crítica - pequeñas o grandes, de consumo o empresariales, sociales o de juegos - donde las bases de datos relacionales tradicionales no pueden proporcionar la escalabilidad o el rendimiento requerido.

Debatir sobre Noticias Hacker

Para su información referencia MongoDB y Couchbase Server con despliegues de 9 nodos.