cassandra - vista - sunset valley sims

¿Qué sucede exactamente cuando se alcanza el límite de lápida?

Question

De acuerdo con el registro de cassandra (ver más abajo) las consultas se abortan debido a la presencia de demasiadas tombstones . Esto está sucediendo porque una vez a la semana limpio (borro) filas con un contador que es muy bajo. Esto ''elimina'' cientos de miles de filas (las marca como tales con una tombstone ).

No es en absoluto un problema si, en esta tabla, una fila eliminada vuelve a aparecer debido a que un nodo estuvo inactivo durante el proceso de limpieza, por lo que establezco el gc grace time para la única tabla afectada en 10 horas (menos de los 10 días predeterminados). ) por lo que las filas desechadas se pueden eliminar de forma permanente de forma relativamente rápida.

En cualquier caso, tuve que establecer el tombstone_failure_threshold extremadamente alto para evitar la siguiente excepción. (cien millones, de cien mil). Mi pregunta es: ¿es esto necesario? No tengo ni idea de qué tipo de consultas se abortan; ¿Inserta, selecciona, borra?

Si se trata simplemente de que algunas selecciones sean abortadas, no es tan importante. Pero eso es suponiendo que abortar significa "limitado" en el sentido de que la consulta se detiene prematuramente y devuelve todos los datos en vivo que logró reunir antes de que se encontraran demasiadas lápidas.

Bueno, para pedirlo más sencillo; ¿Qué sucede cuando se supera el umbral_tombstone_failure_threshold?

INFO [HintedHandoff:36] 2014-02-12 17:44:22,355 HintedHandOffManager.java (line 323) Started hinted handoff for host: fb04ad4c-xxxx-4516-8569-xxxxxxxxx with IP: /XX.XX.XXX.XX
ERROR [HintedHandoff:36] 2014-02-12 17:44:22,667 SliceQueryFilter.java (line 200) Scanned over 100000 tombstones; query aborted (see tombstone_fail_threshold)
ERROR [HintedHandoff:36] 2014-02-12 17:44:22,668 CassandraDaemon.java (line 187) Exception in thread Thread[HintedHandoff:36,1,main]
org.apache.cassandra.db.filter.TombstoneOverwhelmingException
at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:201)
at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:122)
at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:80)
at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:72)
at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:297)
at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1516)
at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1335)
at org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:351)
at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:309)
at org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:92)
at org.apache.cassandra.db.HintedHandOffManager$4.run(HintedHandOffManager.java:530)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

Olvide mencionar; corriendo la versión 2.0.4 Cassandra

Answer 1

Cuando se envía a Cassandra una consulta que devuelve un rango de filas (o columnas), tiene que escanear la tabla para recopilar el conjunto de resultados (esto se denomina sector). Ahora, los datos eliminados se almacenan de la misma manera que los datos normales, excepto que están marcados como guardados hasta que se compactan. Pero el lector de mesa tiene que escanearlo sin embargo. Por lo tanto, si tiene toneladas de lápidas sepulcrales por ahí, tendrá una gran cantidad de trabajo que hacer para satisfacer su porción aparentemente limitada.

Un ejemplo concreto: digamos que tiene dos filas con las claves de agrupación 1 y 3, y cien mil filas muertas con la clave de agrupación 2 que se encuentran entre las filas 1 y 3 en la tabla. Ahora, cuando emita una consulta SELECT donde la clave será> = 1 y <3, deberá escanear 100002 filas, en lugar de las dos esperadas.

Para empeorar las cosas, Cassandra no solo explora estas filas, sino que también tiene que acumularlas en la memoria mientras prepara la respuesta. Esto puede causar un error de memoria insuficiente en el nodo si las cosas salen demasiado lejos, y si varios nodos atienden la solicitud, incluso puede causar una falla múltiple que desactive todo el clúster. Para evitar que esto suceda, el servicio cancela la consulta si detecta un número peligroso de lápidas. Eres libre de ponerlo en marcha, pero es arriesgado, si tu montón de Cassandra está cerca de agotarse durante estos picos.

Esta excepción se introdujo en una solución reciente, primero disponible en 2.0.2. Here está la entrada de error que describe el problema que el cambio estaba tratando de resolver. Anteriormente, todo habría estado bien, hasta que uno de sus nodos, o potencialmente varios, se estrelló repentinamente.

Si se trata simplemente de que algunas selecciones sean abortadas, no es tan importante. Pero eso es suponiendo que abortar significa "limitado" en el sentido de que la consulta se detiene prematuramente y devuelve todos los datos en vivo que logró reunir antes de que se encontraran demasiadas lápidas.

La consulta no devuelve un conjunto limitado, en realidad elimina la solicitud por completo. Si desea mitigar, tal vez valga la pena hacer la eliminación masiva de su fila con la misma cadencia que el período de gracia, por lo que no tiene esta gran afluencia de lápidas cada semana.