Cassandra: mantenimiento

No tengo experiencia con Cassandra, pero tengo algo de experiencia con bases de datos relacionales basadas en SQL.

No he podido encontrar información sobre las mejores prácticas sobre cómo mantener Cassandra una vez implementado. ¿Es necesario aspirar la base de datos? Debería pensar que las cargas de lectura / escritura causan fragmentación en el almacenamiento.

O, en general, ¿cuáles son las mejores prácticas para mantener una implementación de producción de Cassandra? ¿Qué se debe hacer a intervalos regulares para mantener la salud del sistema? El manual de operaciones realmente no discute este aspecto.

Gracias.

En general, un clúster bien diseñado puede vivir AÑOS sin ser tocado. He tenido grupos que se ejecutaron durante años sin intervención. Sin embargo, aquí hay algunas pautas:

El monitoreo es muy importante:

1) Monitorizar latencias. Utilice opscenter o sus herramientas de métricas favoritas para realizar un seguimiento de las latencias. Las latencias que aumentan pueden ser signos de problemas, incluidas las pausas de GC (más comunes en las cargas de trabajo de lectura que en las cargas de trabajo de escritura), problemas estables y similares.

2) Monitorear recuentos estables. Los recuentos de SSTable aumentarán si se sobrepasa la compactación (cada inestable se escribe exactamente una vez; las eliminaciones se manejan combinando inestables antiguos en inestables nuevos mediante la compactación).

3) Supervisar los cambios de estado del nodo (arriba / abajo, etc.). Si ve aleteo de nodos, investigue, ya que no es normal.

4) Realice un seguimiento del uso de su disco: tradicionalmente, debe mantenerse por debajo del 50% (especialmente si usa compactación STCS).

Hay algunas cosas básicas que debes y no debes hacer regularmente:

1) No corras explícitamente nodetool compact. Menciona que lo ha hecho, no es fatal, pero crea inestables muy grandes, que luego son menos propensos a participar en la compactación en el futuro. No necesariamente necesita seguir ejecutándolo, pero a veces puede ayudar deshacerse de los datos eliminados / sobrescritos.

2) nodetool repairgeneralmente se recomienda cada gc_grace_seconds(10 días por defecto). Hay cargas de trabajo donde esto es menos importante: la razón principal por la que NECESITA reparación es para asegurarse de que los marcadores de eliminación ( tombstones) se transmitan antes de que caduquen (viven gc_grace_seconds, si un nodo está inactivo cuando ocurrió la eliminación, esos datos pueden volver a la vida sin la reparación! Si no emite eliminaciones y consulta con un nivel de consistencia suficiente (por ejemplo, lecturas y escrituras en QUORUM), puede vivir una vida sin reparación.

3) Si va a reparar, considere usar una reparación incremental y repare rangos pequeños a la vez.

4) Las estrategias de compactación son importantes. STCS es ideal para escrituras, LCS es ideal para lecturas. DTCS tiene algunas peculiaridades.

5) Los modelos de datos son importantes: al igual que los entornos RDBMS / SQL se meten en problemas cuando las consultas no indexadas llegan a tablas grandes, Cassandra puede ser problemática con filas / particiones muy grandes.

6) Las instantáneas son baratas. Muy barato. Casi instantáneamente, solo enlaces duros, casi no cuestan espacio en el disco de inmediato. Utilice la instantánea antes de actualizar las versiones, especialmente las versiones principales.

7) Tenga cuidado con los borrados. Como se insinuó en el n. ° 2, eliminar crea más datos en el disco y no los libera AL MENOS gc_grace_seconds.

Cuando todo lo demás falla:

He visto artículos que sugieren que Cassandra en producción requiere una cabeza dedicada para administrar cualquier clúster de tamaño; no sé si sea necesariamente cierto, pero si le preocupa, puede contratar a un consultor externo (TheLastPickle, Pythian). ) o tener un contrato de soporte (Datastax) para darle tranquilidad.

De acuerdo con la documentación de reparación de Cassandra , nodetool repairdebe ejecutarse en las siguientes situaciones:

• Como práctica recomendada, debe programar reparaciones semanalmente. Nota: Si nunca se producen eliminaciones, aún debe programar reparaciones regulares. Tenga en cuenta que establecer una columna en nulo es una eliminación.
• Durante la recuperación del nodo. Por ejemplo, al traer un nodo de vuelta al clúster después de una falla.
• En nodos que contienen datos que no se leen con frecuencia.
• Para actualizar datos en un nodo que ha estado inactivo.

Debería pensar que las cargas de lectura / escritura causan fragmentación en el almacenamiento.

Los datos en Cassandra no se "fragmentan" en la forma en que está pensando. Sin embargo, las eliminaciones activan la colocación de lápidas, y el proceso compacto normal elimina las lápidas.

Ahora entiendo que la compactación es un gran problema y se ejecuta automáticamente

Correcto. Un representante de DataStax me dijo que una vez que ejecute compactmanualmente, siempre tendrá que ejecutarlo manualmente. La razón es que la compactación funciona al "compactar" todos los SSTABLES existentes en un espacio de claves en un solo archivo SSTABLE. Puede tener algunas familias de columnas en ese archivo SSTABLE que son pequeñas, y tomará tanto tiempo aumentar más allá del umbral de compactación, que la probabilidad de que la compactación automática vuelva a ejecutarse es muy baja.

Esencialmente, asegúrese de programar un programa regular nodetool repair, nunca ejecutar nodetool compacte implementar una estrategia de respaldo (instantáneas, respaldos incrementales, o ambos).