Dos años es mucho tiempo en tecnología en estos días. Eso era cierto antes de COVID-19, y ciertamente lo es ahora. Han pasado casi dos años desde que se lanzó la última versión principal 4.0 de la base de datos NoSQL de código abierto ScyllaDB en 2020. Un par de años más tarde, con el anuncio de la versión 5.0 de ScyllaDB, es un buen momento para volver a consultar.
¿Cómo han evolucionado las realidades de las bases de datos y la gestión de datos en general? ¿Y cómo se ha mantenido ScyllaDB? Nos conectamos con el cofundador y director ejecutivo de ScyllaDB, Dor Laor, para analizar los detalles del nuevo lanzamiento, así como los desarrollos en el mundo de las bases de datos.
La nube como centro de gravedad de las bases de datos
Cubrimos por primera vez ScyllaDB en MarketingyPublicidad.es en 2017. Su historia es de tecnología profunda, código abierto y pivotes. Iniciada por Dor Laor y Avi Kivity, veteranos de Hypervisor y Linux Red Hat, la base de datos que se posiciona como un Apache Cassandra más rápido no se estableció como una base de datos en absoluto. Habiendo emprendido ese curso, sin embargo, permanece fijo.
Laor es un director general con mucha orientación técnica, que prefiere sumergirse de cabeza en un análisis de lo que ScyllaDB 5.0 trae a la mesa en el frente técnico. Sin embargo, pensamos que comenzaríamos con las tendencias generales que impulsan los desarrollos técnicos, lo que Laor también reconoció.
De acuerdo, no es nada que no haya escuchado antes: los datos van a la nube y el procesamiento de datos en tiempo real va en aumento. ScyllaDB ha estado operando su propia base de datos como servicio, Scylla Cloud, solo durante algunos años, pero se está convirtiendo rápidamente en el centro de gravedad de la empresa.
Scylla Cloud se introdujo en 2019 y creció un 200 % en 2021, luego de un crecimiento del 200 % en 2020. Laor dijo que el impulso del servicio es fuerte, con una predicción de crecimiento del 140 % en 2022. Se convertirá en la mitad del negocio de ScyllaDB, Laor agregó, ya que la gente simplemente prefiere consumir servicios:
«Es difícil encontrar talento para ejecutar una base de datos distribuida. Es un desafío y también muy costoso. Los proveedores que mantienen su propia automatización en torno a esto traerán [users] mejores resultados, porque nuestra implementación es la recomendada. La mayoría de los usuarios que ejecutan una base de datos por su cuenta estarán demasiado ocupados para implementar copias de seguridad y restauración, por ejemplo. Ese no es nuestro caso», dijo Laor.
Scylla Cloud inicialmente estuvo disponible en AWS, aunque luego se expandió para cubrir también GCP. En AWS, los usuarios pueden optar por ejecutar ScyllaDB en su propia cuenta si lo desean. En GCP, ScyllaDB pronto estará disponible en el mercado. El soporte para Azure también llegará pronto. Laor dijo que su enfoque en este momento es automatizar y completar varios aspectos de la seguridad y administración de usuarios del servicio.
Como parte de su propia investigación, ScyllaDB realizó algunos puntos de referencia en AWS. Esos puntos de referencia se compartieron con el público en Scylla Summit 2022, el reciente evento en línea de la compañía. La evaluación comparativa es difícil, lo cual es claro para un proveedor como ScyllaDB, que está bastante interesado en las evaluaciones comparativas.
El personal de ScyllaDB comparó su base de datos a nivel de petabytes, utilizando funciones como la priorización de la carga de trabajo para controlar las prioridades de las consultas transaccionales (lectura-escritura) y analíticas (solo lectura) en el mismo clúster con un rendimiento fluido y predecible. En el proceso, también descubrieron algunas ideas sobre las CPU de diferentes proveedores y las instancias de AWS.
En la cumbre, se presentaron puntos de referencia que comparan instancias AWS i3 con la solución x86 de Intel con instancias que se ejecutan en AMD. AWS pronto también pondrá a disposición i4, otra familia de instancias basada en máquinas x86 más nuevas, y dado que ScyllaDB tuvo acceso anticipado, también la incluyeron.
Todas estas familias son sobresalientes, dijo Laor. Las pruebas de ScyllaDB mostraron que los i4 son el doble de rápidos que los i3. En general, se encontró que las instancias basadas en brazos eran más lentas, pero si se tiene en cuenta el rendimiento del precio, en algunas cargas de trabajo son más baratas que las i3, dijo Laor. En general, sin embargo, se recomiendan todos, su NVMe ha mejorado mucho y son mucho mejores que el almacenamiento en red, agregó.
Datos a escala y en tiempo real
La otra tendencia en la gestión de datos en la que está jugando ScyllaDB es el énfasis continuo en el procesamiento de datos en tiempo real. Un ejemplo notable de Scylla Summit 2022 fue Palo Alto Networks que usó el procesamiento de flujo con ScyllaDB, sin una cola de mensajes. La motivación era reducir la complejidad operativa y, por extensión, el costo.
Inicialmente, pensamos que podría haberse construido sobre la función de captura de datos modificados (CDC) de ScyllaDB, que ha estado en funcionamiento desde la versión 4.0. CDC permite a los usuarios realizar un seguimiento de los cambios en sus datos, registrando tanto los valores de los datos originales como los nuevos valores en los registros. Los cambios se transmiten a una tabla CQL estándar que se puede indexar o filtrar para encontrar cambios críticos en los datos.
Aparentemente, el caso de uso de Palo Alto fue hecho a medida, y también involucró a Kafka. Si conoce su patrón de datos, esa es la mejor manera, comentó Laor. CDC generalmente se implementará para usuarios que no saben qué se escribió en la base de datos o cuyos datos no tienen un patrón regular.
Independientemente, el auge del procesamiento de datos en tiempo real se muestra en las asociaciones de ScyllaDB, así como en el programa de su reciente cumbre. La cumbre contó con presentaciones de Confluent, Redpanda y StreamNative, quienes se ocupan del procesamiento de datos en tiempo real, y los dos primeros son proveedores en este espacio. Laor señaló que ScyllaDB tiene un conector Kafka y otros conectores con los que la gente puede trabajar.
Los datos van en tiempo real y se trasladan a la nube, y ScyllaDB se mantiene al día. Imagen: ScyllaDB
En cuanto a los logros técnicos, ScyllaDB 5.0 ha progresado en dos frentes clave: rendimiento y operaciones. En el frente del rendimiento, Laor enfatizó el nuevo programador de E/S de ScyllaDB, que ha estado en proceso durante aproximadamente 6 años. Está diseñado para adaptarse a las nuevas capacidades de hardware y funciona en el nivel de fragmento. Lo que la gente de ScyllaDB se dio cuenta fue que las cargas de trabajo con solicitudes mixtas de lectura/escritura requieren una gestión especial, y esto es en lo que trabajaron.
Otra mejora importante en el rendimiento fue la forma en que se administran las particiones grandes. Esos son complicados tanto para la base de datos como para los usuarios. ScyllaDB mejoró la indexación de particiones grandes y agregó la capacidad de almacenar índices en caché. Laor se refirió a este problema como «solucionado a medias» en Cassandra y versiones anteriores de ScyllaDB a «resuelto por completo» en ScyllaDB 5.0.
En términos de mejoras operativas, el cambio principal es el paso de ser una base de datos de consistencia final a una base de datos con consistencia inmediata, como lo expresó Laor. El protocolo de consenso que rige las transacciones ha cambiado, ya que ScyllaDB cambió de Paxos a Raft. Laor explicó el viaje.
Cuando ScyllaDB implementó el protocolo Paxos con transacciones ligeras, también comenzó a implementar la API de DynamoDB para Alternator y completó las pruebas de Jepsen. Eso mostró las limitaciones del protocolo Raft, incluidos escenarios que no son transaccionales, como cambios de esquema y cambios de topología. Con Raft, se pueden admitir varios cambios de esquema de manera transaccional, mientras que los cambios de topología son trabajos en curso.
La otra mejora importante se refiere a las operaciones de reparación del nodo base. Las operaciones de nodo se refieren a agregar, eliminar o reemplazar nodos en un clúster. En todas esas operaciones, los datos deben transmitirse de ida y vuelta desde otras réplicas. Esa es una operación pesada, seguida de una fase de reparación. El protocolo del nodo base de reparación incluye ambos en una fase mientras tiene estado. Esto significa una operación más rápida que también se puede reanudar.
En general, Laor describió la evolución técnica continua y el crecimiento comercial proyectado para ScyllaDB. La base de clientes se ha expandido, desde nombres familiares como Amdocs e Instacart hasta casos de uso más exóticos en torno a blockchain. La base de datos en sí es independiente del caso de uso, aunque los grandes volúmenes de datos y las aplicaciones de series de tiempo son donde brilla: escala asequible, como lo expresó Laor.
Hasta ahora, el crecimiento ha venido principalmente de casos de uso de brownfield, es decir, de clientes que reemplazaron a Cassandra o DynamoDB con ScyllaDB; sin embargo, el segmento greenfield también está creciendo, mencionó Laor. Los planes de ScyllaDB incluyen la expansión de su oferta en la nube a Azure, así como funciones sin servidor y de tenencia múltiple integradas en su operador Kubernetes. A medida que se expande la huella digital mundial, es un buen momento para estar en el negocio de los datos, concluyó Laor.
