Cần trợ giúp về khái niệm hóa trong Redis/NoSQL

Question

Tôi nghĩ rằng tôi có một nắm bắt tốt về tất cả các lệnh để sử dụng Redis, nhưng tôi đang gặp khó khăn trong việc tìm ra cách tốt nhất để sử dụng nó. Tôi đang thiết kế một hệ thống thông báo khách hàng sẽ thông báo cho họ thông qua phương thức ưa thích của họ (Email, SNMP, Syslog) khi có báo động trên bất kỳ mạch nào của họ.

Vì vậy, tôi nhận được tên thiết bị và cổng. Tôi cần liên kết với một khách hàng, và sau đó kết hợp khách hàng đó với một phương thức phân phối. Với một db quan hệ, nó sẽ trông giống như thế này:

Device name: Los_Angeles 
Port: 11 

SELECT Customer_ID, Customer_name from device_info where device_port = 'Los_Angeles:11' 
SELECT Customer_protocol, SNMP_destination, Syslog_destination from CUSTOMER 
    where Customer_ID = <customer_id from above> 

(Ví dụ đơn giản hơn rất nhiều).

Tôi có thể xem cách thực hiện chương trình này với một danh sách băm hoặc băm băm. Nhưng tôi đoán những gì tôi đang gặp rắc rối với Redis là những cấu trúc dữ liệu phức tạp hơn không có sẵn cho tôi (theo như tôi biết). Vì vậy, làm thế nào để tôi liên kết nhiều mẩu thông tin với một khóa duy nhất? Tôi có thể nghĩ ra một vài cách tôi có thể làm, nhưng tất cả dường như liên quan đến nhiều bước, và tôi muốn một số đầu vào từ các lập trình viên Redis hiện tại về cách tốt nhất để làm điều này.

Answer 1

Bạn đúng rằng chỉ có cấu trúc dữ liệu đơn giản có sẵn với Redis và chúng không thể được tạo thành theo giá trị (như bạn có thể làm với cơ sở dữ liệu hướng tài liệu như CouchDB hoặc MongoDB). Tuy nhiên, có thể tạo cấu trúc dữ liệu bằng cách tham chiếu, và đây là một mô hình rất phổ biến.

Ví dụ, các mục có trong tập hợp có thể là các khóa cho các đối tượng khác (danh sách, bảng băm, các bộ khác, v.v ...). Hãy thử áp dụng điều này cho ví dụ của bạn.

Để mô hình hóa mối quan hệ giữa khách hàng và thiết bị + cổng, bạn có thể sử dụng các bộ chứa ID khách hàng. Để lưu trữ thông tin về khách hàng, một bảng băm cho mỗi khách hàng là tốt.

Sau đây là các khách hàng:

hmset c:1 name Smith protocol tcp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2 
hmset c:2 name Jackson protocol udp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2 
hmset c:3 name Davis protocol tcp snmp_dest 127.0.0.3 syslog_dest 127.0.0.4 

Các phím của những hồ sơ này là c: ID

Hãy sư hai người bọn họ đến một thiết bị và cổng:

sadd d:Los_Angeles:11 2 3 

Mấu chốt của bộ này là d: device: port. Tiền tố c: và d: chỉ là một quy ước. Một bộ cho mỗi thiết bị/cổng sẽ được tạo. Một khách hàng nhất định có thể thuộc về một số bộ (và do đó liên quan đến một số thiết bị/cổng).

Bây giờ để tìm khách hàng có phương thức phân phối được gắn với thiết bị/cổng này, chúng tôi chỉ cần truy xuất nội dung của bộ này.

smembers d:Los_Angeles:11 
1) "2" 
2) "3" 

sau đó thông tin khách hàng tương ứng có thể được lấy ra bởi pipelining một số lệnh hgetall:

hgetall c:2 
hgetall c:3 
1) "name" 
2) "Jackson" 
3) "protocol" 
4) "udp" 
5) "snmp_dest" 
6) "127.0.0.1" 
7) "syslog_dest" 
8) "127.0.0.2" 
1) "name" 
2) "Davis" 
3) "protocol" 
4) "tcp" 
5) "snmp_dest" 
6) "127.0.0.3" 
7) "syslog_dest" 
8) "127.0.0.4" 

Đừng ngại của số lệnh. Chúng rất nhanh và hầu hết các khách hàng Redis đều có khả năng phân phối các truy vấn để chỉ cần một số lượng tối thiểu các chuyến khứ hồi. Chỉ bằng cách sử dụng một smembers và một số hgetall, vấn đề có thể được giải quyết chỉ với hai vòng.

Bây giờ, có thể tối ưu hóa thêm một chút, nhờ vào lệnh SORT phổ biến. Đây có lẽ là lệnh phức tạp nhất trong Redis, và nó có thể được sử dụng để lưu một roundtrip tại đây.

sort d:Los_Angeles:11 by nosort get c:*->name get c:*->protocol get c:*->snmp_dest get c:*->syslog_dest 
1) "Jackson" 
2) "udp" 
3) "127.0.0.1" 
4) "127.0.0.2" 
5) "Davis" 
6) "tcp" 
7) "127.0.0.3" 
8) "127.0.0.4" 

Trong một lệnh, nó truy xuất nội dung của thiết bị/cổng và tìm thông tin khách hàng tương ứng.

Ví dụ này là tầm thường, nhưng nói chung, trong khi bạn có thể biểu diễn cấu trúc dữ liệu phức tạp với Redis, nó không phải là ngay lập tức. Bạn cần phải suy nghĩ cẩn thận về mô hình cả về cấu trúc lẫn quyền truy cập dữ liệu (tức là tại thời điểm thiết kế, dính vào dữ liệu của bạn VÀ trường hợp sử dụng của bạn).