Lưu trữ Cassandra bên trong

Question

Tôi đang cố gắng hiểu chính xác những gì xảy ra trong nội bộ ở mức công cụ lưu trữ khi một hàng (cột) được chèn vào trong một bảng kiểu CQL.

CREATE TABLE log_date (
    userid bigint, 
    time timeuuid, 
    category text, 
    subcategory text, 
    itemid text, 
    count int, 
    price int, 
    PRIMARY KEY ((userid), time) - #1 
    PRIMARY KEY ((userid), time, category, subcategory, itemid, count, price) - #2 
); 

Giả sử rằng tôi có bảng như trên.

Trong trường hợp # 1, hàng CQL sẽ tạo 6 cột (hoặc 5?) Trong bộ nhớ.
Trong trường hợp # 2, hàng CQL sẽ tạo một cột rất tổng hợp trong bộ nhớ.

Tôi tự hỏi cách nào hiệu quả hơn để lưu trữ nhật ký vào Cassandra.
Hãy tập trung vào hai tình huống đó.
Tôi không cần bất kỳ lần đọc thời gian thực nào. Chỉ những tác phẩm.

Nếu bạn muốn đề xuất các tùy chọn khác, vui lòng tham khảo những điều sau đây.
Lý do tôi chọn Cassandra để lưu trữ nhật ký là

1. Khả năng mở rộng tuyến tính và tốt cho chữ viết nặng.
2. Nó có lược đồ trong CQL. Tôi thực sự thích có một lược đồ.
3. Dường như hỗ trợ Spark đủ tốt. Đầu nối cassandra-spark của Datastax dường như có nhận thức về địa phương dữ liệu.

Answer 1

Tôi đang cố gắng hiểu chính xác những gì xảy ra bên trong mức công cụ lưu trữ khi một hàng (cột) được chèn vào bảng kiểu CQL.

Hãy nói rằng tôi xây dựng bảng với cả hai từ khóa chính của bạn, và INSERT một số dữ liệu:

aploetz@cqlsh:stackoverflow2> SELECT userid, time, dateof(time), category, subcategory, itemid, count, price FROM log_date1; 

userid | time         | dateof(time)    | category | subcategory | itemid   | count | price 
--------+--------------------------------------+--------------------------+----------+----------------+-------------------+-------+------- 
    1002 | e2f67ec0-f588-11e4-ade7-21b264d4c94d | 2015-05-08 08:48:20-0500 | Books |   Novels | 678-2-44398-312-9 |  1 | 798 
    1002 | 15d0fd20-f589-11e4-ade7-21b264d4c94d | 2015-05-08 08:49:45-0500 | Audio |  Headphones | 228-5-44343-344-5 |  1 | 4799 
    1001 | 32671010-f588-11e4-ade7-21b264d4c94d | 2015-05-08 08:43:23-0500 | Books | Computer Books | 978-1-78398-912-6 |  1 | 2200 
    1001 | 74ad4f70-f588-11e4-ade7-21b264d4c94d | 2015-05-08 08:45:14-0500 | Books |   Novels | 678-2-44398-312-9 |  1 | 798 
    1001 | a3e1f750-f588-11e4-ade7-21b264d4c94d | 2015-05-08 08:46:34-0500 | Books | Computer Books | 977-8-78998-466-4 |  1 | 599 

(5 rows) 
aploetz@cqlsh:stackoverflow2> SELECT userid, time, dateof(time), category, subcategory, itemid, count, price FROM log_date2; 

userid | time         | dateof(time)    | category | subcategory | itemid   | count | price 
--------+--------------------------------------+--------------------------+----------+----------------+-------------------+-------+------- 
    1002 | e2f67ec0-f588-11e4-ade7-21b264d4c94d | 2015-05-08 08:48:20-0500 | Books |   Novels | 678-2-44398-312-9 |  1 | 798 
    1002 | 15d0fd20-f589-11e4-ade7-21b264d4c94d | 2015-05-08 08:49:45-0500 | Audio |  Headphones | 228-5-44343-344-5 |  1 | 4799 
    1001 | 32671010-f588-11e4-ade7-21b264d4c94d | 2015-05-08 08:43:23-0500 | Books | Computer Books | 978-1-78398-912-6 |  1 | 2200 
    1001 | 74ad4f70-f588-11e4-ade7-21b264d4c94d | 2015-05-08 08:45:14-0500 | Books |   Novels | 678-2-44398-312-9 |  1 | 798 
    1001 | a3e1f750-f588-11e4-ade7-21b264d4c94d | 2015-05-08 08:46:34-0500 | Books | Computer Books | 977-8-78998-466-4 |  1 | 599 

(5 rows) 

Trông khá giống nhau qua cqlsh. Vì vậy, chúng ta hãy có một cái nhìn từ cassandra-cli, và truy vấn tất cả các hàng Foor userid 1002:

RowKey: 1002 
=> (name=e2f67ec0-f588-11e4-ade7-21b264d4c94d:, value=, timestamp=1431092900008568) 
=> (name=e2f67ec0-f588-11e4-ade7-21b264d4c94d:category, value=426f6f6b73, timestamp=1431092900008568) 
=> (name=e2f67ec0-f588-11e4-ade7-21b264d4c94d:count, value=00000001, timestamp=1431092900008568) 
=> (name=e2f67ec0-f588-11e4-ade7-21b264d4c94d:itemid, value=3637382d322d34343339382d3331322d39, timestamp=1431092900008568) 
=> (name=e2f67ec0-f588-11e4-ade7-21b264d4c94d:price, value=0000031e, timestamp=1431092900008568) 
=> (name=e2f67ec0-f588-11e4-ade7-21b264d4c94d:subcategory, value=4e6f76656c73, timestamp=1431092900008568) 
=> (name=15d0fd20-f589-11e4-ade7-21b264d4c94d:, value=, timestamp=1431092985326774) 
=> (name=15d0fd20-f589-11e4-ade7-21b264d4c94d:category, value=417564696f, timestamp=1431092985326774) 
=> (name=15d0fd20-f589-11e4-ade7-21b264d4c94d:count, value=00000001, timestamp=1431092985326774) 
=> (name=15d0fd20-f589-11e4-ade7-21b264d4c94d:itemid, value=3232382d352d34343334332d3334342d35, timestamp=1431092985326774) 
=> (name=15d0fd20-f589-11e4-ade7-21b264d4c94d:price, value=000012bf, timestamp=1431092985326774) 
=> (name=15d0fd20-f589-11e4-ade7-21b264d4c94d:subcategory, value=4865616470686f6e6573, timestamp=1431092985326774) 

đơn giản đủ, đúng không? Chúng tôi thấy userid 1002 làm RowKey và cột phân cụm của chúng tôi là time làm khóa cột. Sau đó, tất cả các cột của chúng tôi cho mỗi khóa cột (time). Và tôi tin rằng ví dụ đầu tiên của bạn tạo ra 6 cột, vì tôi khá chắc chắn bao gồm trình giữ chỗ cho khóa cột, bởi vì PRIMARY KEY của bạn có thể trỏ đến một giá trị rỗng (như khóa ví dụ thứ 2 của bạn).

Nhưng còn phiên bản thứ 2 dành cho userid 1002 thì sao?

RowKey: 1002 
=> (name=e2f67ec0-f588-11e4-ade7-21b264d4c94d:Books:Novels:678-2-44398-312-9:1:798:, value=, timestamp=1431093011349994) 
=> (name=15d0fd20-f589-11e4-ade7-21b264d4c94d:Audio:Headphones:228-5-44343-344-5:1:4799:, value=, timestamp=1431093011360402) 

Hai cột được trả lại cho RowKey 1002, một cột cho mỗi kết hợp duy nhất của các cột cột (phân cụm), với giá trị trống (như đã đề cập ở trên).

Vậy điều này có ý nghĩa gì đối với bạn? Vâng, một vài điều:

• Điều này sẽ cho bạn biết rằng các khóa CHÍNH trong Cassandra đảm bảo tính duy nhất.Vì vậy, nếu bạn quyết định rằng bạn cần cập nhật các giá trị chính như category hoặc subcategory (ví dụ thứ 2) mà bạn thực sự không thể trừ khi bạn XÓA và tạo lại hàng. Mặc dù từ góc độ ghi nhật ký, điều đó có thể là ok.
• Cassandra lưu trữ tất cả dữ liệu cho một khóa phân đoạn/hàng cụ thể (userid) cùng nhau, được sắp xếp theo các phím cột (phân cụm). Nếu bạn lo ngại về việc truy vấn và sắp xếp dữ liệu của mình, điều quan trọng là phải hiểu rằng bạn sẽ phải truy vấn từng số userid cụ thể để sắp xếp để tạo ra bất kỳ sự khác biệt nào.
• Vấn đề lớn nhất tôi thấy, là ngay bây giờ bạn đang đặt mình lên cho sự phát triển cột không bị ràng buộc. Phím phân vùng/hàng có thể hỗ trợ tối đa 2 tỷ cột, vì vậy ví dụ thứ 2 của bạn sẽ giúp bạn nhiều nhất ở đó. Nếu bạn nghĩ rằng một số userid của bạn có thể vượt quá điều đó, bạn có thể triển khai "nhóm ngày" làm khóa phân bổ bổ sung (ví dụ: nếu bạn biết rằng userid sẽ không bao giờ vượt quá 2 tỷ trong một năm hoặc bất kỳ điều gì).

Dường như với tôi, tùy chọn thứ 2 của bạn có thể là lựa chọn tốt hơn. Nhưng thành thật cho những gì bạn đang làm, một trong số họ có thể sẽ hoạt động tốt.