Vamos a diseccionar el Benchmark NoSQL de otoño de 2014.
Apache Cassandra / DataStax Enterprise. MongoDB. Servidor Couchbase.
Vamos.
Hardware
| Servidor (8) | Cliente (32) | |
| Procesador | Intel Xeon E5-2620 V2 (2) | Intel Core i5-4440 |
| Memoria | 64 GB | 8 GB |
| Almacenamiento (datos) | SSD SATA 6Gb/s de 100 GB (2) | |
| Almacenamiento (OS) | SSD SATA 6Gb/s de 80 GB |
Red: 96 Gb/s (conmutador de 1 Gb/s con 48 puertos)
Espera, ¿96Gb/s? Es una matriz full duplex. (enlace)
¿Por qué no realizar pruebas comparativas con decenas de servidores?
Prefiero las pruebas realizadas en servidores bare-metal. No es barato.
Datos
| 4 Nodos | 6 Nodos | 8 Nodos | |
| Entradas | 20M | 30M | 40M |
| Copias | 2 | 2 | 2 |
| Feilds | 10 | 10 | 10 |
| Campo | 150 bytes | 150 bytes | 150 bytes |
| Entrada | 1.500 bytes | 1.500 bytes | 1.500 bytes |
| Datos | 55,8 GB | 83,8 GB | 111,6 GB |
¿Por qué no comparar con terabytes de datos?
El objetivo es identificar el rendimiento y la escalabilidad de las bases de datos cuando los conjuntos de trabajo están en memoria. El conjunto de trabajo podría haber sido de 32 GB, o podría haber sido de 384 GB. No habría importado. Cabía en la memoria. El conjunto de trabajo podría haber sido 10% de los datos, o podría haber sido 90% de los datos. No habría importado. Cabía en la memoria.
Pensemos en los clientes que ven películas en Netflix. Hay muchísimos clientes. Sin embargo, sólo una fracción de ellos está viendo películas en un momento dado. Es un conjunto de trabajo. Pensemos en los usuarios de aplicaciones web y móviles. Yo juego a Words with Friends con mi mujer. Jugamos dos o tres partidas a la vez. De vez en cuando abro la aplicación. Me paso unos minutos, si no varios, jugando a las palabras adecuadas para machacarla. Nos encanta Amazon Prime. Sin embargo, solo compramos de vez en cuando. Cuando lo hacemos, formamos parte de un grupo de trabajo. Clientes que están comprando en ese momento. No todos los clientes. Luego están los datos en tiempo real. Consideremos el análisis del flujo de clics y los datos de los sensores. El conjunto de trabajo son los usuarios que actualmente visitan el sitio web. No todos los usuarios. El conjunto de trabajo es el último minuto, la última hora o el último día de los datos de los sensores. No todos los datos de los sensores.
Mientras que un conjunto de trabajo en memoria mejora el rendimiento de lectura, no mejora el rendimiento de escritura.
Todos los datos eran persistentes.
Configuración
Coherencia
Apache Cassandra, eventualmente consistente (ONE). MongoDB y Couchbase Server, consistentes.
Durabilidad / Persistencia
Apache Cassandra y MongoDB y Couchbase Server, persistencia asíncrona.
Nota: El registro de commit fue deshabilitado en Apache Cassandra.
Replicación
Hay dos ejemplares.
Topología
Apache Cassandra y Couchbase Server, un nodo por servidor. MongoDB, dos nodos por servidor.
Nota: MongoDB se basa en una topología maestro/esclavo. Para garantizar que todos los servidores respondan a las solicitudes de lectura/escritura de los clientes, se instalaron un maestro y un esclavo (de diferentes fragmentos) en cada servidor.
Cargas de trabajo
Lectura Pesada: 95% Lecturas / 5% Escrituras
Equilibrado: 50% Lecturas / 50% Escrituras
Nodos de base de datos e hilos cliente
Las pruebas se realizaron en despliegues de cuatro, seis y ocho servidores.
Las pruebas se realizaron con un número creciente de hilos de cliente.
Resultados
Leer más
Apache Cassandra
El rendimiento máximo se alcanza entre 248 y 496 hilos de cliente: 99.000 ops/s.
Añadir nodos aumenta el rendimiento.
La latencia nunca es inferior a 1 ms.
Añadir nodos disminuye la latencia.
MongoDB
El rendimiento máximo se alcanza entre 132 y 198 hilos de cliente: 227.000 ops/s.
Añadir nodos aumenta el rendimiento.
La latencia es inferior a 1 ms hasta 231 subprocesos de cliente: 200K ops/s.
Añadir nodos disminuye la latencia.
Servidor Couchbase
El rendimiento máximo es de 2.970 hilos de cliente: 1,62M ops/s.
Añadir nodos aumenta el rendimiento.
La latencia es inferior a 1 ms hasta 1.320 subprocesos de cliente: 1,44M ops/s.
Añadir nodos disminuye la latencia.
MongoDB contra Couchbase Server
Comparemos el rendimiento y la latencia de los servidores MongoDB y Couchbase con una carga equivalente.
El rendimiento de Couchbase Server aumenta cuando se incrementa la carga. MongoDB, no tanto.
La latencia de Couchbase Server es inferior a 0,6 ms hasta 264 hilos de cliente: 642K ops/s.
MongoDB es inferior a 1 ms hasta 231 hilos de cliente: 200K ops/s
Explicación
- La latencia de lectura de MongoDB se beneficia de los archivos mapeados en memoria. Sin embargo, los archivos mapeados en memoria no rinden tan bien como la memoria directa. Eso, y que MongoDB se basa en una topología arcaica y compleja. De hecho, el benchmark comparó MongoDB con 16 nodos con Couchbase Server con 8 nodos.
Servidor Apache Cassandra contra Couchbase
El rendimiento de Couchbase Server aumenta cuando se incrementa la carga. Apache Cassandra, no tanto.
La latencia de Couchbase Server es inferior a 0,7 ms hasta 792 hilos de cliente: 1,22M ops/s.
La latencia de Apache Cassandra nunca es inferior a 1 ms.
Explicación
Apache Cassandra se basa en una caché de filas pobre y deshabilitada por defecto (JIRA).
Lectura y escritura equilibradas
Apache Cassandra
El rendimiento máximo se alcanza entre 272 y 544 hilos de cliente: 89.000 ops/s.
Añadir nodos aumenta el rendimiento.
La latencia es inferior a 1 ms hasta 680 hilos de cliente: 79K ops/s.
Añadir nodos disminuye la latencia.
MongoDB
El rendimiento máximo es de 256 hilos de cliente: 85.000 ops/s.
Añadir nodos aumenta el rendimiento.
La latencia nunca es inferior a 1 ms.
Añadir nodos disminuye la latencia.
Servidor Couchbase
El rendimiento máximo es de 3.000 hilos de cliente: 1,18 millones de operaciones/s.
Añadir nodos aumenta el rendimiento.
La latencia es inferior a 1 ms hasta 480 subprocesos de cliente: 499K ops/s.
Añadir nodos disminuye la latencia.
MongoDB contra Couchbase Server
Comparemos el rendimiento y la latencia de MongoDB y Couchbase Server con una carga equivalente.
El rendimiento de Couchbase Server aumenta cuando se incrementa la carga. MongoDB, no tanto.
La latencia de Couchbase Server es inferior a 0,8 ms hasta 360 hilos de cliente: 457K ops/s.
La latencia de MongoDB nunca es inferior a 1ms.
Explicación
Bueno, una sola cerradura no ayuda (manual | JIRA). El bloqueo a nivel de documento se solicita desde 2010.
Servidor Apache Cassandra contra Couchbase
El rendimiento de Couchbase Server aumenta cuando se incrementa la carga. Apache Cassandra, no tanto.
La latencia de Couchbase Server es inferior a 1ms hasta 480 hilos de cliente: 499K ops/s.
La latencia de Apache Cassandra es inferior a 1 ms hasta 680 hilos de cliente: 79K ops/s.
Explicación
La latencia de escritura de Apache Cassandra se beneficia de la memtable, pero Couchbas Server fue diseñado para la concurrencia.
Conclusión
| Lee | Escribe | |||
| Bajo rendimiento | Alto rendimiento | Bajo rendimiento | Alto rendimiento | |
| Apache Cassandra | Pobre | Pobre | Genial | Pobre |
| MongoDB | Genial | Pobre | Pobre | Pobre |
| Servidor Couchbase | Genial | Genial | Genial | Bien |
¿Preguntas?
Comente o únase al debate en Reddit o HN.
Puede descargar el libro blanco aquí.
