Giới thiệu HotKV

HotKV là một kho dữ liệu đa luồng, tương thích Redis, viết từ đầu bằng C++ hiện đại, được xây dựng để khai thác tối đa tốc độ từ các máy chủ nhiều lõi hiện đại với chi phí thấp nhất có thể. Tôi là Norbert E. Boros, nhà sáng lập kiêm CEO của HotKV Ltd. Bài viết này giải thích vì sao tôi xây dựng nó, hiện nó làm được gì và nó đo được những gì.

Tóm lại. HotKV chạy lệnh trên nhiều luồng cùng lúc bên trong một tiến trình duy nhất và nói RESP2 và RESP3, giao thức Redis. Trong benchmark một instance vào tháng Mười năm 2026 của chúng tôi trên 160 vCPU, nó có thông lượng cao nhất ở 11 trong 12 lệnh chúng tôi đo, và Dragonfly ngang bằng với nó ở lệnh thứ mười hai. Thiết lập và các giới hạn của nó được mô tả bên dưới.

Vì sao tôi xây dựng HotKV

Tôi quan tâm đến tốc độ trong mọi thứ tôi xây dựng. Một website, một công cụ hay một máy chủ nên phản hồi ngay lập tức, và khi không như vậy, tôi muốn biết vì sao. Thói quen đó đã định hình công việc của tôi suốt từ khi tôi viết phần mềm.

C và C++ là ngôn ngữ chính của tôi trong nhiều năm. Gần mười năm tôi làm việc trên phần mềm chống gian lận trong game chạy trên hàng nghìn PC của người chơi. Nó phải quét bộ nhớ để tìm các công cụ gian lận trong khi dùng ít CPU và bộ nhớ nhất có thể, vì mỗi chu kỳ nó dùng đều bị lấy đi từ trò chơi. Công việc đó dạy tôi đo lường mọi thứ, thiết kế quanh phần cứng và coi việc dùng ít tài nguyên là một tính năng tự thân.

Song song với đó, tôi dùng Redis và Valkey trong nhiều dự án cần một cache nhanh: kho phiên, danh sách địa chỉ IP bị tường lửa chặn và một cache đặt trước hàng trăm triệu bản ghi SQL Server. Chúng là những công cụ xuất sắc. Chúng cũng khiến tôi tò mò về những gì một kho khóa-giá trị có thể làm nếu được thiết kế ngay từ đầu cho các máy chủ nhiều lõi mà chúng ta chạy ngày nay.

HotKV là câu trả lời mà tôi đã đi đến. Tôi viết nó từ đầu bằng C++ hiện đại để lấy được nhiều tốc độ nhất có thể từ phần cứng, với chi phí thấp nhất có thể. Benchmark bên dưới cho thấy nó đang đứng ở đâu hôm nay, và tôi kỳ vọng còn nhiều thứ để đạt thêm.

Chi phí của AI

Còn một lý do thứ hai. Chạy các ứng dụng AI đang trở nên đắt đỏ, với tôi và, xét theo những gì các lập trình viên chia sẻ trên mạng, với nhiều người khác nữa. Một phần lớn chi phí đó thường đến từ việc gửi cho mô hình những câu hỏi nó đã trả lời rồi. Một kho nhanh nhận ra một câu hỏi lặp lại hoặc tương tự và trả lời nó từ cache là một trong những cách trực tiếp nhất để cắt giảm hóa đơn đó, đó là lý do caching cho khối lượng công việc AI là một phần cốt lõi của HotKV.

HotKV dùng để làm gì

HotKV Ltd tồn tại để làm cho loại phần mềm này hiệu quả hơn và phải chăng hơn. Các máy chủ hiện đại có rất nhiều lõi, và một kho dữ liệu nên dùng chúng, để bạn có được tốc độ cao nhất có thể với chi phí thấp nhất có thể.

Ý tưởng thứ hai là giữ nhiều phần hơn của hệ thống ở cùng một nơi. Các nhóm xây dựng trên LLM thường kết thúc bằng việc chạy một cache, một cơ sở dữ liệu vector và một nơi để giữ bộ nhớ agent, với một đống mã keo dán giữa chúng. Tôi muốn caching và công việc AI xung quanh nó nằm trong một engine, ngay cạnh dữ liệu của bạn: caching chính xác và ngữ nghĩa cho các lệnh gọi mô hình, tìm kiếm vector, bộ nhớ agent và ngân sách token. Ít hệ thống phải vận hành hơn nghĩa là ít bộ phận chuyển động hơn và hóa đơn thấp hơn. Trang AI liệt kê những gì hiện có, và benchmark tiết kiệm token cho thấy việc cache các lệnh gọi mô hình đã tiết kiệm được gì trong bài kiểm tra của chúng tôi.

HotKV giữ giao thức Redis và các thư viện client quen thuộc.

Vấn đề

Một luồng thực thi lệnh duy nhất có thể trở thành nút thắt cổ chai trên một máy có nhiều lõi. Một kho dữ liệu xây quanh một luồng thực thi thường chạm tới phần còn lại của máy bằng cách chạy nhiều instance hoặc một cụm, và điều đó kéo theo các lựa chọn triển khai và công việc vận hành. Tôi muốn HotKV bắt đầu từ đầu kia, với các lệnh chạy đồng thời bên trong một instance, để một tiến trình duy nhất có thể dùng toàn bộ máy.

HotKV làm khác đi điều gì

HotKV™ được viết bằng C++20 và được thiết kế để chạy lệnh trên nhiều lõi cùng lúc, nên một instance duy nhất có thể tận dụng cả một máy. Dragonfly, mà chúng tôi so sánh bên dưới, cũng theo hướng đa luồng.

• Nhiều lõi, một instance. Các lệnh chạy đồng thời trên các lõi của máy, nên một instance có thể dùng một máy chủ lớn thay vì nhiều máy nhỏ hơn.
• Client và giao thức quen thuộc. HotKV hỗ trợ RESP2 và RESP3, nên các thư viện client quen thuộc có thể kết nối với nó. Giao dịch (MULTI/EXEC) và scripting Lua đều được hỗ trợ. Xem tài liệu lệnh để biết các lệnh được hỗ trợ và mọi khác biệt.

Nó được xây dựng và kiểm thử như thế nào

Tôi tự xây dựng HotKV và dùng sự hỗ trợ của AI ở nơi nó giúp ích. Điều quan trọng hơn cách một dòng mã được viết là nó có trụ vững hay không, nên engine được kiểm thử rất kỹ. Nó có hơn 2,000 bài kiểm thử tự động và được dựng dưới AddressSanitizer, ThreadSanitizer và UndefinedBehaviorSanitizer. Nó cũng có các mục tiêu fuzz cho bộ phân tích giao thức, điều phối lệnh, nạp RDB và AOF, luồng sao chép và bus cụm.

Thiết lập benchmark, các giới hạn của nó và kết quả đầy đủ nằm ở trang Hiệu năng, để bạn tự đánh giá các con số.

Ảnh chụp benchmark

Cập nhật tháng Mười năm 2026: các số liệu được công bố lần đầu trong bài viết này đến từ những lần chạy benchmark mà sau đó chúng tôi phát hiện có sai sót (trong đó, mọi máy tạo tải đều dùng cùng một hạt giống ngẫu nhiên), nên chúng tôi thay chúng bằng kết quả từ benchmark đã được xây dựng lại.

Tháng 10 năm 2026: HotKV, Redis, Valkey và Dragonfly

HotKV Ltd đã chạy benchmark này. Chúng tôi đo HotKV, được dựng từ mã nguồn, so với Redis 8.10.2, Valkey 9.1.2 và Dragonfly 2.0.2. Mỗi máy chủ chạy riêng, dưới dạng một instance trên toàn bộ 160 vCPU của một Azure D160alds_v7 (AMD EPYC 9V45), tắt lưu trữ bền vững. Ba máy 64 vCPU riêng biệt tạo tải bằng memtier_benchmark: giá trị 256 byte, độ sâu pipeline 30 và 5,000,000 khóa được nạp sẵn. Mỗi số liệu là trung vị của ba lần chạy 10 giây.

HotKV có thông lượng cao nhất ở 11 trong 12 lệnh. So với Redis hoặc Valkey, nó đo được từ 8.6 đến ít nhất 69.7 lần thông lượng của chúng, tùy lệnh và máy chủ; so với Dragonfly, từ 1.97 đến 4.41 lần trên 11 lệnh đó, một số trong đó là cận dưới. Ở PING, Dragonfly đo được cao hơn 0.6 phần trăm. Chúng tôi tính đó là hòa, vì các máy tạo tải đã gần giới hạn của chính chúng. Số liệu cao nhất ở một lệnh dữ liệu là 90.8 triệu thao tác INCR mỗi giây. INCR và PING di chuyển ít dữ liệu và bị giới hạn bởi các máy tạo tải, nên số liệu thực của HotKV cho chúng có thể cao hơn.

Cách đọc bảng

MGET đọc tám khóa và MSET ghi bốn cặp khóa-giá trị cho mỗi lệnh, và thông lượng đếm theo số lệnh. Báo cáo đánh dấu bảy số liệu của HotKV (GET và sáu lệnh ghi) vì chúng đã chạm ngưỡng sử dụng mạng 85% của nó, và PING vì các máy tạo tải ở trên 85% CPU. Các tỷ lệ dựa trên chúng là cận dưới, được đánh dấu bằng ≥. GET và PING là các giới hạn thực. Với sáu lệnh ghi, số liệu sử dụng mạng của báo cáo cộng lưu lượng chiều vào và chiều ra rồi so với mức trần chiều ra, nên nó phóng đại mức độ gần giới hạn của chúng. Lệnh nặng nhất, SETNX, dùng tối đa khoảng 80% mức trần chiều vào đã đo. Chúng tôi giữ ≥ trên chúng như một quy ước thận trọng. Các bảng đầy đủ, các cờ và ghi chú phương pháp nằm ở trang Hiệu năng.

Phạm vi của benchmark

• Bản dựng và tinh chỉnh. HotKV được biên dịch với -march=native cho CPU kiểm thử, trong khi các máy chủ khác là bản phát hành dựng sẵn nguyên bản của chúng.
• Thiết lập luồng. Mỗi máy chủ được cấp mọi lõi của máy: HotKV --threads 160, Dragonfly 160 luồng proactor, Valkey io-threads 160 và Redis io-threads 128, mức tối đa của nó. Redis và Valkey chạy lệnh trên một luồng và có thể đạt thông lượng cao hơn với ít luồng I/O hơn, nên số liệu của chúng có thể thấp hơn mức tốt nhất. Chúng tôi không chạy cụm hay nhiều instance của chúng.
• Phạm vi. Mười hai lệnh, một kích thước giá trị, một độ sâu pipeline, không TLS và không lưu trữ bền vững. LPOP và RPOP không được đo, vì ở các tốc độ này, một lần đọc có hủy làm rỗng bất kỳ list nào vừa trong bộ nhớ trong vòng 10 giây. Báo cáo ghi lại độ trễ và mức dùng bộ nhớ, nhưng chúng tôi không so sánh chúng ở đây. Các máy chủ làm lượng việc rất khác nhau trong mỗi lần chạy 10 giây, nên số liệu bộ nhớ không cùng điều kiện. Khối lượng công việc hỗn hợp không được đo.
• Biến thiên. Redis dao động rất mạnh giữa ba lần chạy của nó ở nhiều lệnh, lên đến 7.2 lần giữa lần chạy nhanh nhất và chậm nhất ở HSET, và trung vị che giấu điều đó. So với lần chạy nhanh nhất của từng đối thủ thay vì trung vị, HotKV vẫn dẫn đầu ở cả 11 lệnh.

Redis, Valkey và Dragonfly là nhãn hiệu của chủ sở hữu tương ứng. Chúng chỉ được nêu tên để nhận diện phần mềm chúng tôi đã đo, và điều này không hàm ý bất kỳ sự tài trợ, chứng thực hay liên kết nào.

Những gì đang có hôm nay

Các họ lệnh lõi gồm string, list, set, hash, sorted set, stream, chỉ mục địa lý, bitmap, HyperLogLog, pub/sub và scripting Lua. Các module AI và tính năng enterprise chạy trên các gói có giấy phép. Bảng giá liệt kê mỗi gói bao gồm gì. Xem tài liệu để biết mức bao phủ lệnh hiện tại. Ngoài bộ lệnh Redis:

• Gắn thẻ khóa: gắn nhãn cho khóa bằng thẻ tùy ý và truy vấn theo thẻ (TAG.SET, TAG.MEMBERS và năm lệnh nữa).
• TTL nano giây: NEXPIRE, NTTL và NEXPIREAT đặt và đọc thời hạn hết hạn theo nano giây, nên hạn chót có thể mịn hơn một mili giây. Khóa hết hạn được thu hồi bởi một lượt quét nền và khi chúng được truy cập.
• Nén giá trị tùy chọn: cho các giá trị vượt một ngưỡng kích thước (mặc định 512 byte), tắt trừ khi bạn bật.
• Snapshot không fork: BGSAVE ghi trên một luồng nền thay vì một tiến trình được fork. Một snapshot không phải là bản sao tại một thời điểm. Mỗi khóa được lưu đúng như lúc snapshot chạm tới nó. Việc ghi lại tệp chỉ ghi nối thêm thì có fork.
• Số liệu Prometheus: một endpoint HTTP tích hợp, tắt theo mặc định và bật bằng metrics-port, nên không cần exporter bên ngoài.

HotKV cũng có tìm kiếm vector tích hợp với chỉ mục HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Chúng tôi đã đo nó so với Redis 8 trong Tìm kiếm vector: HotKV so với vector set của Redis 8, từ 1 đến 100 client.

Hãy bắt đầu trên HotKV Cloud, hoặc trò chuyện với bộ phận kinh doanh về việc chạy HotKV trên máy chủ của riêng bạn.