Cassandra genera lápidas al eliminar datos. En algunas circunstancias, el exceso de lápidas puede causar largas pausas de GC, latencia, fallas de lectura o errores fuera del montón. Este artículo proporciona consejos para el manejo de lápidas.

Tabla de Contenidos

¿Qué es una lápida?

En Cassandra, los datos eliminados no se eliminan inmediatamente del disco. En su lugar, Cassandra escribe un valor especial, conocido como lápida, para indicar que los datos se han eliminado. Las lápidas evitan que los datos eliminados se devuelvan durante las lecturas y, finalmente, permitirán que los datos se eliminen a través de la compactación.

Las lápidas son escrituras: pasan por la ruta de escritura normal, ocupan espacio en el disco y hacen uso de los mecanismos de consistencia de Cassandra. Las lápidas se pueden propagar por todo el grupo a través de sugerencias y reparaciones. Si un clúster se administra correctamente, se garantiza que los datos permanecerán eliminados incluso si un nodo está inactivo cuando se emite la eliminación.

Las lápidas son generadas por:

• ELIMINAR instrucciones
• Establecer TTLs
• Insertar valores nulos
• Insertar datos en partes de una colección.

¿Cuál es el ciclo de vida normal de las lápidas?

Las lápidas están escritas con una marca de tiempo. En circunstancias ideales, las lápidas (y sus datos asociados) se dejarán caer durante las compacciones después de que haya pasado un cierto tiempo.

Se deben cumplir los tres criterios siguientes para que se eliminen las lápidas:

• Las lápidas se crearon hace más de gc_grace_segundos.
• La tabla que contiene la lápida está involucrada en una compactación.
• Todas las mesas que podrían contener los datos relevantes están involucradas en la compactación.

Cada tabla tiene una configuración gc_grace_seconds. De forma predeterminada, se establece en 864000, lo que equivale a 10 días. La intención es proporcionar tiempo para que el clúster logre consistencia a través de reparaciones (y, por lo tanto, evitar la resurrección de los datos eliminados).

Las lápidas solo se soltarán a través de una compactación si todas las tablas que podrían contener los datos relevantes están involucradas en la compactación. Si ha transcurrido mucho tiempo entre la escritura de los datos originales y la emisión de la ELIMINACIÓN, esto se vuelve menos probable:

• La Estrategia de compactación por niveles compactará las tablas de tamaño similar juntas. Los datos tienden a moverse a mesas más grandes a medida que envejecen, por lo que es poco probable que la lápida (en una mesa nueva y pequeña) se compacte con los datos (en una mesa antigua y grande).
• La estrategia de compactación nivelada se divide en muchos niveles que se compactan por separado. La lápida se escribirá en el nivel 0 y efectivamente ‘perseguirá’ los datos a través de los niveles, eventualmente debería ponerse al día.
• La Estrategia de Compactación de Ventana de Tiempo (o Estrategia de Compactación por Niveles de Fecha) nunca compactará la lápida con los datos si están escritos en diferentes ventanas de tiempo.

¿Cuándo causan problemas las lápidas?

Uso del disco

Cuando se eliminan datos, el espacio no se liberará durante al menos el período gc_grace establecido en la configuración de la tabla. Esto puede causar problemas si un racimo se está llenando rápidamente.

En algunas circunstancias, el espacio nunca se liberará sin intervención manual.

Rendimiento de lectura

Pueden producirse graves problemas de rendimiento si las lecturas se encuentran con un gran número de lápidas.

Los problemas de rendimiento suelen ocurrir con los siguientes tipos de consultas: Consultas

• que se ejecutan en todas las particiones de una tabla («select * from keyspace.tabla»)
• Consultas de rango («seleccionar * del espacio de claves.tabla WHERE value > x», o » WHERE value IN (value1, value2, li) «
• Cualquier consulta que solo se pueda ejecutar con una cláusula» PERMITIR FILTRADO».

Estos problemas de rendimiento se producen debido al comportamiento de las lápidas durante las lecturas. En una consulta de rango, su controlador Cassandra normalmente usará paginación, lo que permite que los nodos devuelvan un número limitado de respuestas a la vez. Cuando las lápidas de cassandra están involucradas, el nodo necesita guardar las lápidas que ha encontrado en la memoria y devolverlas al coordinador, en caso de que una de las otras réplicas no sepa que los datos relevantes se han eliminado. Las lápidas no se pueden ubicar porque es esencial devolverlas todas, por lo que la latencia y el uso de memoria aumentan proporcionalmente al número de lápidas encontradas.

Si se encontrarán las lápidas depende de la forma en que se almacenen y recuperen los datos. Por ejemplo, si Cassandra se usa para almacenar datos en una cola (lo cual no se recomienda), las consultas pueden encontrar decenas de miles de lápidas para devolver algunas filas de datos.

¿Cómo puedo diagnosticar problemas relacionados con lápidas?

Las consultas que encuentren un gran número de lápidas aparecerán en los registros. De forma predeterminada, una lectura que encuentre más de mil lápidas generará una advertencia:

WARN org.apache.cassandra.db.ReadCommand Lee 0 filas vivas y 87051 celdas de lápida para la selección de consulta * DEL ejemplo.table

De forma predeterminada, encontrar más de 100.000 lápidas provocará que la consulta falle con una excepción Tombstoneoverwhelming.

Para verificar si las lecturas de tombstone están causando problemas de rendimiento, compruebe si las lecturas se correlacionan con un aumento de la latencia de lectura y la duración de la pausa GC.

Si está claro que las lápidas son los problemas, las siguientes técnicas pueden ayudar a reducir el alcance del problema:

• El número de lápidas devueltas en una consulta en particular se puede encontrar ejecutando la consulta en cqlsh con el rastreo habilitado.
• Las estadísticas del número de lápidas encontradas recientemente en cada tabla están disponibles en la salida de nodetool cfstats.
• Para los clústeres de nuestro servicio administrado, las estadísticas de lápidas encontradas recientemente están disponibles en la página de clústeres en Listas de métricas > Información de tabla. Esto incluye células vivas por lectura y lápidas sepulcrales medias y máximas por lectura, desglosadas por nodo o tabla para un período de tiempo determinado.
• Se puede encontrar información más detallada sobre las lápidas almacenadas utilizando ic-tools.

¿Cómo puedo evitar los problemas de lápidas?

Las siguientes opciones pueden ayudar:

• Evitar consultas que se ejecutarán en todas las particiones de la tabla (por ejemplo, consultas sin cláusula WHERE, o cualquier consulta que requiera PERMITIR EL FILTRADO).
• Altere las consultas de rango para evitar consultar datos eliminados u operar en un rango de datos más estrecho. Los problemas de rendimiento solo ocurren si se leen las lápidas y se escala con el número de lápidas leídas.
• Diseñe el modelo de datos para evitar eliminar grandes cantidades de datos.
• Si planea eliminar todos los datos de una tabla, trunque o suelte la tabla para eliminar todos los datos sin generar lápidas.
• Utilice un valor de tiempo de vida predeterminado. Esto solo funciona de manera eficiente si la clave principal de sus datos está basada en el tiempo, sus datos están escritos en orden cronológico y los datos se eliminarán en una fecha conocida. Para ello, establezca un TTL predeterminado en las opciones de nivel de tabla y establezca una estrategia de compactación basada en el tiempo (TimeWindowCompactionStrategy, si está disponible, DateTieredCompactionStrategy, de lo contrario). Esto seguirá creando lápidas, pero los sstables enteros se eliminarán de manera eficiente una vez que el TTL haya pasado por todos sus contenidos.

¿Cómo puedo deshacerme de las lápidas existentes?

En la mayoría de las circunstancias, el mejor enfoque es esperar a que la lápida se compacta normalmente. Si problemas urgentes de rendimiento o uso del disco requieren una acción más inmediata, hay dos comandos nodetool que se pueden usar para forzar compactación, lo que puede ayudar a soltar lápidas. Estos deben considerarse un último recurso – en un clúster saludable con un modelo de datos bien diseñado, no es necesario ejecutar compactación manual.

Ejecutarnodetool compact fuerza la compactación de todas las tablas. Esto requiere una gran cantidad de espacio libre en disco. Los argumentos de espacio de claves y tabla deben usarse para limitar la compactación a las tablas donde las lápidas son un problema. En las tablas donde se utiliza una Estrategia de Compactación por niveles de tamaño, este comando puede llevar a la creación de una enorme estabilidad con la que nunca tendrá pares con los que compactar; si el indicador –split-output está disponible, debe usarse.

El comando nodetool garbagecollect está disponible a partir de Cassandra 3.10. Este comando ejecuta una serie de compacciones más pequeñas que también comprueban las tablas superpuestas. Es más intensivo en CPU y consume más tiempo que nodetool compact, pero requiere menos espacio libre en disco.

Las lápidas solo se eliminarán si han transcurrido gc_grace_seconds desde que se crearon las lápidas. El propósito de gc_grace_seconds es proporcionar tiempo para reparaciones para restaurar la consistencia del clúster, así que tenga cuidado al modificarlo: la eliminación prematura de lápidas puede dar lugar a la resurrección de los datos eliminados. Además, la configuración gc_grace_seconds afecta a la caducidad de las sugerencias generadas para el traspaso insinuado, por lo que es peligroso reducir gc_grace_seconds por debajo de la duración de la ventana de traspaso insinuado (de forma predeterminada, 3 horas).

Reparaciones

Las reparaciones pueden retrasar o evitar la caída de lápidas. Cuando se ejecuta una reparación completa o incremental, las mesas afectadas se marcan como reparadas; en compacciones posteriores, estas tablas se compactarán por separado de las mesas que no se hayan reparado. Si las lápidas están en tablas sin reparar y los datos sombreados están en tablas reparadas (o viceversa), los datos no se pueden eliminar porque las tablas no se pueden compactar.
Si realiza regularmente reparaciones completas o incrementales en el clúster, esto no debería ser un problema excesivo, ya que las lápidas y los datos eventualmente terminarán reparados. Sin embargo, si tiene una combinación de datos reparados y no reparados, y no realiza reparaciones regularmente, esto puede convertirse en un problema. sstablemetadata puede ayudarlo a inspeccionar el estado reparado de sus sstables para averiguar si esto está sucediendo. Si lo es, puede ser aconsejable establecer todas las tablas como no reparadas con sstablerepairedset para que puedan compactarse juntas.Tenga en cuenta que las reparaciones de subrango no marcan los datos como reparados.