确定Cassandra集群的满度

Question

我刚刚在一个9节点的Cassandra集群中导入了大量数据，在创建一个包含更多数据的新ColumnFamily之前，我希望能够确定我的集群当前有多满(就内存使用量而言)。我不太确定我需要看什么。我不想再导入20-30‘t的数据，然后意识到我应该再添加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。我假设你说的是磁盘空间。

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

使用这些统计数据，您应该能够计算出% cassandra数据分区中有多满。通常，您不希望太接近100%，因为cassandra的正常压缩过程会临时使用更多磁盘空间。如果你没有足够的空间，那么一个节点可能会被磁盘填满，这可能是很难解决的(正如我附带指出的，我偶尔会保留一个包含几个of的“压载”文件，我可以删除这些文件，以防我需要打开一些额外的空间)。我通常发现，对于0.8系列来说，磁盘使用率不超过70%是安全的。

如果您使用的是较新版本的cassandra，那么我建议您尝试使用Leveled Compaction策略来减少临时磁盘使用量。新的策略不会潜在地使用两倍的磁盘空间，而是最多使用小的固定大小的10倍(默认情况下为5MB)。

你可以在Datastax：http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra上的这篇优秀的博客文章上阅读更多关于压缩如何临时增加磁盘使用量的内容，它还解释了压缩策略。

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

另一个需要注意的是，您的节点的负载并不是非常均匀--从2 7GB到7 7GB。如果你使用的是ByteOrderPartitioner而不是随机的，那么这可能会导致负载不均匀和环中的“热点”。如果可能，您应该考虑使用随机数。另一种可能是，您有额外的数据挂起，需要处理(隐含的移交和快照)。考虑通过在每个节点上一次一个地运行nodetool repair和nodetool cleanup来清理它(请务必先阅读它们做了什么！)。

希望这能有所帮助。