determinar cómo llena un grupo Cassandra es

Question

simplemente he importado una gran cantidad de datos en un clúster 9 de Cassandra nodo y antes de crear un nuevo ColumnFamily con aún más datos, me gustaría ser capaz de determinar qué tan lleno de mi grupo es actualmente (en términos de uso de memoria). No estoy muy seguro de lo que necesito ver. No quiero importar otros 20-30 GB de datos y darse cuenta de que debería haber agregado otros 5-6 nodos.

En resumen, no tengo idea de si tengo muy pocos/muchos nodos en este momento para lo que hay en el clúster.

Cualquier ayuda sería muy apreciada :)

$ nodetool -h 192.168.1.87 ring 
Address   DC   Rack  Status State Load   Owns Token          
                       151236607520417094872610936636341427313  
192.168.1.87 datacenter1 rack1  Up  Normal 7.19 GB   11.11% 0           
192.168.1.86 datacenter1 rack1  Up  Normal 7.18 GB   11.11% 18904575940052136859076367079542678414  
192.168.1.88 datacenter1 rack1  Up  Normal 7.23 GB   11.11% 37809151880104273718152734159085356828  
192.168.1.84 datacenter1 rack1  Up  Normal 4.2 GB   11.11% 567137278201564105772291
192.168.1.85 datacenter1 rack1  Up  Normal 4.25 GB   11.11% 75618303760208547436305468318170713656  
192.168.1.82 datacenter1 rack1  Up  Normal 4.1 GB   11.11% 94522879700260684295381835397713392071  
192.168.1.89 datacenter1 rack1  Up  Normal 4.83 GB   11.11% 113427455640312821154458202477256070485  
192.168.1.51 datacenter1 rack1  Up  Normal 2.24 GB   11.11% 132332031580364958013534569556798748899  
192.168.1.25 datacenter1 rack1  Up  Normal 3.06 GB   11.11% 151236607520417094872610936636341427313 

-

# nodetool -h 192.168.1.87 cfstats 
    Keyspace: stats 
    Read Count: 232 
    Read Latency: 39.191931034482764 ms. 
    Write Count: 160678758 
    Write Latency: 0.0492021849459404 ms. 
    Pending Tasks: 0 
    Column Family: DailyStats 
    SSTable count: 5267 
    Space used (live): 7710048931 
    Space used (total): 7710048931 
    Number of Keys (estimate): 10701952 
    Memtable Columns Count: 4401 
    Memtable Data Size: 23384563 
    Memtable Switch Count: 14368 
    Read Count: 232 
    Read Latency: 29.047 ms. 
    Write Count: 160678813 
    Write Latency: 0.053 ms. 
    Pending Tasks: 0 
    Bloom Filter False Postives: 0 
    Bloom Filter False Ratio: 0.00000 
    Bloom Filter Space Used: 115533264 
    Key cache capacity: 200000 
    Key cache size: 1894 
    Key cache hit rate: 0.627906976744186 
    Row cache: disabled 
    Compacted row minimum size: 216 
    Compacted row maximum size: 42510 
    Compacted row mean size: 3453 

-

[default@stats] describe; 
Keyspace: stats: 
    Replication Strategy: org.apache.cassandra.locator.SimpleStrategy 
    Durable Writes: true 
    Options: [replication_factor:3] 
    Column Families: 
    ColumnFamily: DailyStats (Super) 
     Key Validation Class: org.apache.cassandra.db.marshal.BytesType 
     Default column value validator: org.apache.cassandra.db.marshal.UTF8Type 
     Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type/org.apache.cassandra.db.marshal.UTF8Type 
     Row cache size/save period in seconds/keys to save : 0.0/0/all 
     Row Cache Provider: org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider 
     Key cache size/save period in seconds: 200000.0/14400 
     GC grace seconds: 864000 
     Compaction min/max thresholds: 4/32 
     Read repair chance: 1.0 
     Replicate on write: true 
     Built indexes: [] 
     Column Metadata: 
     (removed) 
     Compaction Strategy: org.apache.cassandra.db.compaction.LeveledCompactionStrategy 
     Compression Options: 
     sstable_compression: org.apache.cassandra.io.compress.SnappyCompressor 

Answer 1

Obviamente, hay dos tipos de memoria - de disco y la memoria RAM. Voy a suponer que estás hablando de espacio en disco.

En primer lugar, debe averiguar cuánto espacio está utilizando actualmente por nodo. Verifique el uso en disco del directorio de datos de cassandra (de forma predeterminada /var/lib/cassandra/data) con este comando: du -ch /var/lib/cassandra/data Debe compararlo con el tamaño de su disco, que se puede encontrar con df -h. Solo tenga en cuenta la entrada para los resultados del df del disco en el que están sus datos de cassandra, marcando la columna Montado en.

Usando esas estadísticas, debería poder calcular qué tan completo está en% la partición de datos de cassandra. En general, no desea acercarse demasiado al 100% porque los procesos de compactación normales de cassandra utilizan temporalmente más espacio en disco. Si no tienes suficiente, un nodo puede quedar atrapado con un disco lleno, lo que puede ser difícil de resolver (como noté de vez en cuando, ocasionalmente guardo un archivo de "lastre" de algunos Gigs que puedo eliminar solo en caso de que necesita abrir un poco de espacio extra). En general, he descubierto que no exceder el 70% del uso del disco es seguro para la serie 0.8.

Si está utilizando una versión más reciente de Cassandra, entonces me recomiendan la administración de la estrategia de compactación Nivelado un tiro para reducir el uso del disco temporal. En lugar de utilizar potencialmente el doble de espacio en disco, la nueva estrategia usará como máximo 10x de un tamaño fijo pequeño (5 MB por defecto).

Puede leer más acerca de cómo la compactación aumenta temporalmente el uso del disco en esta excelente publicación de blog de Datastax: http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra También explica las estrategias de compactación.

Por lo tanto, para planificar un poco la capacidad, puede calcular cuánto espacio necesitará. Con un factor de replicación de 3 (lo que está utilizando anteriormente), agregar 20-30 GB de datos sin procesar agregaría 60-90 GB después de la replicación. Dividir entre sus 9 nodos, eso es quizás 3GB más por nodo. ¿Agregar ese tipo de uso de disco por nodo lo empuja demasiado para tener discos completos? Si es así, es posible que desee considerar agregar más nodos al clúster.

Otra nota es que las cargas de los nodos no son muy parecidas, desde 2 GB hasta 7 GB. Si está utilizando el ByteOrderPartitioner sobre el aleatorio, entonces puede causar una carga desigual y "puntos de acceso" en su anillo. Debes considerar usar al azar si es posible. La otra posibilidad podría ser que tenga datos adicionales que deban tenerse en cuenta (se le vienen a la mente los Hoff Handoffs y las instantáneas). Considere la posibilidad de limpiarlo ejecutando nodetool repair y nodetool cleanup en cada nodo de a uno por vez (¡asegúrese de leer lo que hacen primero!).

Espero que ayude.