¿Sigue siendo el rendimiento un problema para MongoDB?
Avalon comparó Couchbase Server y MongoDB el año pasado, y muchas cosas han cambiado desde entonces. Couchbase Server 4.0 introdujo un lenguaje de consulta basado en SQL, N1QL. Couchbase Server 4.1 añadió sentencias preparadas e índices de cobertura, y el rendimiento de las consultas mejoró.
Couchbase Server 4.5 ha añadido índices optimizados para memoria, indexación de matrices y uniones de índices, así como mejoras en el almacenamiento (escrituras circulares) y la consistencia (lectura de tus propias escrituras). Couchbase Server tiene un motor de consultas más potente, pero con estas mejoras, ¿es el más rápido?
En esta ocasión, Avalon ha evaluado tanto el rendimiento de lectura/escritura como el de las consultas.
Los resultados de lectura/escritura no deberían sorprender a nadie.
¿Couchbase Server tiene un rendimiento de lectura/escritura 6 veces mayor que MongoDB? ¿Por qué? ¿Por qué?
Todo se reduce a arquitectura, utilización de recursos y eficiencia.
Cuando se trata del rendimiento de escritura, MongoDB adolece de una arquitectura maestro/esclavo heredada. Con un nodo primario y otro secundario en cada servidor, y con las escrituras limitadas a los nodos primarios, solo se puede utilizar la mitad de los recursos del servidor para las escrituras.
Cuando se trata de rendimiento de lectura, Couchbase Server se beneficia de una arquitectura centrada en la memoria. Aunque escribe todos los datos en disco, mantiene tantos documentos como sea posible en una caché de objetos gestionada, mucho más eficiente que almacenar en caché bloques de datos de archivos.
Los resultados de la consulta pueden ser sorprendentes.
¿Couchbase Server tiene un rendimiento de consulta 3 veces mayor que MongoDB? ¿Por qué? ¿Por qué?
Como he dicho, todo se reduce a la arquitectura, la utilización de recursos y la eficiencia.
MongoDB ejecuta cada consulta en cada nodo porque se basa en índices locales: cada nodo contiene sólo una parte del índice. Como resultado, el rendimiento de las consultas se limita al de un único nodo. Por ejemplo, si un único nodo puede ejecutar 7.500 consultas por segundo, añadir más nodos no ayuda: cada nodo sigue teniendo que ejecutar las mismas 7.500 consultas por segundo.
Couchbase Server se beneficia de índices globales optimizados en memoria, así como de servicios independientes para leer y escribir datos, indexarlos y consultarlos.
Cuando se trata de latencia de escaneo, Couchbase Server puede aprovechar los Índices Secundarios Globales (GSI), donde el servicio de índice mantiene un índice completo (no una parte de él). Esto permite al servicio de consulta identificar los documentos a devolver con un único escaneo del índice, limitando las peticiones de búsqueda a sólo aquellos nodos que contienen uno o más de los documentos a devolver. Con el almacenamiento optimizado para memoria, el índice completo no sólo se almacena en memoria, sino también en una lista de exclusión sin bloqueos, mucho más eficiente que un árbol B, una estructura de datos optimizada para disco.
Cuando se trata de latencia de inserción, Couchbase Server se beneficia del aislamiento. Los servicios de índices y datos, tanto si se ejecutan en nodos diferentes como si no, están aislados y los índices se actualizan de forma asíncrona. Como resultado, mientras que la latencia de inserción de MongoDB se vio gravemente afectada por las consultas, la latencia de inserción de Couchbase Server no.
Encontrará todos los detalles en el informe completo.
if (users > 100) return "Couchbase Server"; else return "MongoDB";
