Examinando el Ciclo de Vida de las Lápidas en Apache Cassandra

Este artículo es la primera parte de una serie de artículos de blog relacionados con el ciclo de vida y la gestión de las lápidas.

Eliminar y caducar datos en Cassandra es algo que debe planificar cuidadosamente. Especialmente si está a punto de eliminar una gran cantidad de datos a la vez. Sin una planificación adecuada, esto puede generar problemas en el clúster, como un aumento de la latencia de lectura y de la huella de uso del disco. A lo largo de este post, describiré una forma de abordar esto y sus advertencias.

Primero, repasemos lo básico. En Cassandra, los archivos de datos (SSTables) existentes en el disco son archivos inmutables. Cuando estamos borrando algo en Cassandra, se crea una nueva SSTable que contiene un marcador. Este marcador indica qué partición, fila o celda se eliminó junto con la marca de tiempo para esa eliminación. Este marcador de eliminación se llama lápida.

Los datos eliminados y la lápida pueden coexistir en el disco durante un período llamado gc_grace_seconds, que por defecto es de 10 días. Durante este tiempo, aunque los datos todavía pueden existir en la unidad, no se devuelven al cliente si se consulta. Lo que significa que, desde el punto de vista del cliente, los datos se eliminan tan pronto como ejecuta la instrucción delete. Sin embargo, desde un punto de vista operativo, tanto los datos como la lápida todavía pueden existir y ocupar espacio en el disco. Estos datos eliminados que aún existen en el disco se llaman «datos sombreados».»

N.B.: En el párrafo anterior digo que los datos y las lápidas «todavía pueden coexistir en disco «(énfasis en la» lata») porque si se produce compactación que involucra los datos y las lápidas, entonces los datos se desalojan. Pero la lápida permanecerá si gc_grace_seconds no ha pasado.

El gc_grace_seconds es un mecanismo de seguridad para garantizar que la lápida tenga tiempo suficiente para replicarse en todos los nodos que tengan una réplica de los datos sombreados. Para que este mecanismo de seguridad tenga éxito, debe poder reparar el clúster cada gc_grace_seconds. Lo que significa que si está utilizando los 10 días predeterminados para gc_grace_seconds, se debe iniciar y finalizar una reparación cada 10 días. La reparación sirve para evitar datos zombis en el clúster. No entraré en los detalles de cómo puede suceder esto, pero básicamente, los datos zombis ocurren cuando eliminas datos, pero regresan algún tiempo después.

Después de que gc_grace_seconds haya pasado, los datos y la lápida finalmente se pueden desalojar del disco, recuperando el espacio en disco utilizado anteriormente por ellos (Figura 1). La ETA para liberar el espacio en disco es uno de los primeros puntos que quiero aclarar en este post. Al usar Cassandra, muchas personas encuentran sorprendente este mecanismo, es decir, que después de eliminar datos, los datos todavía existen en el disco. Esta confusión generalmente se aclara rápidamente tan pronto como la gente se entera de las lápidas y los segundos gc_grace_seconds. Sin embargo, parece que los operadores tienden a pensar que los datos y las lápidas se desalojan justo después de que gc_grace_seconds haya terminado. De hecho, es esencial ser consciente de que esto podría no ser cierto (y tiende a no serlo). Por lo general, toma más tiempo que gc_grace_seconds para que se produzca este desalojo y se recupere el espacio en disco.

Figura 1-Compactación de datos sombreados con lápidas caducadas y no caducadas

El desalojo mencionado anteriormente ocurre cuando se produce compactación que involucra las tablas que tienen los datos sombreados y la lápida. Solo entonces, los datos se eliminan de manera efectiva y se recupera el espacio en disco. Es importante tener en cuenta que incluso si gc_grace_seconds ha pasado y la tabla con los datos sombreados está compactada con otra tabla que no tiene la lápida, entonces los datos sombreados no se purgan. Lo mismo sucede con los marcadores de lápida, es decir, si la tabla con la lápida no está compactada con todas las tablas que aún tienen datos que se eliminaron, entonces la lápida no se desaloja del disco. La razón por la que esto sucede es que durante la compactación, Cassandra no sabe qué hay en las mesas que no están involucradas en la compactación. Así que no tiene forma de saber que puede descartar los datos ya que no puede ver la lápida. Puede ver esto en la Figura 2 donde, aunque gc_grace_seconds ha pasado para ambas lápidas, nada se desaloja después de la compactación.

Figura 2-Compactación de datos sombreados y sus lápidas por separado

Debido al uso del disco por parte de los datos y el marcador de lápida, la acumulación de lápidas puede afectar la latencia de lectura, porque Cassandra necesita leer muchas lápidas antes de devolver datos en vivo.

La eliminación de datos no suele ser un problema si estas eliminaciones son pequeñas y escasas. Porque, durante el ciclo de vida de compactación natural, Cassandra finalmente recupera el espacio en disco y las lápidas purgadas. Sin embargo, si está eliminando una gran cantidad de datos a la vez, eso crea muchas lápidas y puede afectar rápidamente su latencia de lectura.

Si necesitas eliminar una gran cantidad de datos de forma ad hoc, en la siguiente publicación de blog hay algunos pasos que puedes seguir para mitigar los riesgos.

correo electrónico

Autor

  • Pedro Gordo

Interesado en trabajar con Pedro? Programe una llamada técnica.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.