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然后，您应该将其与磁盘大小进行比较，该大小可以通过{{1}找到}。通过选中Mounted on列，只考虑cassandra数据所在磁盘的df -h结果条目。

使用这些统计信息，您应该能够计算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和快照会浮现在脑海中）。考虑通过一次一个地在每个节点上运行df和nodetool repair来清理它（请务必阅读那些先做的事情！）。

希望有所帮助。

确定Cassandra集群的完整程度

1 个答案: