2011-12-23 3 views
7

Tôi vừa nhập rất nhiều dữ liệu trong cụm nút Cassandra 9 và trước khi tạo một ColumnFamily mới với nhiều dữ liệu hơn, tôi muốn có thể xác định xem cụm hiện tại của mình đầy đủ như thế nào (về mặt sử dụng bộ nhớ). Tôi không chắc chắn những gì tôi cần phải xem xét. Tôi không muốn nhập 20-30GB dữ liệu khác và nhận ra rằng tôi nên thêm 5-6 nút nữa.Xác định xem cụm Cassandra đầy đủ là

Tóm lại, tôi không biết liệu tôi có quá ít/nhiều nút ngay bây giờ cho những gì trong cụm.

Bất kỳ trợ giúp sẽ được đánh giá cao :)

$ 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

Tôi không phải là người đã downvoted nó, và đó là một câu hỏi hay, nhưng tôi đoán downvote có thể đã được đăng tải chéo với danh sách gửi thư của người dùng Cassandra. –

+0

Tôi thực sự đăng bài này trên danh sách gửi thư của Cassandra * sau * Tôi đã đăng bình luận ở trên (và do đó, sau bản thân downvote). – Pierre

+1

Không yêu cầu chức năng/hiệu suất rõ ràng đối với bộ lưu trữ (Cassandra), cũng như thông số kỹ thuật của HW để đề xuất. –

Trả lời

10

Rõ ràng, có hai loại bộ nhớ - đĩa và RAM. Tôi sẽ giả sử bạn đang nói về không gian đĩa.

Trước tiên, bạn nên tìm hiểu bạn đang sử dụng bao nhiêu dung lượng cho mỗi nút. Kiểm tra việc sử dụng trên đĩa của thư mục dữ liệu cassandra (theo mặc định /var/lib/cassandra/data) với lệnh này: du -ch /var/lib/cassandra/data Sau đó bạn nên so sánh với kích thước đĩa của bạn, có thể được tìm thấy với df -h. Chỉ xem xét mục nhập cho các kết quả df cho đĩa dữ liệu cassandra của bạn được bật, bằng cách kiểm tra cột được gắn trên.

Sử dụng các số liệu thống kê đó, bạn sẽ có thể tính toán mức độ đầy đủ của% phân vùng dữ liệu cassandra. Nói chung bạn không muốn quá gần 100% bởi vì quá trình nén thông thường của cassandra tạm thời sử dụng nhiều không gian đĩa hơn. Nếu bạn không có đủ, thì một nút có thể bị bắt với một đĩa đầy đủ, có thể gây đau đớn (như tôi lưu ý bên cạnh tôi thỉnh thoảng giữ một tệp "dằn" của một vài hợp đồng biểu diễn mà tôi có thể xóa chỉ trong trường hợp tôi cần mở thêm không gian). Tôi thường thấy rằng không quá 70% mức sử dụng đĩa là ở bên an toàn cho dòng 0.8.

Nếu bạn đang sử dụng phiên bản mới hơn của cassandra, thì tôi khuyên bạn nên đưa chiến lược Mức độ tương tác lên một ảnh để giảm mức sử dụng đĩa tạm thời. Thay vì có khả năng sử dụng gấp đôi dung lượng đĩa, chiến lược mới sẽ sử dụng tối đa 10x kích thước cố định nhỏ (mặc định là 5MB).

Bạn có thể đọc thêm về cách nén tạm thời tăng mức sử dụng đĩa trên bài đăng tuyệt vời trên blog này từ Datastax: http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra Nó cũng giải thích các chiến lược nén chặt.

Vì vậy, để lập kế hoạch dung lượng nhỏ, bạn có thể tìm ra dung lượng cần thiết. Với hệ số nhân rộng là 3 (những gì bạn đang sử dụng ở trên), việc thêm 20-30GB dữ liệu thô sẽ thêm 60-90GB sau khi sao chép. Phân chia giữa 9 nút của bạn, có thể là 3GB trên mỗi nút. Việc thêm loại sử dụng đĩa đó cho mỗi nút có đẩy bạn quá gần để có đĩa đầy đủ không? Nếu có, bạn có thể muốn xem xét thêm các nút khác vào cụm.

Một lưu ý khác là tải của các nút của bạn không phải là rất đều - từ 2GB đến 7GB. Nếu bạn đang sử dụng ByteOrderPartitioner trên một ngẫu nhiên, sau đó có thể gây tải không đồng đều và "điểm nóng" trong vòng của bạn. Bạn nên cân nhắc sử dụng ngẫu nhiên nếu có thể. Các khả năng khác có thể là bạn có thêm dữ liệu treo ra mà cần phải được chăm sóc (Hinted Handoffs và ảnh chụp nhanh đến tâm). Cân nhắc làm sạch điều đó bằng cách chạy nodetool repairnodetool cleanup trên mỗi nút tại một thời điểm (hãy nhớ đọc kỹ những gì trước tiên!).

Hy vọng điều đó sẽ hữu ích.

+0

Mẹo hữu ích, nhưng bạn có thể làm cho câu trả lời dễ đọc hơn một chút không. – HeyWatchThis

+0

Chỉ cần làm rõ việc sử dụng dữ liệu tối đa. Với mức độ nén 80-90%, mức sử dụng đĩa mac là tối đa vì sstables nhỏ hơn. Với SizeTieredCompaction không bao giờ vượt quá 50% vì SSTables có thể quá lớn đến nỗi để gọn nhẹ, bạn cần đủ không gian cho SSTable lớn nhất của bạn trong không gian trống. – Robert