Descubre ScyllaDB, la base de datos NoSQL

ScyllaDB es una base de datos NoSQL compatible con Apache Cassandra y que se distingue porque cada nodo admite millones de operaciones por segundo, con una latencia predeciblemente baja. Lograr tal ventaja en velocidad se debe a que emplea un modelo de programación totalmente asíncrono y que no comparte nada, se basa en sus propios asignadores de memoria y programa meticulosamente todas sus solicitudes de Entrada/Salida.

Ventajas de ScyllaDB

Scylla tiene algunas ventajas adicionales: 

• Tiene mejor rendimiento (de 2 a 8 veces) que incluso la última versión de Cassandra.
• Los costes son inferiores especialmente porque ahorra tiempo en la administración, por su menor complejidad. Por esto, es una alternativa y reemplaza a Apache Cassandra con grandes ventajas. 
• Otra gran ventaja son sus capacidades de migración desde esta última hacen que ambas bases de datos sean totalmente compatibles. Las dos tienen la misma interfaz CQL, consultas, controladores, e incluso el mismo formato SSTable (Sorted Strings Table) en el disco. 
• La ventaja es que contaremos con una arquitectura diseñada para eliminar los problemas de rendimiento, las limitaciones y las barreras operativas de Cassandra.

ScyllaDB y Seastar

ScyllaDB utiliza Seastar para fragmentar solicitudes en cada núcleo. La aplicación solo tiene un thread por núcleo. ¿Y cómo es esto? Cuando una sesión está siendo manejada por el núcleo 1 y una solicitud de consulta para esa sesión llega al núcleo 2, esta petición se dirige al núcleo 1 para su procesamiento. En esta situación, cualquiera de los dos núcleos puede manejar la respuesta. En esta forma de trabajo, donde nada es compartido, se produce una mejora de las prestaciones, ya que cada thread tiene sus propias colas de memoria, CPU y gestión del búfer del NIC (Network Interface Card).

En los casos en los que no se puede evitar la comunicación entre núcleos, el framework Seastar ofrece una comunicación asíncrona entre varios núcleos que es altamente escalable. 

Cuando se encuentra una fila en una SSTable, debe enviarse a través de la red al cliente. Esto implica copiar datos del espacio de usuario al espacio del núcleo. Sin embargo, Linux suele realizar operaciones de bloqueo multithread que no son escalables. ScyllaDB se encarga de ello por medio de la pila de red del framework Seastar. La pila de red se ejecuta en el espacio de usuario y utiliza DPDK (Data Plane Development Kit) para un procesamiento de paquetes más rápido. DPDK omite el núcleo para copiar los datos directamente en el buffer de NIC y procesa un paquete en un plazo de aproximadamente 80 ciclos de CPU. 

ScyllaDB y la caché de las páginas

La caché de páginas está muy bien cuando se tiene Entradas/Salidas secuenciales y los datos se almacenan en el disco en formato wired. Sin embargo, en Scylla/Cassandra, tenemos datos en forma de SSTables. La caché de página almacena datos en el mismo formato, que ocupa una gran cantidad de memoria para datos pequeños y necesita serialización/deserialización cuando desea transferirlos y esto puede ser un problema como veremos más tarde.

ScyllaDB no depende de la caché de páginas, asigna la mayor parte de su memoria a la caché de filas. Row-Cache (caché de filas) tiene los datos en un formato de memoria que está optimizado, ocupando menos espacio y no necesita serialización ni deserialización. Esto hace que sea muy segura, ya que la serialización es un proceso en el que se traducen las estructuras de datos a un formato que puede almacenarse y reconstruirse con posterioridad. La deserialización, es transformar los datos serializados provenientes de un archivo, secuencia o socket de red en un objeto, y es en este último proceso donde reside la vulnerabilidad.

Por todas estas razones, dependiendo de lo que se busque Scylla hay que tenerla en cuenta cuando se necesiten velocidades de ejecución altas.