20

SCAN là một công cụ mạnh mẽ để truy vấn dữ liệu, nhưng tính chất ngăn chặn của nó có thể phá hủy hiệu suất khi được sử dụng nhiều. KeyDB đã thay đổi bản chất của lệnh này trong phiên bản Pro, cho phép các lệnh cải thiện hiệu suất đáng kể!

Bài viết này xem xét những hạn chế của việc sử dụng lệnh SCAN và những ảnh hưởng của nó đối với hiệu suất. Nó thể hiện sự phân cấp hiệu suất chính xảy ra với Redis và nó cũng xem xét cách KeyDB Pro giải quyết vấn đề này bằng cách triển khai kiến ​​trúc MVCC cho phép SCAN không bị chặn, tránh mọi tác động tiêu cực đến hiệu suất.

KEYS vs SCAN

Chức năng SCAN được tạo ra để phá vỡ lệnh KEYS chặn có thể gây ra các vấn đề lớn khi được sử dụng trong sản xuất. Nhiều người dùng Redis biết quá rõ hậu quả của sự chậm lại này đối với khối lượng công việc sản xuất của họ.

Lệnh KEYS và lệnh SCAN có thể tìm kiếm tất cả các phím phù hợp với một mẫu nhất định. Sự khác biệt giữa hai phương pháp này là SCAN lặp qua keyspace hàng loạt bằng con trỏ để ngăn chặn hoàn toàn việc chặn cơ sở dữ liệu theo độ dài của truy vấn.

Cách sử dụng cơ bản như sau:

keydb-cli:6379> KEYS [pattern]
keydb-cli:6379> SCAN cursor [MATCH pattern] [COUNT count]


Ví dụ dưới đây tìm kiếm tất cả các khóa có chứa mẫu "22" trong đó. Con trỏ bắt đầu từ vị trí 0 và tìm kiếm qua 100 phím cùng một lúc. Kết quả trả về trước tiên sẽ trả về số con trỏ tiếp theo và tất cả các giá trị trong lô có chứa "22" trong tên khóa.

keydb-ci: 6379> SCAN 0 MATCH *22* COUNT 100
1)  2656
2)  1) 220
    2) 3022
    3) 4224
    4) 22


Để biết thêm thông tin về cách sử dụng SCAN, vui lòng xem tài liệu tại đây https://docs.keydb.dev/docs/commands/#scan

QUÉT COUNT

COUNT là số lượng khóa để tìm kiếm tại một thời điểm cho mỗi lần lặp con trỏ. Như vậy, số lượng càng nhỏ, thì càng cần nhiều lần lặp gia tăng cho một tập dữ liệu nhất định. Dưới đây là biểu đồ hiển thị thời gian thực hiện để đi qua tập dữ liệu gồm 5 triệu khóa bằng cách sử dụng các cài đặt COUNT khác nhau.

Ảnh hưởng của Redis SCAN đến hiệu suất và KeyDB đã cải thiện nó như thế nào

Như có thể lưu ý, đối với kích thước số lượng rất nhỏ, thời gian cần để lặp qua tất cả các phím tăng lên đáng kể. Nhóm thành số lượng lớn hơn dẫn đến độ trễ thấp hơn để hoàn thành QUÉT. Kích thước hàng loạt từ 1000 trở lên trả về kết quả nhanh hơn nhiều.

Với Redis, điều quan trọng là phải chọn kích thước đủ nhỏ để giảm thiểu hành vi chặn của lệnh trong quá trình sản xuất.

Giảm hiệu suất Redis với SCAN

Với Redis, lệnh KEYS đã được cảnh báo không được sử dụng trong sản xuất vì nó có thể chặn cơ sở dữ liệu trong khi truy vấn đang được thực hiện. SCAN được tạo ra để lặp qua keyspace theo lô để giảm thiểu các tác động.

Tuy nhiên, câu hỏi vẫn còn, SCAN sẽ tác động đến tải sản xuất như thế nào? Nếu kích thước COUNT của tôi đủ nhỏ, tôi có thể chạy nhiều truy vấn QUÉT cùng một lúc không?

Biểu đồ dưới đây cho thấy tác động của việc chạy SCAN trên một tập dữ liệu lớn với COUNT kích thước 100, 1000 và 10.000. Nó cho thấy những ảnh hưởng mà việc chạy các truy vấn có đối với hiệu suất của khối lượng công việc hiện có.

Ảnh hưởng của Redis SCAN đến hiệu suất và KeyDB đã cải thiện nó như thế nào

Đối với phần trên, memtier đã được sử dụng để tạo khối lượng công việc và một số lượng truy vấn SCAN cụ thể đã được chạy để xem các tác động lên khối lượng công việc.

Tốc độ hoạt động / giây cơ bản khi không chạy SCAN là ~ 128.000 ops / giây. Rõ ràng là khi nhiều truy vấn SCAN được thực hiện, thông lượng khối lượng công việc sẽ giảm đáng kể. Hiệu ứng chặn tích lũy của nhiều lần lặp lại trở nên nhanh chóng rõ ràng. Điều này có nghĩa là điều quan trọng là phải giảm số lượng truy vấn SCAN đang được thực hiện để ngăn chặn việc giảm mạnh hiệu suất.

KeyDB Pro MVCC Triển khai với SCAN

KeyDB đã triển khai Kiểm soát đồng thời nhiều phiên bản (MVCC) vào phiên bản KeyDB Pro. Điều này cho phép một ảnh chụp nhanh được truy vấn mà không chặn các yêu cầu khác. Do đó, các tác động của việc chạy KEYS hoặc SCAN trên KeyDB Pro có ít hoặc không ảnh hưởng đến khối lượng công việc hiện có đang được chạy.

KeyDB Pro cũng đa luồng cho phép hiệu suất cao hơn nhiều.

Như có thể thấy bên dưới, bất kể COUNT hoặc số lượng truy vấn SCAN đang được thực hiện, khối lượng công việc đang chạy về cơ bản không bị ảnh hưởng.

Ảnh hưởng của Redis SCAN đến hiệu suất và KeyDB đã cải thiện nó như thế nào

Hiệu suất không giảm và KeyDB Pro có thể đồng thời phục vụ các truy vấn SCAN. Đây có thể là một tin tuyệt vời cho những người phụ thuộc nhiều vào SCAN hoặc cần áp dụng nó vào trường hợp sử dụng của họ. Hành vi không chặn do việc sử dụng MVCC cũng như đa luồng của chúng tôi mang lại rất nhiều cơ hội mà chúng tôi dự định xây dựng thành KeyDB Pro.

Ví dụ Python

Dưới đây là một ví dụ về cách SCAN có thể được sử dụng để lặp qua toàn bộ tập dữ liệu. Chúng tôi sử dụng thư viện Python KeyDB (thư viện Redis cũng hoạt động) và xác định một hàm chấp nhận một mẫu để khớp và kích thước đếm. Con trỏ bắt đầu từ 0 và được cập nhật mỗi lần lặp lại và được chuyển trở lại cho đến khi nó đạt đến điểm bắt đầu một lần nữa (lặp qua toàn bộ tập dữ liệu).

#! /usr/bin/python3
import keydb
keydb_pycli=keydb.KeyDB(host='localhost', port=6379, db=0, charset="utf-8", decode_responses=True)
def keydb_scan(pattern,count):
        result = []
        cur, keys = keydb_pycli.scan(cursor=0, match=pattern, count=count)
        while cur != 0:
                cur, keys = keydb_pycli.scan(cursor=cur, match=pattern, count=count)
                result.extend(keys)
                print(keys)
        print(result)


Phần kết luận

Hy vọng rằng bài viết này đã cung cấp một số thông tin chi tiết về cách sử dụng SCAN nếu bạn đang sử dụng Redis hoặc KeyDB Community, cũng như giới thiệu về các khả năng của KeyDB Pro với MVCC.

Nếu những cải tiến này có thể giúp ích cho trường hợp sử dụng của bạn, vui lòng liên hệ với chúng tôi theo địa chỉ support@keydb.dev để tìm hiểu thêm! Chúng tôi luôn vui vẻ khi trò chuyện

Chúng tôi rất vui mừng về việc sử dụng MVCC trong KeyDB Pro vì nó đang mở ra rất nhiều cơ hội để cải thiện hiệu suất và cung cấp thông tin chi tiết tốt hơn về dữ liệu. MVCC trong năm tới sẽ cho phép chúng tôi sử dụng nhiều lõi máy hơn, thực hiện các hành động như khôi phục giao dịch và tạo ra những bước nhảy vọt về những gì có thể với KeyDB Pro.

Tìm hiểu thêm:

Tự kiểm tra

Đối với các thử nghiệm ở trên, chúng tôi đã sử dụng mã python mẫu để truy vấn thông qua dữ liệu. Tập dữ liệu là 50 triệu khóa nhằm cung cấp đủ thời gian để đo lường chính xác các tác động lên thông lượng. Truy vấn sẽ được yêu cầu song song lên đến 1000 lần cho các bài kiểm tra. Tập dữ liệu đầy đủ sẽ được lặp lại thông qua việc sử dụng các COUNT khác nhau.

Trong khi thực hiện các truy vấn một khối lượng công việc chuẩn được tạo ra sử dụng Memtier với các thiết lập mặc định của nó: $ memtier_benchmark -p 6379. Các con số được ghi lại đã được sử dụng để cung cấp dữ liệu ở trên. Tất cả các thử nghiệm được thực hiện trên cùng một máy (m5.8xlarge) chạy memtier và KeyDB Pro / Redis trên cùng một máy. Có thể đạt được thông lượng cao hơn từ KeyDB Pro nếu Memtier được chuyển sang máy của chính nó, tuy nhiên đối với mục đích của thử nghiệm này, thiết lập đã đủ để chứng minh khái niệm.

Nếu bạn muốn tạo ra một tải tương tự, bạn có thể yêu cầu memtier chạy lệnh SCAN cho bạn, tuy nhiên nó sẽ không lặp lại qua keyspace, chỉ tạo ra các yêu cầu cho một lần lặp. Tuy nhiên, các hiệu ứng nhìn thấy sẽ tương tự. Cơ sở dữ liệu của bạn không cần phải quá lớn để xem các hành vi bên dưới.

Lệnh trên tạo ra các hiệu ứng sau đối với khối lượng công việc tiêu chuẩn của memtier cho Redis:

Ảnh hưởng của Redis SCAN đến hiệu suất và KeyDB đã cải thiện nó như thế nào

Nếu sử dụng memtier cho việc này, bạn có thể giới hạn số lượng khách hàng "--clients = x" để giảm số lượng truy vấn SCAN được tạo.

|