04.06.2016

các ghi chép này được viết từ hơn một năm trước khi kiến thức về Cassandra của mình vẫn còn hạn chế, cũng như từ đó đến nay đã có rất nhiều thay đổi trong các phiên bản Cassandra mới. Các ghi chép dưới đây chỉ mang tính chất tham khảo.

Ghi chép về một số kinh nghiệm khi sử dụng Cassandra

Hạn chế sử dụng secondary index

Index được Cassandra tạo ra để tạo điều kiện dễ dàng cho các query, giống như MySQL. Tuy nhiên chức năng này chủ yếu được tạo ra để thu hút người dùng hơn là mang lại giá trị thực tiễn.

Khi dataset còn nhỏ, secondary index có vẻ hoạt động rất tốt, tuy nhiên khi lượng data nhiều hơn index không những không làm tăng tốc độ query, ngược lại tăng latency và dễ dàng fail. Ngoài ra, index cũng sẽ làm cho quá tình compaction, repair trở lên chậm chạp hơn.

Giải pháp để không sử dụng index là tạo ra các bảng mới để thực hiện query. Việc tạo bảng mới sẽ làm tăng độ trùng lặp dữ liệu tuy nhiên dabase như Cassandra khuyến khích điều này. Dung lượng không phải là một vấn đề nghiêm trọng với Cassandra.

Casandra không phù hợp cho các thay đổi thường xuyên trong cấu trúc dữ liệu

Đơn giản là khi data lớn lên, việc dịch chuyển dữ liệu khi thay đổi cấu trúc là rất phiền phức.

Backup & Restore

Công cụ backup có sẵn của Cassandra không giúp ích gì nhiều, một số công cụ hỗ trợ bên ngoài thì khó sử dụng và nhiều bugs. Việc tốt nhất bạn có thể làm là giữ cho cluster luôn khỏe mạnh.

Widerow

Về lý thuyết một row trong Cassandra có thể chứa tới 2 tỉ cột, tuy nhiên đây chỉ là trên lí thuyết. Thực tế là không nên quá 100.000 cột hay 100MB cho mỗi dòng. Các widerow quá nặng nề sẽ làm chậm query và gây ra các vấn đề lớn khi compact.

Tuy nhiên nếu không sử dụng widerow thì chẳng cần dùng Cassandra làm gì.

Replication factor bao nhiêu là phù hợp

3

Sử dụng token hay num_token

Nên bắt đầu với num_toke, sẽ tránh được phiền phức khi thêm node, giảm node, rebalance.

Tuy vậy, sử dụng num_token sẽ khiến cho thời gian repair tăng lên.

Sự cố khi thêm node