By Felipe Cardeneti Mendes En 2008, Apache Cassandra estableció un nuevo estándar para la escalabilidad de la base de datos. Nacido para apoyar la búsqueda de Inbox de Facebook, ha sido adoptado desde entonces por gigantes tecnológicos como Uber, Netflix y Apple – donde es ejecutado por expertos que también sirven como contribuyentes de Cassandra (al lado de DataStax/IBM). ¿Pero qué hay de rendimiento? sencillez? eficiencia? elasticidad? En el 2015, ScyllaDB Fresco de crear KVM y hackear el núcleo de Linux, los fundadores creyeron que su El timing era ideal: sólo un año antes, Netflix había publicado sus números mostrando cómo empujar Este fue un éxito impresionante, pero uno que requirió importantes inversiones en infraestructura y esfuerzos de ajuste. Nació para ir más allá de la utilización suboptimal de recursos de Cassandra Enfoque de ingeniería de bajo nivel Apache Cassandra llega a 1 millón de RPS La idea era bastante simple (en teoría, al menos): tomar la arquitectura escalable de Apache Cassandra y reimplantarla cerca del metal manteniendo la compatibilidad del protocolo de cable. Para evitar contenciones, todo se hizo asíncronamente, y todas estas optimizaciones se combinaron con planificadores internos autónomos para una sobrecarga operacional mínima. Arquitectura Shard-per-Core Aunque no puedo hablar con la dirección actual de Cassandra, ScyllaDB ha evolucionado bastante significativamente desde entonces – cambiando de “ Una implementación Cassandra más rápida a una base de datos con su propia identidad y un conjunto de características únicas. Sólo Spoiler: En este vídeo, te guiaré por algunas diferencias clave entre ScyllaDB y cómo se diferencia de Apache Cassandra. Discuto las diferencias en el rendimiento, la elasticidad y las capacidades como la priorización de la carga de trabajo. Puedes ver cómo ScyllaDB mapea los datos por núcleo de la CPU, escala en paralelo y desactiva los cambios de topología, lo que le permite manejar millones de OPS con latencias bajas previsibles (y sin ajuste y vigilancia constante). Evolución de ScyllaDB La primera generación de ScyllaDB se centró en el rendimiento en bruto, cuando introdujeron la arquitectura asíncrona shard-per-core, el cache basado en líneas y los programadores avanzados que lograron latencias bajas predecibles. La segunda generación de ScyllaDB tenía como objetivo la paridad de características con Cassandra, pero en realidad hemos ido más allá de eso. Algo que Cassandra De la misma manera, ScyllaDB también introdujo en ese mismo año; estos fueron presentados en Cassandra 5 (después de al menos Además, nuestra implementación de Paxos para transacciones ligeras se eliminó. La implementación alternativa de Cassandra. Visiones materializadas e índices secundarios globales listos para la producción Las banderas como experimento Apoyo a los índices locales secundarios Tres implementaciones de indexación diferentes Muchas de las superficies y limitaciones La tercera generación marcó nuestro paso a la nube, junto con la continua innovación. Este es el momento en el que se introdujo ScyllaDB Alternator, nuestra API compatible con DynamoDB. En el 2020 (algo Durante este período, mejoramos drásticamente las velocidades de reparación con la reparación a nivel de fila e introducimos la priorización de la carga de trabajo (más sobre esto en la próxima sección). Compresión ZSTD Cassandra solo lo adoptó tarde en 2021 La cuarta generación de ScyllaDB surgió alrededor del momento en que AWS anunció su familia de instancias i3en, con nodos de alta densidad que contienen hasta 60 TB de datos ( Durante este período, introducimos la Estrategia de Compactación Incremental (ICS), permitiendo a los usuarios utilizar hasta el 70% de su almacenamiento antes de escalarlo. algo que Cassandra todavía lucha para manejar de manera efectiva También hemos introducido con un enfoque fundamentalmente diferente al de Cassandra. Con conceptos como , BYPASS CACHE, TIMEOUTs configurables por consulta, y mucho más. Cambiar la captura de datos (CDC) Ampliación del protocolo CQL Shard conciencia Finalmente, llegamos a la quinta generación de ScyllaDB, que todavía se está desarrollando. Esta fase representa nuestro camino hacia una fuerte consistencia y elasticidad con Raft y Tablets. Para más información sobre la importancia de esto, lea en... Capacidades que separan ScyllaDB Nuestros ingenieros han introducido muchas características interesantes en la última década. Basado en mis interacciones con los antiguos usuarios de Cassandra, creo que estas son las más interesantes para discutir aquí. Tablets Data Distribution Cada tabla de ScyllaDB se divide en fragmentos más pequeños (“tabletas”) para distribuir uniformemente los datos y la carga en todo el sistema. Las tabletas aportan elasticidad a ScyllaDB, lo que le permite doblar instantáneamente, triplicar o incluso 10 veces el tamaño de su clúster para acomodar aumentos de tráfico impredecibles. También permiten un uso más eficiente del almacenamiento, alcanzando hasta el 90% de utilización. Como los equipos pueden escalar rápidamente en respuesta a los picos de tráfico, pueden satisfacer los SLA de latencia sin tener que sobreprovisionar “en caso”. Raft-Based: fuerte coherencia para metadatos Raft introduce una fuerte coherencia a los metadatos de ScyllaDB. Han pasado los días en que un cambio de esquema podría empujar a su clúster en desacuerdo o perder el acceso porque se olvidó de actualizar el factor de replicación de su espacio clave de autenticación (problemas que todavía plagaron a Cassandra). Workload Prioritization Permite consolidar múltiples cargas de trabajo bajo un solo clúster, cada una con su propio SLA. Básicamente, controla cómo diferentes cargas de trabajo compiten por los recursos del sistema. Los equipos lo utilizan para priorizar las solicitudes de aplicación urgentes que requieren tiempos de respuesta inmediata frente a otras que pueden tolerar retrasos más ligeros (por ejemplo, escaneos grandes). Priorización del trabajo Repair-based Operations Las operaciones basadas en la reparación aseguran que los datos del clúster permanezcan sincronizados, incluso durante los cambios de topología. , donde operaciones como la sustitución de nodos fallidos pueden ScyllaDB también elimina completamente el problema de la resurrección de datos, gracias a . Falta de consistencia de datos en Apache Cassandra result in data loss Colección de basura basada en tumba Incremental Compaction La compactación incremental (ICS) ha sido la estrategia de compactación predeterminada en ScyllaDB durante más de cinco años. ICS reduce considerablemente la amplificación temporal del espacio, lo que resulta en que hay más espacio en disco disponible para almacenar datos de los usuarios – y esto elimina el requisito típico de 50% de espacio libre en su disco. Row-based Cache El cache basado en líneas de ScyllaDB también es único. Está habilitado por defecto y no requiere un ajuste manual. extension, puede prevenir la contaminación de la caché manteniendo los elementos importantes inactivados. Reduce significativamente el tiempo de acceso I/O al recuperar datos del disco. Bypass en caché Caché de índice SSTABLE Per-shard Concurrency Limits and Rate Limiters ScyllaDB incluye límites de concurrencia por fracción y limitadores de tasa por partición para proteger contra picos inesperados. Ya sea que se trate de un cliente mal comportado o de una inundación de solicitudes a una clave específica, ScyllaDB asegura resiliencia donde Cassandra a menudo cae en falta. DynamoDB Compatibility ScyllaDB también ofrece una capa compatible con DynamoDB, distanciándose aún más de sus orígenes de Apache Cassandra. Esto permite a los equipos ejecutar sus cargas de trabajo de DynamoDB en cualquier nube o on-prem – sin cambios de código, y con un 50% de menor coste. ¿Qué es lo siguiente? En la reciente Cumbre de Monster SCALE, el CEO / cofundador Dor Laor compartió un vistazo a lo que está por venir para ScyllaDB. Listo ahora (ver aquí) y Para los detalles): Blog Post Página del producto Capacidad de funcionar de forma segura con un uso de almacenamiento del 90% Soporte para clusters con nodos de tipo de instancia mixta Provisionamiento dinámico y crédito flexible Vector de búsqueda A corto plazo: Tablas muy consistentes Servicio de inyección incorrecta Reparaciones transparentes Almacenamiento de objetos y tierras Raft para mesas fuertemente consistentes a largo plazo Transacciones multi-chave Análisis y transformaciones con UDFs Balanceador automático de particiones grandes Infraestructura inmutable para una mayor estabilidad y fiabilidad Un modo de replicación para cambios de infraestructura más flexibles y eficientes Para más detalles, vea la conversación completa aquí: Para cerrar, ScyllaDB más rápido que Cassandra (me compartiré mis últimos resultados de referencia aquí pronto).Pero tanto ScyllaDB como Cassandra han evolucionado hasta el punto de que ScyllaDB ya no es “sólo” un Cassandra más rápido.Hemos evolucionado más allá de Cassandra.Si tu proyecto necesita un rendimiento más predecible – y/o podría beneficiarse de las optimizaciones de elasticidad, eficiencia y simplicidad en las que nos hemos centrado durante años – también puedes considerar evolucionar más allá de Cassandra. es Para saber más sobre ScyllaDB, visite https://www.scylladb.com/ Puede acceder a libros de bases de datos gratuitos, masterclasses y más en https://resources.scylladb.com/ https://www.scylladb.com/ https://resources.scylladb.com/
