确定Cassandra集群的完整程度

我刚刚在一个9节点的Cassandra集群中导入了大量数据,在我创建一个包含更多数据的新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
显然,有两种类型的内存 – 磁盘和RAM.我假设你在谈论磁盘空间.

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

使用这些统计信息,您应该能够计算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来清理它(请务必阅读那些先做的事情!).

希望有所帮助.

相关文章
相关标签/搜索