Redis
 sql >> Cơ Sở Dữ Liệu >  >> NoSQL >> Redis

Có phải lệnh UNLINK luôn tốt hơn lệnh DEL không?

Trước khi thảo luận cái nào tốt hơn, chúng ta hãy xem xét sự khác biệt giữa các lệnh này. Cả DELUNLINK giải phóng phần quan trọng trong chế độ chặn. Và sự khác biệt là cách họ giải phóng phần giá trị.

DEL luôn giải phóng phần giá trị trong chế độ chặn. Tuy nhiên, nếu giá trị quá lớn, ví dụ:quá nhiều phân bổ cho một LIST lớn hoặc HASH , nó chặn Redis trong một thời gian dài. Để giải quyết vấn đề, Redis triển khai UNLINK lệnh, tức là xóa 'không chặn'.

Trên thực tế, UNLINK KHÔNG phải lúc nào cũng là không chặn / không đồng bộ . Nếu giá trị nhỏ, ví dụ:kích thước của LIST hoặc HASH nhỏ hơn 64 , giá trị sẽ được giải phóng ngay lập tức. Bằng cách này, UNLINK gần giống với DEL , ngoại trừ việc nó tốn thêm một vài lệnh gọi hàm so với DEL . Tuy nhiên, nếu giá trị lớn, Redis sẽ đặt giá trị vào một danh sách và giá trị sẽ được giải phóng bởi một luồng khác, tức là miễn phí không chặn. Theo cách này, luồng chính phải thực hiện một số đồng bộ hóa với luồng nền và đó cũng là một khoản chi phí.

Tóm lại, nếu giá trị nhỏ, DEL ít nhất cũng tốt như UNLINK . Nếu giá trị rất lớn, ví dụ:LIST với hàng nghìn hoặc hàng triệu mục, UNLINK tốt hơn nhiều so với DEL . Bạn luôn có thể thay thế DEL một cách an toàn với UNLINK . Tuy nhiên, nếu bạn thấy đồng bộ hóa luồng trở thành vấn đề (đa luồng luôn là vấn đề đau đầu), bạn có thể quay lại DEL .

CẬP NHẬT:

Kể từ Redis 6.0, có một cấu hình mới: lazyfree-lazy-user-del . Bạn có thể đặt nó thành và Redis sẽ chạy DEL lệnh như thể đang chạy một UNLINK lệnh.



  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Phương pháp nhanh hơn để di chuyển dữ liệu redis sang MySQL

  2. Làm cách nào để lưu và thoát redis.conf?

  3. Redis làm gì khi hết bộ nhớ?

  4. Bộ lưu trữ Kubernetes NFS sử dụng PV và PVC

  5. Đăng ký Flask-SocketIO