No es la primera vez que hablo de FUD (enlace). Sin embargo, es la primera vez que me dirijo a FUD dirigido a Couchbase y eso es una gran cosa. Después de todo, sé lo que pasa después.
Primero te ignoran, luego se ríen de ti, después luchan contra ti y entonces ganas. - Gandhi
Creo que la mejor manera de hacer frente al FUD es abordarlo. Hoy, voy a abordar una entrada de blog de DataStax (enlace).
Escrituras asíncronas
Como MongoDB circa 2013, Couchbase realiza escrituras asíncronas por defecto.
Esto no es cierto. Sí, MongoDB realizaba escrituras asíncronas por defecto. No respondía a peticiones de escritura (enlace). Sin embargo, este ya no es el caso con MongoDB 2.6 (enlace). Couchbase Server no realiza escrituras asíncronas. Responde a peticiones de escritura.
Persistencia y rendimiento
Se puede forzar a Couchbase a que persista las escrituras en disco, pero al hacerlo se reduce el rendimiento; como no hay commitlog ni journaling, cada escritura debe actualizar el btree de Couchbase y fsync.
Esto es engañoso. Sí, Couchbase Server escribe primero en memoria. Después, sincroniza los datos en memoria con el dispositivo de almacenamiento. Sin embargo, también lo hace DataStax Enterprise (Apache Cassandra). Por defecto, no fsync después de escribir en el registro de commit. Por lo tanto, escribe primero en memoria. Escribe en la caché de páginas a través del sistema operativo. Si DataStax Enterprise está configurado para fsync después de escribir en el registro de confirmación, que mata el rendimiento.
Cubos y documentos
El motor de almacenamiento de Couchbase tiene problemas para manejar más de cinco cubos (análogos a las tablas relacionales).
Esto no es cierto. Un cubo es análogo a una base de datos. No hay esquema. No hay tablas. Esa es una de las ventajas de una base de datos de documentos.
Coherencia y disponibilidad
Couchbase se las arregla para no ser ni totalmente consistente, ni totalmente disponible: no puede servir lecturas durante la conmutación por error o particiones de red, pero todavía puede servir datos obsoletos a las lecturas.
No es cierto. y no tiene sentido. ¿No puede servir lecturas, pero sí puede servir datos a las lecturas?
Couchbase Server mantiene una fuerte consistencia. Por defecto, el failover automático está desactivado. Si un nodo no está disponible o no responde, sus datos no están disponibles. Couchbase Server es CP. Sin embargo, Couchbase Server puede ser configurado para AP.
¿Es DataStax Enteprise totalmente coherente? Puede encontrar la respuesta aquí.
FUD disipado.
Recomendaciones
DataStax ha publicado una entrada en su blog sobre cómo no realizar un benchmark de Apache Cassandra (enlace). Es un gran comienzo.
No realice pruebas comparativas de bases de datos distribuidas con máquinas virtuales, almacenamiento compartido, unidades mal configuradas, carga inadecuada y con conjuntos de datos pequeños.
Estoy de acuerdo. Sin embargo, la lista está incompleta.
1. No realice pruebas comparativas de bases de datos distribuidas con un único nodo.
Una base de datos distribuida tiene que hacer concesiones entre coherencia y disponibilidad (enlace), y esas compensaciones afectan al rendimiento. Si una prueba se realiza con un único nodo, se ignoran esas compensaciones y se oculta el impacto en el rendimiento. Los resultados de rendimiento son poco realistas y, por tanto, inútiles.
2. No realice pruebas comparativas de bases de datos distribuidas con diferentes configuraciones.
Por ejemplo, no configure Couchbase Server para fsync cada escritura mientras configura DataStax Enterprise para fsync cada diez (10) segundos (enlace y enlace). Los resultados de rendimiento son sesgados y, por tanto, inválidos. Parece que DataStax ha puesto commitlog_sync en batch. Eso es justo. Sin embargo, DataStax no graficó la latencia. Si commitlog_sync está configurado como batch, Apache Cassandra esperará 50 ms antes de completar una operación de escritura.
Bueno, eso es todo por hoy.
