2011-12-23 57 views
7

我刚刚在一个9节点的Cassandra集群中导入了大量数据,在创建了一个新的ColumnFamily以及更多的数据之前,我希望能够确定我的集群当前有多满(根据内存使用情况)。我不太确定我需要看什么。我不想再导入另外20-30GB的数据,并意识到我应该增加5-6个节点。确定Cassandra集群的完整程度

总之,我不知道现在群集中的节点是否有太多/很多节点。

任何帮助,将不胜感激:)

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

-

[[email protected]] 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 
+1

我不是那个低估它的人,这本身就是一个很好的问题,但我猜测downvote可能是用于与Cassandra用户邮件列表交叉发布的。 – 2011-12-24 02:06:40

+0

我发布了上面的评论(因此,在downvote本身之后)之后,我实际上在Cassandra邮件列表上发布了这个*。 – Pierre 2011-12-24 02:18:46

+1

对存储(Cassandra)没有明确的功能/性能要求,也没有硬件规格建议。 – 2012-02-03 11:03:23

回答

10

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

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

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

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

您可以在Datastax的这篇出色的博客文章中详细了解压缩如何暂时增加磁盘使用量:http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra它还介绍了压缩策略。

所以要做一点容量规划,你可以计算出你需要多少空间。复制因子为3(以上使用的是),添加20-30GB的原始数据将在复制后添加60-90GB。将您的9个节点分开,每个节点可能多3GB。为每个节点添加这种磁盘使用情况是否会让您靠得太近而无法使用全部磁盘?如果是这样,您可能需要考虑向集群添加更多节点。

另一个需要注意的是,您的节点负载并不是非常均匀 - 从2GB到7GB。如果您使用的是随机的ByteOrderPartitioner,那么可能会导致环中负载不均匀和“热点”。如果可能,你应该考虑使用随机。另一种可能性可能是您需要处理额外的数据(请注意提示和快照)。考虑通过在每个节点上一次运行nodetool repairnodetool cleanup来清理它(请务必阅读那些首先执行的操作!)。

希望有所帮助。

+0

有用的提示,但你可以请让答案稍微可读。 – HeyWatchThis 2012-05-31 20:15:37

+0

只是为了澄清最大数据使用情况。使用水平压缩80-90%mac磁盘使用率是最大的,因为sstables较小。使用SizeTieredCompaction从不会超过50%,因为SSTables可能会变得非常大以至于为了紧凑,您需要足够的空间为自由空间中的最大SSTable。 – Robert 2013-11-06 20:52:22