Comience a usar tablas virtuales en Apache Cassandra 4.0
Qué son y cómo utilizarlos.
Entre las muchas adiciones en la reciente versión beta de Apache Cassandra 4.0, las tablas virtuales es una que merece cierta atención.
En versiones anteriores de Cassandra, los usuarios necesitaban acceso a Java Management Extensions (JMX) para examinar detalles de Cassandra, como la ejecución de compactaciones, clientes, métricas y una variedad de ajustes de configuración. Las mesas virtuales eliminan estos desafíos. Cassandra 4.0 beta permite a los usuarios consultar esos detalles y datos como filas de Cassandra Query Language (CQL) desde una tabla del sistema de solo lectura.
Así es como funcionaba el mecanismo basado en JMX en versiones anteriores de Cassandra. Imagine que un usuario quiere comprobar el estado de compactación de un nodo particular en un clúster. El usuario primero debe establecer una conexión JMX para ejecutar nodetool compactionsstats
en el nodo. Este requisito presenta inmediatamente al usuario algunas complicaciones. ¿Está configurado el cliente del usuario para acceso JMX? ¿Están configurados los nodos y el firewall de Cassandra para permitir el acceso a JMX? ¿Están preparadas y en vigor las medidas adecuadas de seguridad y auditoría? Estas son sólo algunas de las preocupaciones con las que tuvieron que lidiar los usuarios al tratar con versiones anteriores de Cassandra.
Con Cassandra 4.0, las tablas virtuales permiten a los usuarios consultar la información que necesitan utilizando su controlador previamente configurado. Este cambio elimina todos los gastos generales asociados con la implementación y el mantenimiento del acceso JMX.
Cassandra 4.0 crea dos nuevos espacios de claves para ayudar a los usuarios a aprovechar las tablas virtuales: system_views
y system_virtual_schema
. El espacio de claves system_views
contiene toda la información valiosa que buscan los usuarios, almacenada de manera útil en varias tablas. El espacio de claves system_virtual_schema
, como su nombre lo indica, almacena toda la información de esquema necesaria para esas tablas virtuales.
(Ben Bromhead, CC BY-SA 4.0)
Es importante comprender que el alcance de cada tabla virtual está restringido a su nodo. Cualquier consulta de tablas virtuales devolverá datos que son válidos sólo para el nodo que actúa como su coordinador, independientemente de la coherencia. Para simplificar este requisito, se ha agregado soporte a varios controladores para especificar el nodo coordinador en estas consultas (Python, DataStax Java y otros controladores ahora ofrecen este soporte).
Para ilustrar, examine esta tabla virtual sstable_tasks
. Esta tabla virtual muestra todas las operaciones en SSTables, incluidas compactaciones, limpiezas, actualizaciones y más.
(Ben Bromhead, CC BY-SA 4.0)
Si un usuario ejecutara nodetool compactionsstats
en una versión anterior de Cassandra, este es el mismo tipo de información que se mostraría. Aquí, la consulta encuentra que el nodo tiene actualmente una compactación activa. También muestra su progreso y su espacio de claves y tabla. Gracias a la tabla virtual, un usuario puede recopilar esta información rápidamente y, con la misma eficacia, obtener la información necesaria para diagnosticar correctamente el estado del clúster.
Para ser claros, Cassandra 4.0 no elimina la necesidad de acceso a JMX: JMX sigue siendo la única opción para consultar algunas métricas. Dicho esto, los usuarios agradecerán la posibilidad de extraer métricas clave del clúster simplemente utilizando CQL. Gracias a la comodidad que ofrecen las mesas virtuales, los usuarios pueden reinvertir en Cassandra el tiempo y los recursos previamente dedicados a las herramientas JMX. Las herramientas del lado del cliente también deberían comenzar a aprovechar las ventajas que ofrecen las mesas virtuales.
Si está interesado en la versión beta de Cassandra 4.0 y su función de mesas virtuales, pruébela.