Ya es oficial. Los principales proveedores de bases de datos NoSQL (DataStax, MongoDB y Couchbase) se han enfrentado.
En los últimos 30 días,
- Couchbase publicó un referencia el 19 de marzo.
- MongoDB respondió publicando un referencia el 31 de marzo.
- DataStax respondió publicando un referencia el 13 de abril.
Es importante realizar pruebas comparativas competitivas. Cuando patrocinamos una prueba comparativa, aprendemos lo bien que funciona nuestra base de datos en un escenario específico con una configuración específica. Cuando la competencia patrocina una prueba comparativa, aprendemos lo bien que funciona en un escenario diferente con una configuración diferente. Dicho esto, todos debemos a la comunidad garantizar que los puntos de referencia representen escenarios reales con configuraciones adecuadas. Y para ello, debemos ser transparentes.
Aunque nos alegramos de que DataStax haya reconocido la importancia de los benchmarks, este benchmark no proporciona una representación precisa del rendimiento de Couchbase Server. La falta de transparencia de este benchmark plantea una serie de preguntas sin respuesta que crean incertidumbre sobre su validez.
1) ¿Por qué se ha configurado mal la caché de Couchbase Server?
Couchbase Server soporta dos opciones para la optimización de la caché - expulsión "value", la opción por defecto, y expulsión "full". Este benchmark habilitó la optimización de caché incorrecta, expulsión "completa", para este escenario - limitando significativamente el rendimiento de lectura de Couchbase Server.
Couchbase Server almacena en caché los metadatos y el valor cuando se inserta un documento.
Cuando la expulsión de "valor" está activada, y no hay suficiente memoria, Couchbase Server expulsará el valor de otros documentos pero conservará sus metadatos.
Cuando la expulsión "completa" está activada, y no hay suficiente memoria, Couchbase Server expulsará tanto los metadatos como el valor de otros documentos.
Recomendaríamos la expulsión de "valor" para el escenario de este benchmark porque había suficiente memoria para almacenar en caché los metadatos de los 500M de documentos. Esto habría mejorado el rendimiento de lectura al eliminar IO de disco innecesarias para determinar dónde se almacenaban los datos en el disco.
Tanto Couchbase Server como MongoDB son capaces de ofrecer un mejor rendimiento de lectura. Por qué su rendimiento de lectura fue tan pobre en este benchmark?
Los números no cuadran. ¿Cómo es que Couchbase Server funcionó peor con un mayor porcentaje de datos en memoria y un tamaño de documento mucho menor? El tamaño de los documentos en el benchmark de Couchbase era de 1K. En el benchmark de DataStax era de 100 bytes.
Rendimiento del servidor Couchbase en
(1) Couchbase Benchmark y (2) DataStax Benchmark
| Punto de referencia | Operaciones por segundo y núcleo | Datos por nodo | Memoria por nodo | Nodos | Núcleos por nodo |
| 1 patrocinado por Couchbase | 4,600 | 32 GB | 10 GB | 9 | 8 |
| 2 patrocinados por DataStax | 375 | 50 GB | 23 GB | 8 | 4 |
2) ¿Por qué el cliente YCSB de Couchbase Server se basaba en una librería cliente obsoleta?
El repositorio de GitHub muestra que el cliente YCSB para Couchbase Server utilizado en este benchmark está basado en una librería cliente antigua para Couchbase Server 2.5. Debería haberse basado en la biblioteca cliente actual para Couchbase Server 3.0. El cliente antiguo esperaba un mínimo de 10 milisegundos antes de comprobar si los datos se habían escrito en el disco. El cliente actual espera tan sólo 10 microsegundos.
El rendimiento de escritura de Couchbase Server habría sido mejor con un cliente de segunda generación.
3) ¿Por qué se ha desactivado la replicación para Cassandra?
DataStax configuró Cassandra sin replicación - esto no es recomendable en el mundo real. Es un nivel de riesgo inaceptable. Si un nodo falla, los datos no están disponibles. ¿DataStax desactivó la replicación para mejorar el rendimiento de escritura de Cassandra?
Cassandra es eventualmente consistente por defecto. Couchbase Server y MongoDB imponen una fuerte consistencia por defecto. Si Cassandra se configurara para replicar datos, habría problemas con la consistencia. Si la consistencia fuerte se configurara a través de quorums, habría un impacto negativo en el rendimiento.
Couchbase Server replica datos a dos nodos por defecto - se almacenan en el propietario y en dos réplicas. MongoDB replica datos a múltiples nodos - se almacenan en el nodo primario y en nodos secundarios. Este benchmark no indica el número de réplicas configuradas para Couchbase Server o el número de nodos secundarios desplegados para MongoDB. Simplemente no lo sabemos, y por eso es importante la transparencia. Somos incapaces de reproducir las pruebas de rendimiento sin ella.
4) ¿Eran duraderos los escritos de Cassandra?
Couchbase Server y MongoDB estaban configurados para escrituras duraderas. No está claro si Cassandra estaba configurado para escrituras duraderas. Si no lo estuvieran, Cassandra se beneficiaría de una ventaja de rendimiento significativa a expensas de la durabilidad. Por defecto, las escrituras de Cassandra no son duraderas.
5) ¿Por qué no se utilizó la replicación para lograr la durabilidad?
Recomendamos activar la replicación para conseguir durabilidad. Al replicar los datos en varios nodos, los datos son duraderos porque no se perderán si falla un nodo. En este benchmark, los datos se almacenan en un único nodo, por lo que no son duraderos a menos que se escriban en disco. Sin embargo, una base de datos distribuida como Cassandra o Couchbase Server puede almacenar los datos en múltiples nodos... y eso es lo que recomendamos.
Crédito extra: Defiende MongoDB
Así es, estamos defendiendo MongoDB.
En primer lugar, nos sorprende que DataStax configurara MongoDB con particionamiento basado en rangos sabiendo que las claves eran incrementales ("usuario1", "usuario2", "usuario3"). MongoDB 2.4 introdujo partición basada en hash.
En segundo lugar, nos sorprende que DataStax haya publicado un benchmark que incluye una versión candidata de MongoDB. Creemos que los puntos de referencia deben limitarse a las versiones generalmente disponibles. No deberían incluir versiones milestone, candidatas, alfa o beta. El benchmark de Couchbase referencia incluye MongoDB 3.0 porque hemos esperado a la versión GA.
En tercer lugar, no creemos que esto represente bien el rendimiento de lectura de MongoDB. Después de todo, MongoDB ejecutó hasta 74K operaciones por segundo en el benchmark de Couchbase. Eso es mucho más que las 2K ops / segundo demostradas en este benchmark. No sabemos por qué, y es porque este benchmark carece de transparencia.
Conclusión: Para ser útiles, los puntos de referencia deben ser transparentes y estar bien configurados.
Es importante para los vendedores, los clientes potenciales y la comunidad que los puntos de referencia sean fácilmente reproducibles. Para ello, los puntos de referencia publicados deben incluir toda la configuración del cliente y de la base de datos. Sin embargo, nos resultaría difícil reproducir este punto de referencia dada la falta de transparencia.
Dicho esto, es difícil comparar bases de datos. No basta con saber configurar tu propia base de datos, también tienes que saber configurar otras bases de datos. Después de hacer un benchmarking de Cassandra, aprendimos a configurarla mejor en benchmarks posteriores. Esperamos que DataStax haya aprendido a configurar mejor Couchbase Server.
Si lo necesitan, estaremos encantados de ayudarles con su próximo punto de referencia.
Debatir sobre Noticias Hacker
