แนะนำ HotKV

HotKV เป็นที่เก็บข้อมูลแบบมัลติเธรดที่เข้ากันได้กับ Redis เขียนขึ้นใหม่ทั้งหมดด้วย C++ สมัยใหม่ เพื่อรีดความเร็วจากเซิร์ฟเวอร์หลายคอร์ยุคใหม่ให้ได้มากที่สุดด้วยต้นทุนต่ำที่สุดเท่าที่เป็นไปได้ ผมคือ Norbert E. Boros ผู้ก่อตั้งและ CEO ของ HotKV Ltd บทความนี้อธิบายว่าทำไมผมจึงสร้างมัน วันนี้มันทำอะไรได้บ้าง และวัดผลออกมาอย่างไร

สรุปสั้นๆ HotKV ประมวลผลคำสั่งบนหลายเธรดพร้อมกันภายในโปรเซสเดียว และใช้ RESP2 กับ RESP3 ซึ่งเป็นโปรโตคอลของ Redis ในเบนช์มาร์กอินสแตนซ์เดี่ยวบน 160 vCPU เมื่อเดือนตุลาคม 2026 ของเรา HotKV มีปริมาณงานสูงสุดใน 11 จาก 12 คำสั่งที่เราวัด และ Dragonfly เสมอกันในคำสั่งที่สิบสอง วิธีการติดตั้งและข้อจำกัดอธิบายไว้ด้านล่าง

ทำไมผมจึงสร้าง HotKV

ผมใส่ใจเรื่องความเร็วในทุกสิ่งที่สร้าง เว็บไซต์ เครื่องมือ หรือเซิร์ฟเวอร์ควรตอบสนองทันที และเมื่อมันไม่เป็นเช่นนั้น ผมอยากรู้ว่าเพราะอะไร นิสัยนี้หล่อหลอมงานของผมมาตั้งแต่เริ่มเขียนซอฟต์แวร์

C และ C++ เป็นภาษาหลักของผมมาหลายปี เกือบสิบปีที่ผมทำงานกับซอฟต์แวร์ป้องกันการโกงในเกมที่ทำงานบนพีซีของผู้เล่นนับพัน มันต้องสแกนหน่วยความจำเพื่อหาโปรแกรมโกง ขณะที่ใช้ CPU และหน่วยความจำให้น้อยที่สุดเท่าที่ทำได้ เพราะทุกรอบที่มันใช้ก็คือรอบที่ถูกแย่งไปจากเกม งานนั้นสอนให้ผมวัดทุกอย่าง ออกแบบโดยยึดฮาร์ดแวร์เป็นหลัก และมองว่าการใช้ทรัพยากรน้อยเป็นฟีเจอร์อย่างหนึ่งในตัวเอง

ควบคู่กันไป ผมใช้ Redis และ Valkey ในหลายโปรเจกต์ที่ต้องการแคชที่เร็ว ทั้งที่เก็บเซสชัน รายการที่อยู่ IP ที่ไฟร์วอลล์บล็อก และแคชหน้า SQL Server ที่มีข้อมูลหลายร้อยล้านเรกคอร์ด ทั้งสองเป็นเครื่องมือที่ยอดเยี่ยม แต่ก็ทำให้ผมสงสัยว่าที่เก็บข้อมูลแบบคีย์-ค่าจะทำอะไรได้บ้าง หากถูกออกแบบตั้งแต่ต้นเพื่อเซิร์ฟเวอร์หลายคอร์ที่เราใช้กันทุกวันนี้

HotKV คือคำตอบที่ผมไปถึง ผมเขียนมันขึ้นใหม่ทั้งหมดด้วย C++ สมัยใหม่ เพื่อรีดความเร็วจากฮาร์ดแวร์ให้ได้มากที่สุดด้วยต้นทุนต่ำที่สุดเท่าที่เป็นไปได้ เบนช์มาร์กด้านล่างแสดงว่าวันนี้มันอยู่ตรงไหน และผมคาดว่ายังมีให้ปรับปรุงได้อีก

ต้นทุนของ AI

มีเหตุผลที่สอง การรันแอปพลิเคชัน AI เริ่มแพงขึ้น สำหรับผมเอง และสำหรับนักพัฒนาอีกหลายคน ตามที่พวกเขาแบ่งปันกันทางออนไลน์ ต้นทุนส่วนใหญ่มักมาจากการส่งคำถามที่โมเดลเคยตอบไปแล้วให้มันอีกครั้ง ที่เก็บข้อมูลที่เร็วซึ่งจำคำถามที่ซ้ำหรือคล้ายกันได้ และตอบจากแคช เป็นหนึ่งในวิธีที่ตรงที่สุดในการลดบิลนั้น นี่คือเหตุผลที่การแคชสำหรับเวิร์กโหลด AI เป็นส่วนหลักของ HotKV

HotKV มีไว้เพื่ออะไร

HotKV Ltd ก่อตั้งขึ้นเพื่อทำให้ซอฟต์แวร์ประเภทนี้มีประสิทธิภาพสูงขึ้นและราคาจับต้องได้มากขึ้น เซิร์ฟเวอร์ยุคใหม่มีหลายคอร์ และที่เก็บข้อมูลควรใช้มัน เพื่อให้คุณได้ความเร็วมากที่สุดด้วยต้นทุนต่ำที่สุดเท่าที่เป็นไปได้

แนวคิดที่สองคือรวมสแตกไว้ในที่เดียวให้มากขึ้น ทีมที่สร้างบน LLM มักลงเอยด้วยการรันแคช vector database และที่เก็บหน่วยความจำของเอเจนต์ โดยมีโค้ดเชื่อมต่อกองโตคั่นอยู่ระหว่างกัน ผมอยากให้การแคชและงาน AI ที่สร้างรอบมันอยู่ในเอนจินเดียว ติดกับข้อมูลของคุณ ทั้งการแคชการเรียกโมเดลแบบตรงกันทุกตัวอักษรและเชิงความหมาย vector search หน่วยความจำของเอเจนต์ และงบประมาณโทเค็น ระบบที่ต้องรันน้อยลงควรหมายถึงชิ้นส่วนที่เคลื่อนไหวน้อยลงและบิลที่ต่ำลง หน้า AI แสดงรายการสิ่งที่มีให้ใช้ในวันนี้ และ เบนช์มาร์กการประหยัดโทเค็น แสดงว่าการแคชการเรียกโมเดลประหยัดได้เท่าใดในการทดสอบของเรา

HotKV คงโปรโตคอลของ Redis และไลบรารีไคลเอนต์ที่คุ้นเคยไว้

ปัญหา

เธรดประมวลผลคำสั่งเดี่ยวอาจกลายเป็นคอขวดบนเครื่องที่มีหลายคอร์ ที่เก็บข้อมูลที่สร้างรอบเธรดประมวลผลเดียวมักใช้ส่วนที่เหลือของเครื่องด้วยการรันหลายอินสแตนซ์หรือคลัสเตอร์ ซึ่งนำการตัดสินใจเรื่องการติดตั้งใช้งานและงานปฏิบัติการมาด้วย ผมอยากให้ HotKV เริ่มจากอีกด้านหนึ่ง โดยให้คำสั่งรันพร้อมกันภายในอินสแตนซ์เดียว เพื่อให้โปรเซสเดียวใช้ทั้งเครื่องได้

HotKV ต่างออกไปอย่างไร

HotKV™ เขียนด้วย C++20 และออกแบบให้รันคำสั่งบนหลายคอร์พร้อมกัน อินสแตนซ์เดียวจึงใช้ประโยชน์จากทั้งเครื่องได้ Dragonfly ซึ่งเราเทียบเบนช์มาร์กด้านล่างก็ใช้แนวทางมัลติเธรดเช่นกัน

• หลายคอร์ หนึ่งอินสแตนซ์ คำสั่งรันพร้อมกันข้ามคอร์ของเครื่อง อินสแตนซ์เดียวจึงใช้เซิร์ฟเวอร์ใหญ่ได้แทนเซิร์ฟเวอร์เล็กหลายตัว
• ไคลเอนต์และโปรโตคอลที่คุ้นเคย HotKV รองรับ RESP2 และ RESP3 ไลบรารีไคลเอนต์ที่คุ้นเคยจึงเชื่อมต่อได้ รองรับทรานแซกชัน (MULTI/EXEC) และสคริปต์ Lua ดูเอกสารคำสั่งสำหรับคำสั่งที่รองรับและความแตกต่างต่างๆ

สร้างและทดสอบอย่างไร

ผมสร้าง HotKV ด้วยตัวเองและใช้ AI ช่วยในจุดที่มีประโยชน์ สิ่งที่สำคัญกว่าวิธีเขียนโค้ดแต่ละบรรทัดคือมันทนทานหรือไม่ เอนจินจึงถูกทดสอบอย่างหนัก มีการทดสอบอัตโนมัติมากกว่า 2,000 รายการ และคอมไพล์ภายใต้ AddressSanitizer, ThreadSanitizer และ UndefinedBehaviorSanitizer นอกจากนี้ยังมี fuzz target สำหรับตัวแยกวิเคราะห์โปรโตคอล การจ่ายคำสั่ง การโหลด RDB และ AOF สตรีมการทำสำเนา และบัสของคลัสเตอร์

วิธีตั้งค่าเบนช์มาร์ก ข้อจำกัด และผลทั้งหมดอยู่ในหน้า Performance คุณจึงตัดสินตัวเลขได้ด้วยตัวเอง

ภาพรวมเบนช์มาร์ก

อัปเดตเมื่อเดือนตุลาคม 2026 ตัวเลขที่เผยแพร่ครั้งแรกในโพสต์นี้มาจากการรันเบนช์มาร์กที่เราพบภายหลังว่ามีข้อบกพร่อง (หนึ่งในนั้นคือตัวสร้างโหลดทุกตัวใช้ random seed เดียวกัน) เราจึงเปลี่ยนเป็นผลจากเบนช์มาร์กที่สร้างใหม่

ตุลาคม 2026: HotKV, Redis, Valkey และ Dragonfly

HotKV Ltd เป็นผู้รันเบนช์มาร์กนี้ เราวัด HotKV ที่คอมไพล์จากซอร์ส เทียบกับ Redis 8.10.2, Valkey 9.1.2 และ Dragonfly 2.0.2 แต่ละเซิร์ฟเวอร์รันตามลำพังเป็นอินสแตนซ์เดี่ยวบนทั้ง 160 vCPU ของ Azure D160alds_v7 (AMD EPYC 9V45) โดยปิดการเก็บถาวร เครื่อง 64 vCPU แยกกันสามเครื่องสร้างโหลดด้วย memtier_benchmark ค่าขนาด 256 ไบต์ ความลึกไปป์ไลน์ 30 และคีย์ที่เขียนไว้ล่วงหน้า 5,000,000 คีย์ ทุกตัวเลขคือค่ามัธยฐานของการรัน 10 วินาทีสามรอบ

HotKV มีปริมาณงานสูงสุดใน 11 จาก 12 คำสั่ง เมื่อเทียบกับ Redis หรือ Valkey มันวัดได้ระหว่าง 8.6 ถึงอย่างน้อย 69.7 เท่าของปริมาณงานของทั้งสอง ขึ้นอยู่กับคำสั่งและเซิร์ฟเวอร์ เมื่อเทียบกับ Dragonfly ระหว่าง 1.97 ถึง 4.41 เท่าใน 11 คำสั่งนั้น โดยหลายค่าเป็นค่าขอบล่าง ใน PING Dragonfly วัดได้สูงกว่า 0.6 เปอร์เซ็นต์ เรานับว่าเสมอกัน เพราะตัวสร้างโหลดใกล้ถึงขีดจำกัดของตัวเอง ตัวเลขสูงสุดในคำสั่งข้อมูลคือ 90.8 ล้านการดำเนินการ INCR ต่อวินาที INCR และ PING เคลื่อนข้อมูลน้อยและถูกจำกัดโดยตัวสร้างโหลด ตัวเลขของ HotKV เองสำหรับสองคำสั่งนี้จึงอาจสูงกว่านี้

วิธีอ่านตาราง

MGET อ่านแปดคีย์ และ MSET เขียนสี่คู่คีย์-ค่าต่อหนึ่งคำสั่ง และปริมาณงานนับเป็นจำนวนคำสั่ง รายงานทำเครื่องหมายตัวเลขของ HotKV เจ็ดตัว (GET และคำสั่งเขียนหกคำสั่ง) เพราะถึงเกณฑ์การใช้เครือข่าย 85% และทำเครื่องหมาย PING เพราะตัวสร้างโหลดใช้ CPU เกิน 85% อัตราส่วนที่สร้างบนค่าเหล่านั้นเป็นค่าขอบล่าง ทำเครื่องหมายด้วย ≥ GET และ PING คือขีดจำกัดจริง สำหรับคำสั่งเขียนทั้งหก ตัวเลขการใช้เครือข่ายของรายงานรวมทราฟฟิกขาเข้าและขาออก แล้วเทียบกับเพดานขาออก จึงทำให้ดูใกล้ขีดจำกัดเกินจริง คำสั่งที่หนักที่สุดคือ SETNX ใช้ไม่เกินราว 80% ของเพดานขาเข้าที่วัดได้ เรายังคง ≥ ไว้กับค่าเหล่านั้นตามธรรมเนียมแบบระมัดระวัง ตารางฉบับเต็ม แฟล็ก และบันทึกวิธีการอยู่ในหน้า Performance

ขอบเขตของเบนช์มาร์ก

• บิลด์และการปรับแต่ง HotKV ถูกคอมไพล์ด้วย -march=native สำหรับ CPU ที่ทดสอบ ขณะที่เซิร์ฟเวอร์อื่นเป็นบิลด์รุ่นปล่อยมาตรฐานของตัวเอง
• การตั้งค่าเธรด ทุกเซิร์ฟเวอร์ได้ทุกคอร์ของเครื่อง: HotKV --threads 160, Dragonfly proactor thread 160 ตัว, Valkey io-threads 160 และ Redis io-threads 128 ซึ่งเป็นค่าสูงสุด Redis และ Valkey รันคำสั่งบนเธรดเดียว และอาจได้ปริมาณงานสูงกว่านี้ด้วย I/O thread ที่น้อยลง ตัวเลขของทั้งสองจึงอาจต่ำกว่าค่าที่ดีที่สุดของมัน เราไม่ได้รันคลัสเตอร์หรือหลายอินสแตนซ์ของทั้งสอง
• ขอบเขต สิบสองคำสั่ง ขนาดค่าเดียว ความลึกไปป์ไลน์เดียว ไม่มี TLS และไม่มีการเก็บถาวร ไม่ได้วัด LPOP และ RPOP เพราะที่อัตราเหล่านี้ การอ่านแบบทำลายข้อมูลทำให้ลิสต์ใดก็ตามที่พอดีในหน่วยความจำว่างภายใน 10 วินาที รายงานบันทึกเวลาแฝงและการใช้หน่วยความจำ แต่เราไม่เปรียบเทียบที่นี่ เซิร์ฟเวอร์ทำงานปริมาณต่างกันมากในแต่ละการรัน 10 วินาที ตัวเลขหน่วยความจำจึงเทียบกันตรงๆ ไม่ได้ ไม่ได้วัดเวิร์กโหลดแบบผสม
• ความแปรปรวน Redis แปรปรวนมากระหว่างสามรอบของมันในหลายคำสั่ง สูงสุด 7.2 เท่าระหว่างรอบที่เร็วที่สุดกับช้าที่สุดใน HSET และค่ามัธยฐานซ่อนสิ่งนั้นไว้ เมื่อเทียบกับรอบที่เร็วที่สุดของคู่แข่งแต่ละรายแทนค่ามัธยฐาน HotKV ยังนำใน 11 คำสั่งทั้งหมด

Redis, Valkey และ Dragonfly เป็นเครื่องหมายการค้าของเจ้าของที่เกี่ยวข้อง มีการเอ่ยชื่อเพื่อระบุซอฟต์แวร์ที่เราวัดเท่านั้น และไม่ได้บ่งชี้ถึงการสนับสนุน การรับรอง หรือความเกี่ยวข้องใดๆ

สิ่งที่มีให้ใช้ในวันนี้

กลุ่มคำสั่งหลักประกอบด้วย string, list, set, hash, sorted set, stream, ดัชนีเชิงภูมิศาสตร์, bitmap, HyperLogLog, pub/sub และสคริปต์ Lua โมดูล AI และฟีเจอร์ enterprise ทำงานบนแผนที่มีไลเซนส์ ราคาแสดงสิ่งที่แต่ละแผนรวมไว้ ดูเอกสารสำหรับความครอบคลุมของคำสั่งในปัจจุบัน นอกเหนือจากชุดคำสั่งของ Redis แล้วยังมี:

• การติดแท็กคีย์: ติดป้ายคีย์ด้วยแท็กใดก็ได้และค้นหาตามแท็ก (TAG.SET, TAG.MEMBERS และอีกห้าคำสั่ง)
• TTL ระดับนาโนวินาที: NEXPIRE, NTTL และ NEXPIREAT ตั้งและอ่านเวลาหมดอายุเป็นนาโนวินาที กำหนดเวลาได้ละเอียดกว่าหนึ่งมิลลิวินาที คีย์ที่หมดอายุถูกเก็บคืนโดยการกวาดเบื้องหลัง และเมื่อมีการเข้าถึง
• การบีบอัดค่าแบบเลือกเปิดใช้: สำหรับค่าที่ใหญ่กว่าเกณฑ์ขนาด (ค่าเริ่มต้น 512 ไบต์) ปิดไว้จนกว่าคุณจะเปิด
• สแนปช็อตโดยไม่ fork: BGSAVE เขียนบนเธรดเบื้องหลังแทนโปรเซสที่ fork ออกมา สแนปช็อตไม่ใช่สำเนา ณ จุดเวลาใดจุดหนึ่ง แต่ละคีย์ถูกบันทึกตามสภาพ ณ ตอนที่สแนปช็อตมาถึงคีย์นั้น ส่วนการเขียนไฟล์ append-only ใหม่ยังคง fork
• เมตริก Prometheus: เอนด์พอยต์ HTTP ในตัว ปิดไว้เป็นค่าเริ่มต้นและเปิดด้วย metrics-port จึงไม่ต้องใช้ exporter ภายนอก

HotKV ยังมี vector search ในตัวด้วยดัชนี HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH) เราวัดเทียบกับ Redis 8 ในVector search: HotKV เทียบกับ vector set ของ Redis 8 ตั้งแต่ 1 ถึง 100 ไคลเอนต์

เริ่มต้นใช้งานบน HotKV Cloud หรือคุยกับฝ่ายขายเรื่องการรัน HotKV บนเซิร์ฟเวอร์ของคุณเอง