确定Cassandra集群的完整程度

Question

我刚刚导入了大量的数据在9节点集群卡桑德拉之前,我创建一个新的ColumnFamily甚至更多的数据,我希望能够确定我的集群目前有多满(在内存使用方面).我不太清楚我需要注意什么.我不想导入另外20-30GB的数据,并意识到我应该增加5-6个节点.

简而言之,我不知道我现在是否有太少/很多节点用于集群中的内容.

任何帮助将不胜感激 :)

$ 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%  56713727820156410577229101238628035242      
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

显然,有两种类型的内存 - 磁盘和RAM.我假设你在谈论磁盘空间.

首先,您应该了解每个节点当前使用的空间大小.使用/var/lib/cassandra/data此命令检查cassandra数据目录的磁盘使用情况(默认情况下):du -ch /var/lib/cassandra/data 然后应将其与磁盘大小进行比较,可以在其中找到df -h.df通过选中Mounted on列,只考虑cassandra数据所在磁盘的结果条目.

使用这些统计信息,您应该能够计算cassandra数据分区的百分比.通常,您不希望太接近100%,因为cassandra的正常压缩过程暂时使用更多的磁盘空间.如果你没有足够的,那么一个节点可能会被一个完整的磁盘捕获,这可能很难解决(因为我注意到我偶尔会保留一些我可以删除的Gigs的"镇流器"文件,以防万一需要打开一些额外的空间).我一般发现0.8系列的磁盘使用率不超过70%是安全的.

如果您使用的是较新版本的cassandra,那么我建议您使用Leveled Compaction策略来减少临时磁盘使用量.新策略最多只使用固定大小的10倍(默认为5MB),而不是可能使用两倍的磁盘空间.

您可以从Datastax的这篇优秀博客文章中了解更多有关压缩如何暂时增加磁盘使用量的信息:http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra 它还解释了压缩策略.

因此,为了进行一些容量规划,您可以计算出您需要多少空间.复制因子为3(您在上面使用的内容),添加20-30GB的原始数据将在复制后增加60-90GB.在9个节点之间拆分,每个节点可能多3GB.是否每个节点添加这种磁盘使用量会使您太接近拥有完整磁盘？如果是这样,您可能需要考虑向群集添加更多节点.

另一个注意事项是节点的负载不是很均匀 - 从2GB到7GB.如果您使用ByteOrderPartitioner而不是随机的那个,则可能导致环中负载不均匀和"热点".如果可能,您应该考虑使用随机.另一种可能是您需要处理剩余的额外数据(Hinted Handoffs和快照会浮现在脑海中).考虑通过一次一个地运行nodetool repair和nodetool cleanup在每个节点上清理它(确保先阅读那些先做的事情!).

希望有所帮助.