Tại sao Cassandra khuyên không nên tạo một chỉ mục trên các cột có số lượng thẻ cao?


10

Tài liệu của Cassandra nêu rõ,

Không sử dụng một chỉ mục trong những tình huống này:

  • Trên các cột có số lượng thẻ cao vì sau đó bạn truy vấn một khối lượng lớn các bản ghi cho một số lượng nhỏ kết quả. Xem các vấn đề khi sử dụng chỉ số cột cardinality cao bên dưới.

Nó tiếp tục

Nếu bạn tạo một chỉ mục trên cột có số lượng thẻ cao, có nhiều giá trị riêng biệt, một truy vấn giữa các trường sẽ phát sinh nhiều tìm kiếm cho rất ít kết quả. Trong bảng có một tỷ bài hát, việc tìm kiếm các bài hát của nhà văn (một giá trị thường là duy nhất cho mỗi bài hát) thay vì bởi nghệ sĩ của họ, có thể sẽ rất kém hiệu quả. Có lẽ sẽ hiệu quả hơn nếu duy trì thủ công bảng dưới dạng một chỉ mục thay vì sử dụng chỉ mục tích hợp Cassandra. Đối với các cột chứa dữ liệu duy nhất, đôi khi sử dụng chỉ mục để thuận tiện, miễn là khối lượng truy vấn đối với bảng có cột được lập chỉ mục là vừa phải và không tải liên tục.

Nhưng không bao giờ thực sự trả lời câu hỏi: tại sao nó không hiệu quả? Tôi không biết "duy trì thủ công bảng dưới dạng một chỉ mục" nghĩa là gì. Nhưng sau đó, nó phần nào mâu thuẫn với chính nó, "đôi khi nó rất hiệu quả khi sử dụng một chỉ mục để thuận tiện miễn là khối lượng truy vấn ở mức vừa phải"

Có phải đây chỉ là cố gắng bảo tôi sử dụng PK khi nào và ở đâu tôi có thể? Không hiệu quả là gì? Tôi hiểu rằng một truy vấn sẽ đánh vào một chỉ mục sẽ cần truy vấn mọi nút trong cụm, và sau đó mỗi nút sẽ thực hiện tra cứu trong chỉ mục cục bộ của nó và kết quả sẽ được tổng hợp. Điều này không nhất thiết phải tốn kém (mỗi lần tra cứu chỉ số nên khá rẻ) ngoại trừ việc chúng tôi trả tiền theo độ trễ mạng, vì chúng tôi phải chờ nút chậm nhất trong số rất nhiều. Tôi có thiếu thứ gì ở đây không?

Nhưng nếu tôi có một bộ sưu tập có một món đồ trị giá - trong một dịp hiếm hoi - cần phải được tra cứu bởi một thuộc tính khác nhưng gần như duy nhất thì đây là một cách sử dụng phù hợp, phải không?

VeryMọi người? IDK nếu sao chép có nghĩa là điều này có thể đạt 1/3 của cụm cho hệ số sao chép là 3 hay không?

Câu trả lời:


6

Với chỉ mục Cassandra ( tức là "chỉ mục phụ", trái ngược với khóa chính), mỗi nút phải truy vấn dữ liệu cục bộ của riêng mình để trả lời truy vấn (xem Câu hỏi thường gặp về chỉ mục phụ Cassandra ). Các chỉ số này cũng được xây dựng bằng cách sử dụng một quá trình nền . Nền tảng này có nghĩa là chỉ mục có thể trả về phủ định sai về số lần truy cập (hoặc dương tính giả về mặt sai sót).

Điều này có nghĩa là trong một cột có số lượng thẻ cao, tốc độ thay đổi ( nghĩa là bổ sung / xóa) từ cột đó có thể khá cao. Và do đó, nếu tốc độ thay đổi đó nhanh hơn so với việc cập nhật chỉ mục thông qua quá trình nền, thì việc sử dụng một chỉ mục là "không hiệu quả" (chỉ mục đang thực hiện nhiều công việc hơn mức cần thiết của ứng dụng, thường có thể trả lời sai) .

Một cách tiếp cận hiệu quả hơn, về độ chính xác của truy vấn , có thể là duy trì bảng thứ hai , thay vì chỉ mục phụ. Các bảng, trái ngược với các chỉ mục , được đối xử giống như bất kỳ bảng nào khác. Họ có nhiều khả năng cung cấp cho ứng dụng của bạn kết quả truy vấn mà nó mong đợi . Nhược điểm là việc duy trì bảng dưới dạng một chỉ mục , so với "chỉ mục phụ" của Cassandra, hiện là các ràng buộc ứng dụng ( tức là mã ứng dụng của bạn bây giờ phải biết để chèn / xóa các hàng từ bảng "chỉ mục" đó để giữ cho hai bảng được đồng bộ hóa thông qua "đối chiếu" ở cấp ứng dụng).

Hi vọng điêu nay co ich!


Các chỉ mục đó được xây dựng bằng cách sử dụng một quá trình nền là một chút xấu xí. Dương tính giả có thể nhìn thấy cho người dùng, tôi đoán? (Tôi không thấy chúng sẽ như thế nào khá cao. " - Tôi hiểu lý do tại sao tốc độ thay đổi, liên quan đến việc xây dựng chỉ số bg, sẽ rất tệ, nhưng tôi vẫn không thấy tính chính xác cao phải làm gì với nó. (Chắc chắn, ngay cả một cột có số lượng thẻ thấp cũng sẽ chịu chung số phận, phải không?)
Thanatos

Vâng, một cột cardinality thấp sẽ chịu chung số phận. Suy nghĩ của tôi có một chút mờ nhạt ở đó, tôi thừa nhận. Tôi đã giả định rằng một chỉ số cardinality cao sẽ có nhiều khả năng có tỷ lệ thay đổi cao hơn (do đó nhiều khả năng thể hiện kết quả dương tính / âm tính giả); đó là tốc độ thay đổi (liên quan đến quá trình lập chỉ mục nền) có liên quan nhất, không phải là tính chính xác.
Castaglia

2

Một số thuật ngữ: Bảng cha là bảng mà chỉ mục được tạo. Bảng chỉ mục phụ là bảng được tạo để duy trì chỉ mục trên bảng khác.

Dữ liệu của bảng chỉ mục phụ được lưu trữ trên cùng một nút với dữ liệu của bảng cha. Trình phân vùng Cassandra không phân vùng và phân phối dữ liệu bảng chỉ mục. Vì vậy, nếu bạn muốn thực hiện tra cứu trên một cột chỉ mục, tất cả các nút được truy vấn, không chỉ các nút sao chép có chứa dữ liệu. (nút điều phối viên không biết dữ liệu nằm ở đâu) https://www.datastax.com/dev/blog/cassandra-native-secondary-index-deep-dive

Đối với các cột cardinality cao như ssn hoặc một số id duy nhất khác, sẽ có một ánh xạ một đến một với khóa chính. Nếu bạn tạo một chỉ mục trên cột như vậy, dữ liệu sẽ nằm trên số lượng nhân tố của các nút, nhưng lệnh gọi tra cứu được thực hiện trên tất cả các nút. Trong trường hợp tốt nhất, điều phối viên trực tiếp nhấn vào các nút có chứa dữ liệu và Một khi mức độ nhất quán được đáp ứng, bạn sẽ nhận được kết quả của mình. Tệ nhất, nếu dữ liệu bạn đang tìm kiếm, không có trong chỉ mục, bạn đợi cho đến khi tất cả các nút phản hồi để thấy rằng dữ liệu không có ở đó. Vì vậy, đối với mỗi lệnh gọi tra cứu trên bảng chỉ mục phụ, tất cả các nút đều được nhấn. So sánh rằng chỉ với số lượng nhân tố của các nút được nhấn cho mỗi cuộc gọi tra cứu, trong trường hợp bảng là bảng C * bình thường.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.