Tất cả phụ thuộc vào cách bạn sẽ sử dụng nó. Nếu mỗi byte đều được tính, chẳng hạn như khi bạn phải trả cho mỗi kB được chuyển sang dịch vụ đám mây, bạn có thể tính toán chi phí. Các phép toán rất đơn giản; một byte là một byte 'trên dây'. Bên trong redis, đối với các giá trị lớn hơn, nó cũng đơn giản như nhau. Đối với các giá trị nhỏ hơn, Redis thực hiện một số tối ưu hóa bộ nhớ.
Trong HSET của bạn ví dụ, bạn tách các thành viên ra, điều này chỉ có ý nghĩa nếu bạn cần tách họ ra khỏi nhau trong hầu hết thời gian. Cách tiếp cận tốt hơn -might- be:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Các khóa / thành viên riêng biệt 'tốn kém' hơn rất nhiều so với các chuỗi dài hơn, hiệu suất khôn ngoan. Bạn thậm chí có thể đặt toàn bộ bảng hoặc tập dữ liệu vào một thành viên nếu nó chỉ được sử dụng như một thực thể bán tĩnh hoàn chỉnh.
Tốc độ và Kích thước:Có một sự khác biệt đáng chú ý giữa các phím và giá trị .
Các phím: Ngắn hơn thường hiệu quả hơn về bộ nhớ cũng như tốc độ hiệu quả. Nếu bạn sử dụng Redis Sorted Set, bạn thậm chí có thể sử dụng 'số' làm khóa (nhóm được sắp xếp 'thành viên' cộng với 'điểm số'). Tôi nói 'số' vì điểm về mặt kỹ thuật là float64, nhưng để được sử dụng làm ID, nó phải nằm trong khoảng -999999999999999 đến 999999999999999 bao gồm (đó là 15 chữ số), không có bất kỳ phần phân số nào. Điều này có thể thực sự hữu ích, vì Redis thực hiện sắp xếp nhanh chóng và có thể mở rộng O (log (n)) của các Bộ được sắp xếp (sử dụng danh sách bỏ qua, được đơn giản hóa).
Giá trị: Định dạng MsgPack (không nén) chiếm ít dung lượng nhất, đặc biệt nếu bạn lưu trữ các định nghĩa một lần và nhiều giá trị. JSON tiết kiệm bộ nhớ hơn một chút, nhưng tất nhiên là một định dạng IPC phổ biến đến mức không nên bỏ qua. Chuỗi thô, ký tự được phân tách, độ dài cố định (ugh), bất cứ điều gì bạn muốn, đều có thể sử dụng. Bạn luôn có thể nén dữ liệu của mình trước khi lưu trữ trong Redis. Cho đến nay hiệu quả bộ nhớ . Khi nói đến tốc độ , nó ít đơn giản hơn. Nếu bạn muốn sử dụng tập lệnh phía máy chủ Lua (điều bạn nên làm), bạn không thể làm gì với dữ liệu nén. JSON và MsgPack có thể được deserialized, nhưng chỉ 'tổng thể'. Đó là tốt trong hầu hết các tình huống. Linh hoạt nhất là lưu trữ các giá trị riêng biệt (ví dụ như các thành viên của HSET), nhưng điều này cũng đi kèm với một mức giá (hầu hết thời gian:giá quá cao). Bạn cũng có thể kết hợp tất cả những thứ này. Những gì chúng tôi sử dụng nhiều nhất:tiền tố của hai hoặc ba giá trị được phân tách bằng dấu phân cách, theo sau là tải trọng MsgPack.
Lời khuyên chung của tôi là:hãy bắt đầu với việc chỉ sử dụng HSET và ZSET, không chia nhỏ dữ liệu thuộc về nhau, hãy sử dụng các tên PascalCased mô tả cho các khóa của bạn từ 10-25 ký tự, sử dụng ':' nếu bạn cần dấu phân cách trong các khóa (không gian tên) , tuần tự hóa dưới dạng JSON (để đơn giản, nhưng mã để dễ dàng chuyển sang MsgPack), sử dụng tập lệnh Lua (ngay cả khi bạn không biết Lua, tập con bạn sử dụng trong Redis rất nhỏ).
Tôi sẽ không lo lắng về nó quá nhiều trong giai đoạn khởi động dự án của bạn, bạn luôn có thể thay đổi nó sau này và thực hiện một số so sánh A / B ngay khi bạn có một số dữ liệu có thể nội suy.
Hy vọng điều này sẽ hữu ích, TW
