Cho dù bạn là người mới sử dụng Redis hay bạn chỉ cần cập nhật các tính năng có sẵn, hướng dẫn này có thể giúp bạn hiểu tất cả các cấu trúc dữ liệu màRedis cung cấp.
Chọn cấu trúc phù hợp
Cấu trúc dữ liệu của Redis rất đơn giản - không cấu trúc nào trong số chúng có khả năng phù hợp hoàn hảo cho vấn đề bạn đang cố gắng giải quyết. Nhưng nếu bạn chọn cấu trúc ban đầu phù hợp cho dữ liệu của mình, các lệnh Redis có thể hướng dẫn bạn những cách hiệu quả để đạt được những gì bạn cần. Nhiều lệnh Redis có một tiền tố cho biết kiểu cấu trúc dữ liệu cơ bản mà chúng được sử dụng để làm việc.
Cấu trúc dữ liệu cho mục đích chung
| Tiền tố | Công dụng | Những lưu ý và những điều sai lầm phổ biến | |
|---|---|---|---|
| Hash | H | Lưu trữ đối tượng; bất cứ thứ gì bạn muốn sử dụng đối tượng từ điển cho | Cũng giống như bản thân Redis, một trong những vấn đề lớn nhất mà người dùng gặp phải với Hashes là kế toán khóa. Hãy chắc chắn rằng bạn có một hệ thống để đảm bảo rằng bạn không điền vào các hàm băm của mình bằng các khóa và giá trị mà bạn không cần. |
| Danh sách | L | Hàng đợi, ngăn xếp và danh sách theo chu kỳ | Đừng cố truy cập ngẫu nhiên vào các danh sách lớn và hãy cẩn thận khi sao lưu hàng đợi. |
| Đặt | S | Hệ thống gắn thẻ, nhóm cho dữ liệu chuỗi thời gian | Phải cẩn thận khi sử dụng các giao lộ và công trình - giữ cho bộ đồ chơi của bạn nhỏ gọn. Bộ không phải là cách tốt nhất để đếm số lượng duy nhất. Sử dụng HyperLogLog thay thế! |
| Tập hợp được sắp xếp | Z | Bảng điểm, tìm kiếm từ vựng, danh sách truy cập ngẫu nhiên | Zsets là một trong những cấu trúc linh hoạt nhất và cũng là một trong những cấu trúc đắt tiền nhất. Hãy theo dõi sát sao chữ O lớn của bạn! Nếu bạn đang sử dụng các bộ được sắp xếp để tự động hoàn thành, bạn có thể điều tra ZRANGEBYLEX, xử lý tìm kiếm từ vựng (nhưng hãy cẩn thận với UTF-8!) |
| Luồng | X | Chuỗi thời gian, hàng đợi, phân phối thông báo | Việc không giới hạn luồng là điều phổ biến, đôi khi chúng cũng bị nhầm lẫn với khả năng của các hệ thống nhắn tin phân tán (cụ thể là Apache Kafka). |
| Chuỗi | (không có) | Bộ nhớ đệm, bộ đếm, thao tác bit đơn giản | Hãy cẩn thận với các giá trị cực kỳ lớn, việc NHẬN hoặc CÀI ĐẶT chúng có thể gây ra lỗi khó tìm trong một số mạng nhất định và máy khách Redis. Bạn có thể dễ dàng tự làm tổn thương mình khi sử dụng SETNX để xây dựng hệ thống khóa. |
Cấu trúc dữ liệu chuyên biệt
Redis cung cấp một số thao tác để xử lý các trường hợp đặc biệt của các kiểu cụ thể, trong khi kiểu "ẩn" là một trong các kiểu dữ liệu mục đích chung ở trên:
| Tiền tố | Loại cơ bản | Công dụng | Những lưu ý và những điều sai lầm phổ biến | |
|---|---|---|---|---|
| Bản đồ bit | BIT | Chuỗi | Cờ tiết kiệm không gian cho phân tích | Nhầm lẫn về các khả năng hoặc mất dấu sự phức tạp của kế toán trong hệ thống dựa trên bitmap. |
| Bộ đếm | INCR, DECR | Chuỗi | Phân tích hiệu quả về không gian | Tràn phạm vi có dấu 64-bit sẽ trả về lỗi |
| Thùng rác địa lý | GEO | Tập hợp được sắp xếp | Công cụ định vị cửa hàng, tìm người dùng lân cận | Cần tính toán khoảng cách xa, bất cứ nơi nào cần có các phép chiếu chuyên biệt hoặc các chức năng địa lý phức tạp. |
| HyperLogLog | PF | Chuỗi | Đếm số duy nhất cho phân tích | Việc hợp nhất nhiều HLL với nhau có thể tốn kém. Đảm bảo có giới hạn về số lượng thông số bạn chỉ định trong PFMERGE. |
| Pub / Sub | PUB, SUB, PSUB | (không có) | Tin nhắn tạm thời trôi qua | Truyền tin đơn giản, nhanh chóng mà không có độ bền. Loại Luồng là lựa chọn tốt hơn cho hầu hết các trường hợp sử dụng. |
Sử dụng Big O của bạn
Sử dụng sai các mẫu truy cập của cấu trúc dữ liệu cũng giống như sử dụng sai từ điển:đừng lật từng trang để tra từ! Độ phức tạp về thời gian của mọi lệnh Redis được ghi lại trên redis.io.
Big O là một cách thể hiện “hành vi hạn chế” về cách một thứ gì đó sẽ hoạt động. Một cách nghĩ đơn giản về nó là hoạt động sẽ thực hiện như thế nào khi lượng dữ liệu trong hệ thống tăng lên. Nếu một phép toán là O (1), thì sẽ mất một khoảng thời gian cố định để hoàn thành, bất kể có bao nhiêu dữ liệu. Anoperation là O (n) sẽ chia tỷ lệ tuyến tính với dữ liệu và Anoperation là O (n²) trở nên chậm hơn theo cấp số nhân khi lượng dữ liệu tăng lên.
Để có cách xử lý triệt để hơn, hãy xem phần giới thiệu dễ hiểu về chữ O lớn này với mã mẫu và đồ thị.
Thiết kế hệ thống tốt cần nhiều hơn phân tích thuật toán cơ bản, nhưng thỉnh thoảng bạn nên tìm hiểu những điều cơ bản và suy nghĩ về tổng độ phức tạp của quyền truy cập dữ liệu trong ứng dụng của bạn.
Giữ Hoạt động Nhỏ
Redis là một luồng, điều này giúp bạn dễ dàng suy luận nhưng cũng có thể gây ra một số ngạc nhiên cho những người chỉ quen với việc truy cập dữ liệu đa luồng. thời gian, các hoạt động kéo dài có thể gây ra các bản sao lưu trên toàn hệ thống.
Giữ cho các hoạt động truy cập dữ liệu thật chi tiết là chìa khóa để có hiệu suất tốt với Redis. Hoạt động 100.000 O (1) trong Redis có thể thích hợp hơn hoạt động 1 O (N) trên tập hợp 100.000 phần tử, mặc dù bạn sẽ phải trả nhiều tiền do phân tích mạng và giao thức.
Làm thế nào bạn có thể tìm ra những điểm khó khăn trong hệ thống của bạn? Kiểm tra SLOWLOG thường xuyên (nếu bạn là khách hàng của RedisGreen, chỉ cần xem tab “Truy vấn chậm” trên bảng điều khiển của bạn). Một thao tác chạy càng lâu, nó càng làm chậm mọi thứ khác mà hệ thống của bạn đang cố gắng thực hiện, vì vậy hãy giữ cho nó ngắn gọn!