Hiệu suất Cassandra cho các hàng dài

Question

Tôi đang xem xét việc triển khai CF trong Cassandra có hàng rất dài (hàng trăm nghìn đến hàng triệu cột mỗi hàng).

Sử dụng dữ liệu giả hoàn toàn, tôi đã chèn 2 triệu cột vào một hàng duy nhất (khoảng cách đều nhau). Nếu tôi thực hiện một thao tác cắt lát để có được 20 cột, sau đó tôi nhận thấy một sự suy giảm hiệu suất lớn khi bạn thực hiện thao tác cắt lát của bạn xuống dưới hàng. Với hầu hết các cột, tôi dường như có thể phục vụ kết quả lát trong 10-40ms, nhưng khi bạn nhận được vào cuối hàng, hiệu suất chạm vào tường, với thời gian đáp ứng dần dần tăng từ 43ms tại 1.800.000 đánh dấu đến 214ms tại 1.900.000 và 435ms tại 1.999.900! (Tất cả các lát có chiều rộng bằng nhau).

Tôi đang mất một giải thích tại sao có sự suy giảm nghiêm trọng này về hiệu suất khi bạn đến cuối hàng. Ai đó có thể vui lòng cung cấp một số hướng dẫn về những gì Cassandra đang làm trong nội bộ để thực hiện một sự chậm trễ như vậy? Row caching bị tắt và khá nhiều thứ là cài đặt Cassandra 1.0 mặc định.

Giả sử có thể hỗ trợ tối đa 2 tỷ cột mỗi hàng, nhưng với tốc độ tăng hiệu suất này có nghĩa là nó không thể được sử dụng cho các hàng rất dài trong tình huống thực tế.

Rất cám ơn. Hãy nhớ rằng, tôi sẽ nhấn 10 yêu cầu song song tại một thời điểm, đó là lý do tại sao chúng chậm hơn một chút so với mong đợi của tôi, nhưng đó là một thử nghiệm công bằng trên tất cả các yêu cầu và thậm chí chỉ cần thực hiện tất cả các yêu cầu trong sê-ri có sự xuống cấp kỳ lạ này giữa kỷ lục 1.800.000 và 1.900.000.

Tôi cũng nhận thấy hiệu suất cực thấp khi thực hiện đảo ngược lát chỉ cho một mục khi chỉ có 200.000 cột mỗi hàng: query.setRange (kết thúc, bắt đầu, sai, 1);

Answer 1

nhận xét của psanford đã dẫn tôi đến câu trả lời. Nó chỉ ra rằng Cassandra < 1.1.0 (hiện đang trong phiên bản beta) có hiệu suất chậm trên lát trên hàng dài trong Memtables (chưa được flushed vào đĩa) nhưng hiệu suất tốt hơn trên SSTables đỏ lên đĩa với cùng một dữ liệu.

xem http://mail-archives.apache.org/mod_mbox/cassandra-user/201201.mbox/%3CCAA_K6YvZ=vd=Bjk6BaEg41_r1gfjFaa63uNSXQKxgeB-oq2e5A@mail.gmail.com%3E và https://issues.apache.org/jira/browse/CASSANDRA-3545.

Với ví dụ của tôi, số 1 đầu tiên.8 triệu hàng đã được chuyển sang đĩa, vì vậy các lát trên phạm vi đó nhanh chóng, nhưng ~ 200.000 hàng cuối cùng đã không được rửa sạch vào đĩa và vẫn còn trong memtables. Do việc cắt hình memtables chậm trên các hàng dài nên đây là lý do tại sao tôi thấy hiệu năng kém ở cuối hàng (dữ liệu của tôi được chèn vào thứ tự cột).

Điều này có thể được khắc phục bằng cách gọi thủ công một lần xả trên các nút cassandra. Một bản vá đã được áp dụng cho 1.1.0 để khắc phục điều này và tôi có thể xác nhận rằng bản vá này khắc phục sự cố cho tôi.

Tôi hy vọng điều này sẽ giúp bất kỳ ai khác có cùng vấn đề.

Answer 2

Một tài nguyên tốt về điều này là bài đăng trên blog của Aaron Morton trên Cassandra's Reversed Comparators. Từ bài viết:

Nhớ lại từ bài đăng của tôi trên Cassandra Query Plans rằng một khi các hàng đạt đến một kích thước nhất định, chúng bao gồm chỉ mục của các cột. Và rằng toàn bộ chỉ mục phải được đọc bất cứ khi nào bất kỳ phần nào của chỉ mục cần được sử dụng, đó là trường hợp khi sử dụng một phạm vi Slice chỉ định bắt đầu hoặc đảo ngược. Vì vậy, truy vấn slice nhanh nhất để chạy với một hàng là truy vấn truy lục các cột X đầu tiên trong một hàng bằng cách chỉ định số cột.

Nếu bạn đang chủ yếu là đọc từ ngày kết thúc của một hàng (ví dụ như nếu bạn đang lưu trữ mọi thứ bởi dấu thời gian và bạn chủ yếu là muốn nhìn vào số liệu gần đây), bạn có thể sử dụng Reversed Comparator mà các cửa hàng bạn cột thứ tự giảm dần. Điều này sẽ cung cấp cho bạn hiệu suất truy vấn tốt hơn (và phù hợp hơn).

Nếu các mẫu đọc của bạn ngẫu nhiên hơn, bạn có thể phân tách dữ liệu của mình tốt hơn trên nhiều hàng.