Comparación entre Couchbase y CosmosDB

Microsoft ha generado mucha expectación desde el lanzamiento de CosmosDB. Se trata básicamente de un cambio de marca de Amazon DocumentDB con algunas nuevas características interesantes. Vamos a profundizar un poco más en él y explorar su estrategia, documentación, lo que los desarrolladores han estado hablando y cómo se compara con Couchbase Server.

¿Una base de datos para gobernarlos a todos?

En palabras sencillas, Microsoft afirma que CosmosDB es una base de datos NoSQL capaz de hacer literalmente todo: Es una base de datos de documentos, un almacenamiento columnar, un almacén de claves y valores y una base de datos de grafos. Todo ello gracias a una abstracción del formato de los datos denominada atom-record-sequence (ARS).

Una buena muestra del trabajo de Microsoft es cómo los datos se organizan de forma diferente según cada modelo. En primer lugar, tienes que elegir la API que te gustaría utilizar ( SQL, MongoDB API, Microsoft Azure Table, Cassandra o Gremlin) y ceñirte a ella, ya que no se puede cambiar más tarde. Actualmente, todavía se puede tratar de acceder a algunos modelos a través de DocumentDB API. eso fue lo que me dio algunas pistas de cómo CosmosDB utiliza internamente un formato JSON decorado para almacenar sus datos.

Parece que Microsoft quiere competir con la mayoría de las bases de datos NoSQL que existen, lo cual es una estrategia realmente arriesgada, ya que puede que hayamos superado la época dorada de una base de datos única. solución de base de datos para todo. La elección de almacenes especializados tiene enormes ventajas, y este es el camino que han seguido la mayoría de las aplicaciones en estos momentos con el auge del persistencias políglotas. Un todo en uno una solución como CosmosDB puede ser buena para aplicaciones poco exigentes, pero todas esas abstracciones tienen un coste y, en última instancia, repercutirán en la simplicidad, el rendimiento y estarán limitadas en cuanto a funciones.

Couchbase vs CosmosDB - Comparando Manzanas con "Manzanas"

Intentaré limitar mi comparación con CosmosDB centrándome más en los escenarios que tienen sentido para comparar ambas tecnologías. La siguiente tabla intenta mostrar algunas de las diferencias lado a lado:

Conclusión

Creo que este es el primer artículo que compara CosmosDB con otra base de datos. Me ha llevado bastante tiempo revisar mucha documentación, comentarios de desarrolladores y algunos seminarios web.

Mi sensación, en general, es que CosmosDB tiene una gran visión, pero actualmente, todavía está inmaduro en algunos aspectos. La documentación y las copias de seguridad, por ejemplo, no son uno de sus puntos fuertes, lo cual es una consecuencia natural de construir algo centrado en múltiples campos a la vez. La base de datos de Microsoft también aporta muchas innovaciones, una de las más destacadas son los nuevos niveles múltiples de consistencia eventual: Constancia limitada, Sesión, Prefijo consistente y Eventualmente consistente.

El hecho de que Sesión como consistencia por defecto dice mucho sobre la forma recomendada de usar CosmosDB. También nos da pistas de que podría no ser la mejor solución si necesitas una fuerte consistencia de datos.

No he podido encontrar ninguna mención a mecanismos de caché en CosmosDB, así que asumo que no es una parte importante de la base de datos. El problema es que el almacenamiento en caché es crucial para un buen rendimiento en bases de datos fuertemente consistentes, siendo memory-first una de las razones por las que Couchbase Server es rapidísimo.

CosmosDB no proporciona índices optimizados para memoria y, por defecto, todos los campos se indexan en sus Índices Secundarios Globales (GSI). A mí me parece totalmente exagerado, ya que sigo pensando que es más fácil especificar qué campos quiero indexar que especificar qué campos no quiero indexar. Por supuesto, no tienes por qué eliminar esos campos del índice, pero no olvides que te cobran por ello.

Sharding parece ser ahora mismo una de las cosas más complicadas en CosmosDB. Las particiones se mueven automáticamente entre nodos, pero hay que especificar una clave de partición. El inconveniente de este enfoque es que cada partición es indivisible con un tamaño máximo de 10Gb. Si eliges una mala clave de partición, muchos documentos a los que se accede con frecuencia pueden acabar en la misma partición, lo que limita el rendimiento de tus lecturas/escrituras en función de la capacidad del nodo en el que se almacena la partición.

La clave de partición también es inmutable, así que para cambiarla, tendrás que copiar todos tus datos a otra colección. En Couchbase, de forma transparente distribuya sus documentos uniformemente entre los vBuckets para evitar este problema, y también para aumentar el rendimiento de sus lecturas/escrituras.

Actualmente, el estrangulamiento se realiza únicamente aumentando las unidades de solicitud (RU), que es un estándar común para las bases de datos totalmente gestionadas (en DynamoDB, por ejemplo, el estrangulamiento se realiza aumentando las unidades de capacidad de lectura/escritura). El problema con este enfoque es que no es un buen predictor del rendimiento de la consulta y hace aún más difícil mejorar solo un comportamiento específico, como aumentar únicamente la capacidad de escritura.

Microsoft se ha esforzado mucho en intentar que el aprovisionamiento de UA sea fácil de entender, pero he encontrado muchos comentarios de desarrolladores que subestiman sus UA ( como aquí o aquí ) y acabar con una factura mucho más alta de lo esperado. En general, el patrón que he visto de aprovisionamiento en CosmosDB se basa sobre todo en prueba-error. En Couchbase, el throttling es muy flexible, se puede hacer mediante escalado vertical/horizontal, ejecutando servicios específicos según el hardware del nodo, manteniendo índices en memoria, etc.

Microsoft también está claramente intentando convencer a los usuarios de MongoDB para que migren a CosmosDB. Incluso proporcionan un conector bastante compatible para facilitar la migración. El problema es que la raíz de por qué algunos usuarios están dispuestos a migrar a otras bases de datos se debe a los problemas de escalabilidad y rendimiento de MongoDB. Lo sabemos muy bien porque muchos de esos usuarios acaban migrando a Couchbase Servery el rendimiento de CosmosDB no parece ser una gran ventaja, al menos no por un coste razonable.

Microsoft proporciona una versión local limitada para el desarrollo, pero hasta ahora sólo funciona en máquinas Windows.

CosmosDB también proporciona un botón de distribución de datos global que hace realmente sencillo replicar datos en múltiples ubicaciones del mundo. Es, sin embargo, una característica que no se utiliza a diario para requerir tal simplicidad, también se podría lograr fácilmente en cuestión de minutos en Couchbase Server sin la limitación de ejecutar en una sola nube.

En resumen, estoy de acuerdo con el punto de vista de CosmosDB de que la consistencia eventual es una definición demasiado amplia. Sus nuevos modelos de consistencia permiten al desarrollador elegir el nivel de consistencia que tolera su aplicación.

Las razones para utilizarlo son casi las mismas que las mencionadas en mi artículo sobre DynamoDB. La principal diferencia, por supuesto, es que CosmosDB es mucho más flexible que DynamoDB. Ahora mismo es una base de datos polivalente media para aplicaciones que exigen un rendimiento medio con una gran coherencia. También es fácil se integra con algunas funciones de Azure Functions.

CosmosDB aún carece de casos de uso/clientes famosos, pero tiene potencial para destacar en aplicaciones con consistencia eventual, ya que parece ser su principal objetivo. Pero cuando se trata de aplicaciones fuertemente consistentes de exigencia media/alta, Couchbase Server es con diferencia una mejor opción, tanto desde el punto de vista del precio como del rendimiento.

Es difícil establecer un punto de referencia justo entre estas dos bases de datos, ya que no está claro, por ejemplo, cuántos servidores se ejecutan cuando se aprovisionan 30.000 UI en CosmosDB, por lo que la forma más fácil de predecir su rendimiento esperado es a través de su arquitectura/características.

Al igual que DynamoDB, el precio de CosmosDB es atractivo si se tiene una base de datos pequeña con pocas lecturas/escrituras por segundo. Pero cualquier cosa por encima de eso con le costará una buena cantidad de dinero: 200 000 documentos de 45kb, con 4 escrituras/seg y 40 lecturas/seg le costarán al menos US$ 2 500.

Su calculadora no tiene en cuenta el modelo de consistencia que vas a utilizar, por lo que tienes que añadir unos cuantos dólares extra a esta cifra para Strong-Consistency. En esta configuración, el coste de CosmosDB es al menos el doble de lo que costaría ejecutar Couchbase EE en Amazon Web Services con nuestra arquitectura recomendada (que es capaz de manejar más que eso).

Como he mencionado al principio del artículo, hay un montón de ventajas en la elección de almacenes especializados para cada propósito específico, y Couchbase Server realmente sobresale en la entrega de alto rendimiento con una fuerte consistencia.

Si tiene alguna pregunta, no dude en tuitearme en @deniswsrosa