Contra la espada y la pared: entre ScyllaDB y Cassandra

Cassandra es un ejemplo del mundo NoSQL. Originalmente un proyecto de código abierto surgido de Facebook, fue adoptado por la Fundación Apache y respaldado por una empresa, DataStax, que también ofrece DataStax Enterprise basado en Cassandra. Cassandra se encuentra entre las 10 mejores soluciones de bases de datos según DB-Engines.

Precisamente por eso ahora tiene un rival potencialmente peligroso en ScyllaDB. ScyllaDB es un nuevo chico en el bloque NoSQL que tiene como objetivo ofrecer una solución de código abierto y compatible con API con Cassandra, pero que funciona mucho mejor. El objetivo es ser un reemplazo directo para Cassandra, y cuando hablamos de la base de datos número 8 del mundo, eso es algo importante.

Yo, Cloudius

Dor Laor y Avi Kivity no emprendieron este grandioso plan en 2013. No fue por falta de ambición, pero simplemente no era lo suyo. Ambos tienen experiencia en hipervisores y formaron parte del equipo que creó KVM y fue adquirido por Red Hat. Al dejar Red Hat, su plan inicial era escribir un unikernel que desplazaría a Linux de los servidores en la nube. Así que no falta ambición.

Fundaron una startup llamada Cloudius, encontraron inversores, formaron un equipo y empezaron a trabajar duro. Sin embargo, en algún momento se dieron cuenta de que no se alcanzaría su potencial por varias razones y decidieron dar un giro. Y lo hicieron, para agregar otra base de datos NoSQL a la lista interminable, una que sería capaz de hacer lo que hace Cassandra y algo más.

Pero ¿por qué optar por una base de datos NoSQL y por qué apuntar a Cassandra?

Parte de la misión de Cloudius era acelerar la carga del servidor, con énfasis en las bases de datos. Laor, director ejecutivo de ScyllaDB, dice que lograron aumentar el rendimiento de Redis en un 70 por ciento sin hacer nada específico de Redis. Quizás se pregunten cómo fue eso posible, y hay una respuesta, pero por ahora atengámonos al hecho de que esto los impulsó a tomar esa dirección.

Fue una combinación de razones técnicas y de mercado lo que hizo que Cloudius apuntara a Cassandra. Laor dice que Hadoop también estaba en su lista, pero como ya lo habían hecho decidieron reescribir Cassandra: “El mundo no necesita otro formato de base de datos. El formato de Cassandra es bueno y tiene éxito. Cassandra es la mejor alta plataforma de disponibilidad disponible”.

Dicen que la imitación es la forma más sincera de adulación, y de esto se desprende que el equipo de ScyllaDB consideró que valía la pena imitar a Cassandra. Pero es más complicado que eso: “Cassandra está en todas partes en cargas de trabajo críticas. Pero cuando apuntamos a su optimización, nos topamos con limitaciones ligadas a su naturaleza JVM. Al final, Cassandra termina compitiendo consigo misma.

En ese momento, Google acababa de publicar un punto de referencia que detallaba cómo lograron obtener 1 millón de transacciones sobre Cassandra en su nube utilizando 300 máquinas virtuales. Esto despertó nuestro interés y, centrando nuestro trabajo en Cassandra, logramos obtener un récord de 1,6 millones de transacciones en una máquina virtual. Así empezamos.”

Introduzca ScyllaDB

Cloudius dio un giro y cambió su nombre, pero mantuvo el mismo equipo e inversores. Así nació ScyllaDB. Puede pensar que es descarado apuntar a “la mejor plataforma de alta disponibilidad que existe” y aspirar a hacerlo mejor, pero Laor dice que esperan que la historia se repita. Y la totalidad de esa cita, “la imitación es la forma más sincera de adulación que la mediocridad puede ofrecer a la grandeza”, puede no necesariamente aplicarse aquí.

“Cuando ingresamos al mercado con KVM, todos los jugadores estaban establecidos: VMWare, HyperV, Xen. Llegamos últimos, pero basándonos en el diseño revolucionario de Avi, KVM ahora domina. Creemos que nuestra diferenciación esta vez es aún mayor”, dice Laor.

¿Cuál es entonces esta diferenciación? ScyllaDB promete algo simple, atractivo y difícil de creer: mantenga su código base, reemplace Cassandra con ScyllaDB y obtenga un aumento de rendimiento hasta 10 veces mayor. Existen puntos de referencia y referencias que respaldan esas afirmaciones, pero ¿cómo puede funcionar esto? Todo se reduce a varias cosas.

Primero, lenguaje de implementación diferente. ScyllaDB ha sido reescrito desde cero en C++, a diferencia del código base basado en Java de Cassandra. La JVM agrega una capa intermedia entre el código fuente y el hardware, intercambiando portabilidad y facilidad de uso por rendimiento. Las JVM han recorrido un largo camino, pero el uso adecuado de un lenguaje más cercano a los fundamentos de bajo nivel puede resultar en un mejor rendimiento.

Pero eso es sólo una parte del secreto de ScyllaDB. Una parte igualmente importante tiene que ver con los fundamentos subyacentes, como la memoria o la asignación de sockets. El tipo de detalles esenciales que son difíciles de conseguir, programar y mantener, pero que pueden dar lugar a mejoras espectaculares. El tipo de cosas que uno llega a conocer íntimamente si programa, digamos, un hipervisor.

Todas esas lecciones aprendidas a lo largo de años de programación de bajo nivel se han destilado en SeaStar. SeaStar es un marco de código abierto para aplicaciones de alto rendimiento en el que se basa ScyllaDB, aunque no tiene nada específico de base de datos. SeaStar está controlado por eventos y permite escribir código asincrónico y sin bloqueo eficiente.

¿La compensación? Complejidad. Laor admite que es difícil programar sobre SeaStar, pero dice que el resultado vale la pena. Menciona, por ejemplo, Pedis, una reescritura de Redis basada en SeaStar realizada por Alibaba, que potencia a Redis. Además, promete ScyllaDB, el usuario promedio de Cassandra no necesita preocuparse por eso.

ScyllaDB tiene como objetivo facilitar la compleja tarea de configurar y ajustar las implementaciones de Cassandra ofreciendo capacidades de ajuste automático. ScyllaDB ha agregado mejoras tanto en la administración de nodos como en los protocolos de red con el objetivo de que los clústeres funcionen de manera óptima sin requerir la intervención del administrador.

Laor comparó esta característica con la base de datos autoajustable de Oracle. Sin embargo, también existen soluciones similares para otras plataformas, como Spark. Para Spark, algunos enfoques se basan en el uso del aprendizaje automático en conjuntos de datos recopilados de muchos clústeres operativos, otros en reglas.

ScyllaDB ha adoptado el enfoque basado en reglas, ya que Laor no cree que los conjuntos de datos puedan ser representativos de todas las configuraciones posibles. “Utilizamos inteligencia de desarrolladores, no inteligencia artificial”, afirma. Podría decirse que, de todos modos, los conjuntos de datos de los clústeres operativos de Cassandra serían difíciles de conseguir para ScyllaDB. Lo que nos lleva a un punto interesante.

Una roca y un lugar duro

Por un lado, la decisión de construir una nueva plataforma que sea compatible con una existente reduce la fricción y reduce la barrera de adopción para las organizaciones. ScyllaDB ya cuenta con nombres como Samsung, IBM y Outbrain entre sus primeros usuarios que lo utilizan en producción.

Por otro lado, induce fricción con la plataforma que el recién llegado pretende desplazar: Cassandra. Hemos visto ejemplos similares en el mundo de Spark, pero la diferencia es que las alternativas de Spark todavía se basan en gran medida en Spark, por lo que puede haber polinización cruzada y, eventualmente, quizás convergencia.

Aquí estamos hablando de un cambio radical: lenguaje de implementación diferente, infraestructura de bajo nivel diferente, protocolos de red diferentes. Realmente no hay lugar para que Cassandra y ScyllaDB jueguen lado a lado, como lo demuestra ampliamente el hecho de que ni siquiera pueden coexistir en un clúster.

Por lo general, dice Laor, las personas configuran un clúster ScyllaDB de prueba de concepto trabajando codo con codo con Cassandra hasta que se sienten lo suficientemente seguros como para hacer el cambio. “Tenemos diferentes protocolos. Consideramos apoyar los protocolos de Cassandra, pero hay tantas versiones que decidimos no hacerlo. Además, cuando las cosas van mal en un grupo mixto, ¿a quién culpar?”

¿Podría eso perjudicar la adopción? “No estamos casados ​​con nuestras bases de datos, eso es lo que nos dice la gente”, dice Laor. “Es una gran inversión, pero pueden cambiar. Elegir a Cassandra fue una decisión estratégica para nosotros. Empezamos desde cero y reescribimos todo. Cuando haces eso, creas antagonismo. Toca a mucha gente, es sensible.

Pero los resultados hablan por sí solos. Por ejemplo, un cliente nuestro de AdTech logró pasar de 100.000 tiempos de espera por segundo con Cassandra a 100 por segundo con ScyllaDB. No hemos estado haciendo mucho en términos de colaboración, principalmente porque en este momento estamos trabajando intensamente en la paridad de funciones. Pero al igual que KVM y Xen, donde teníamos interfaces comunes, puede haber potencial para la colaboración”.

Laor menciona algunas áreas en las que están contribuyendo a la comunidad de Cassandra, como que el CTO de ScyllaDB presente opciones de diseño en la conferencia de próxima generación de Cassandra o contribuya con un controlador para Go. También enfatiza que ScyllaDB es un proyecto de código abierto y que intentan documentar y difundir las decisiones de diseño y la implementación y dice que les gustaría trabajar con Cassandra en ciertas características en el futuro.

ScyllaDB es un recién llegado, pero al menos en el papel parece que tiene lo necesario para desplazar a un peso pesado como Cassandra con el respaldo empresarial de DataStax. El equipo ha estado ahí y lo ha hecho antes, la paridad de características casi está ahí, las finanzas y la estructura organizacional parecen estar ahí también.

ScyllaDB está bien financiado, con un total de 25 millones de dólares, y cuenta con un equipo de 45 personas (en su mayoría ingenieros) que trabajan juntos durante años. En el frente técnico, parece que ScyllaDB puede competir con Cassandra. Pero, ¿qué significa esa “adquisición hostil” para Cassandra, DataStax y la comunidad? ¿Podrá ScyllaDB ganarse corazones y mentes?

De todos modos, parece que la comunidad de Cassandra se encuentra actualmente en una especie de confusión. Ha habido cierta fricción entre DataStax y la Fundación Apache, lo que ha generado incertidumbre sobre el futuro y la dirección del proyecto. Entonces, ser un usuario de Cassandra hoy puede significar que estás entre la espada y la pared.

DataStax, por su parte, no respondió a una solicitud de comentarios. ScyllaDB, por otro lado, dice que su comunidad está creciendo, a pesar de que la barrera de entrada es alta debido a la naturaleza compleja de su implementación, y que prácticamente han logrado la paridad de funciones.

ScyllaDB 2.0 se anunció hoy en Scylla Summit y trae algunas características muy buscadas, como contadores y vistas materializadas. Según Laor, la paridad total de funciones se logrará a principios de 2018. Agregue a la mezcla la reciente adquisición de Seastar.io, que actuará como catalizador para que ScyllaDB ofrezca una versión administrada en la nube, y verá por qué ScyllaDB es un nombre para usted. Es posible que escuchemos más en el futuro.

Hablando de nombres, ¿qué pasa con el nombre de ScyllaDB? Al parecer sus fundadores quisieron utilizar un nombre de la mitología griega, como fue el caso de Casandra. Según ellos, en algunas partes del mundo “Scylla” se pronuncia “scale-ah”, lo que alude a escalabilidad, y así nació un nombre.

Irónicamente, Cassandra era un Oráculo al que nadie escuchaba. Escila y Caribdis eran un monstruo y un remolino que custodiaban el estrecho de Mesina, haciendo imposible pasar a través de ellos. Estar entre Escila y Caribdis es estar entre la espada y la pared. Pero estar entre ScyllaDB y Cassandra puede resultar algo bueno para la comunidad, en caso de que finalmente se mantenga alejada de…