Antirez cho biết, hãy xem trong https://news.ycombinator.com/item?id=1171423
Có một số lý do:
- Chúng không tốn nhiều bộ nhớ. Về cơ bản là tùy thuộc vào bạn. Việc thay đổi các tham số về xác suất của một nút có một số cấp nhất định sẽ làm cho bộ nhớ ít thâm dụng hơn btrees.
- Một tập hợp được sắp xếp thường là mục tiêu của nhiều hoạt động ZRANGE hoặc ZREVRANGE, nghĩa là duyệt qua danh sách bỏ qua dưới dạng danh sách được liên kết. Với thao tác này, vị trí bộ nhớ cache của danh sách bỏ qua ít nhất cũng tốt như với các loại cây cân bằng khác.
- Chúng đơn giản hơn để triển khai, gỡ lỗi, v.v. Ví dụ, nhờ sự đơn giản của danh sách bỏ qua, tôi đã nhận được một bản vá (đã có trong Redis master) với danh sách bỏ qua tăng cường triển khai ZRANK trong O (log (N)). Nó yêu cầu một số thay đổi nhỏ đối với mã.
Về độ bền và tốc độ của Append Only, tôi không nghĩ là nên tối ưu hóa Redis với chi phí nhiều mã hơn và phức tạp hơn cho một trường hợp sử dụng mà IMHO nên hiếm đối với mục tiêu Redis (fsync () ở mọi lệnh) . Hầu như không ai sử dụng tính năng này ngay cả với cơ sở dữ liệu ACID SQL, vì dù sao thì gợi ý về hiệu suất cũng rất lớn.
Về chủ đề:kinh nghiệm của chúng tôi cho thấy Redis chủ yếu là I / O ràng buộc. Tôi đang sử dụng các chuỗi để phục vụ mọi thứ từ Bộ nhớ ảo. Giải pháp lâu dài để khai thác tất cả các lõi, giả sử liên kết của bạn nhanh đến mức bạn có thể bão hòa một lõi duy nhất, là chạy nhiều phiên bản Redis (không có khóa, gần như hoàn toàn có thể mở rộng tuyến tính với số lõi) và sử dụng "Redis Cluster "giải pháp mà tôi dự định phát triển trong tương lai.
