Bài 1

Redis chọn cấu trúc trong bộ nhớ thế nào

HSET không nói cho bạn biết Redis vừa lưu hash đó bằng cái gì. Với hash nhỏ, nó là một dãy byte liền mạch; qua một ngưỡng nào đó, nó thành bảng băm với con trỏ cho từng trường. Cùng một lệnh, cùng một kiểu dữ liệu, hai cách lưu chênh nhau vài lần bộ nhớ. OBJECT ENCODING là lệnh cho biết Redis đang dùng cách nào.

Một khoá, hai tầng

Mỗi khoá trong Redis có một kiểu mà người dùng thấy (TYPE trả về hash, set, zset, list, string) và một encoding là cách lưu thật trong bộ nhớ (OBJECT ENCODING). Kiểu do bạn chọn; encoding do Redis chọn, dựa trên số phần tử và độ dài giá trị so với các ngưỡng cấu hình.

112 tổ hợp, đo trên Redis thật

Bộ đo dựng từng khoá bằng một lệnh EVAL rồi gọi OBJECT ENCODING, với bốn kiểu tập hợp × bảy số phần tử (1, 127, 128, 129, 511, 512, 513) × bốn kiểu giá trị (chuỗi 3 byte, chuỗi 64 byte, chuỗi 65 byte, số nguyên). Ngưỡng dùng đúng mặc định của Redis 7.4, chỉ list-max-listpack-size đặt về 128 để có một con số dương so sánh được.

docker exec rdlab redis-cli EVAL "
  for i=1,tonumber(ARGV[1]) do
    redis.call('HSET', KEYS[1], 'f'..i, ARGV[2])
  end
  return redis.call('HLEN', KEYS[1])" 1 h513 513 v
docker exec rdlab redis-cli OBJECT ENCODING h513
# hashtable

Bảng dưới đây là những hàng nói được nhiều nhất trong 112 hàng:

Giá của một trường thứ 513

Hai khoá chỉ khác nhau một trường:

Một trường thêm vào làm khoá đó chiếm gấp 4,65 lần bộ nhớ, và chi phí mỗi trường tăng từ 12,1 lên 56,2 byte. Lý do là listpack lưu các trường liền nhau trong một khối byte, không con trỏ, không bucket; hashtable phải có bảng bucket cộng một dictEntry cho mỗi trường.

Hệ quả thực tế: nếu ứng dụng của bạn có hàng triệu hash nhỏ, giữ chúng dưới ngưỡng là khoản tiết kiệm lớn nhất bạn có thể lấy mà không đổi một dòng mã. Chiều ngược lại cũng đúng — nới hash-max-listpack-entries lên quá cao thì mọi phép đọc một trường phải quét tuần tự cả listpack.

Một chi tiết nhỏ đáng ghi: h511 và h512 cùng chiếm 6 192 byte. Đó không phải lỗi lấy mẫu của MEMORY USAGE — chạy lại với SAMPLES 0 (đếm hết, không lấy mẫu) vẫn cho đúng 6 192. Listpack cấp phát theo bước, nên có lúc thêm một trường không tốn thêm byte nào.

List: giới hạn tính bằng byte, không phải số phần tử

list-max-listpack-size mặc định là -2, và số âm nghĩa là giới hạn tính theo kích thước chứ không theo số phần tử. Nhưng ngay cả khi đặt nó thành một số dương lớn, vẫn còn một giới hạn cứng: một node listpack không vượt 8 192 byte.

Tìm biên bằng tìm kiếm nhị phân với list-max-listpack-size 100000:

Cả ba biên đều dừng ở MEMORY USAGE bằng 8 240 byte, tức 8 192 byte listpack cộng khoảng 48 byte phần đầu đối tượng. Phòng thí nghiệm bên dưới tính lại kích thước listpack theo công thức 6 byte header + 1 byte kết thúc + mỗi phần tử (nội dung + byte ghi độ dài + byte backlen), và công thức đó tái hiện đúng cả ba biên.

Chuyển encoding là một chiều

Redis chuyển từ encoding gọn sang encoding đầy đủ khi vượt ngưỡng, nhưng không bao giờ chuyển ngược. Đo được:

hash 513 trường                        → hashtable
CONFIG SET hash-max-listpack-entries 1024  → vẫn hashtable
HSET thêm một trường nữa               → vẫn hashtable
HDEL bớt còn 512 trường                → vẫn hashtable
tạo khoá MỚI với 513 trường (ngưỡng 1024) → listpack

Tương tự với set: 129 chuỗi thành hashtable, xoá bớt còn 128 vẫn là hashtable.

Phòng thí nghiệm

Đặt kiểu, số phần tử, độ dài giá trị và từng ngưỡng. Thuật toán chạy trên trình duyệt là bản viết lại quy tắc ở trên, đã đối chiếu với 112 hàng ma trận, ba biên byte của list và bốn trường hợp string trên Redis 7.4.11 — khớp toàn bộ.

Tự kiểm tra