cassandra - 确定 Cassandra 集群有多满

Question

我刚刚在一个 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

Answer 1

显然，有两种类型的内存——磁盘和 RAM。我假设你在谈论磁盘空间。

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

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

如果您使用的是较新版本的 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在每个节点上一次一个(一定要阅读那些首先做什么!)。

希望有帮助。