HotKV مخزن بيانات متعدد الخيوط ومتوافق مع Redis، كُتب من الصفر بلغة C++ الحديثة، وبُني ليستخرج أقصى سرعة من الخوادم الحديثة كثيرة الأنوية بأقل تكلفة ممكنة. أنا Norbert E. Boros، المؤسس والرئيس التنفيذي لشركة HotKV Ltd. تشرح هذه التدوينة لماذا بنيته، وما الذي يفعله اليوم، وما الذي أظهرته قياساته.
باختصار. يشغّل HotKV الأوامر على خيوط كثيرة في آنٍ واحد داخل عملية واحدة، ويتحدث RESP2 وRESP3، أي بروتوكول Redis. في اختبار الأداء الذي أجريناه في أكتوبر 2026 على مثيل واحد بـ 160 وحدة vCPU، حقق أعلى إنتاجية في 11 من الأوامر الـ12 التي قسناها، وتعادل معه Dragonfly في الأمر الثاني عشر. نصف أدناه إعداد الاختبار وحدوده.
لماذا بنيتُ HotKV
أهتم بالسرعة في كل ما أبنيه. ينبغي لموقع الويب أو الأداة أو الخادم أن يستجيب على الفور، وحين لا يفعل أريد أن أعرف السبب. وقد شكّلت هذه العادة عملي منذ أن بدأت كتابة البرمجيات.
كانت C وC++ لغتيّ الأساسيتين لسنوات طويلة. وعملت قرابة عشر سنوات على برمجيات لمكافحة الغش في الألعاب، كانت تعمل على الحواسيب الشخصية لآلاف اللاعبين. وكان عليها أن تفحص الذاكرة بحثًا عن أدوات الغش وهي تستهلك أقل قدر ممكن من المعالج والذاكرة، لأن كل دورة تستهلكها كانت تُقتطع من اللعبة. علّمني ذلك العمل أن أقيس كل شيء، وأن أصمّم بما يناسب العتاد، وأن أعدّ انخفاض استهلاك الموارد ميزة قائمة بذاتها.
وإلى جانب ذلك، استخدمت Redis وValkey في مشاريع كثيرة احتاجت إلى ذاكرة تخزين مؤقت سريعة: مخازن الجلسات، وقوائم عناوين IP التي يحظرها جدار حماية، وذاكرة مؤقتة أمام مئات الملايين من سجلات SQL Server. إنها أدوات ممتازة. وقد أثارت فضولي أيضًا لمعرفة ما يمكن أن يقدّمه مخزن للمفاتيح والقيم لو صُمّم منذ البداية للخوادم كثيرة الأنوية التي نشغّلها اليوم.
HotKV هو الجواب الذي توصلت إليه. كتبته من الصفر بلغة C++ الحديثة لأستخرج من العتاد أقصى سرعة ممكنة بأقل تكلفة ممكنة. يُظهر اختبار الأداء أدناه موقعه اليوم، وأتوقع أن يكون هناك المزيد مما يمكن تحقيقه.
تكلفة الذكاء الاصطناعي
وكان هناك سبب ثانٍ. فقد أصبح تشغيل تطبيقات الذكاء الاصطناعي مكلفًا بالنسبة إليّ، وبالنسبة إلى كثيرين غيري أيضًا إذا حكمنا بما كان المطورون يتشاركونه على الإنترنت. وكثيرًا ما يأتي جزء كبير من هذه التكلفة من إرسال أسئلة إلى نموذج سبق أن أجاب عنها. والمخزن السريع الذي يتعرّف على السؤال المكرر أو المشابه ويجيب عنه من الذاكرة المؤقتة هو من أكثر الطرق مباشرةً لخفض هذه الفاتورة، ولهذا فإن التخزين المؤقت لأحمال عمل الذكاء الاصطناعي جزء أساسي من HotKV.
الغاية من HotKV
وُجدت HotKV Ltd لتجعل هذا النوع من البرمجيات أعلى أداءً وأيسر تكلفة. تملك الخوادم الحديثة أنوية كثيرة، وينبغي لمخزن البيانات أن يستخدمها، لتحصل على أكبر قدر ممكن من السرعة بأقل تكلفة ممكنة.
والفكرة الثانية هي جمع جزء أكبر من الحزمة التقنية في مكان واحد. كثيرًا ما ينتهي الأمر بالفرق التي تبني على نماذج LLM إلى تشغيل ذاكرة مؤقتة، وقاعدة بيانات متجهية، ومكان لحفظ ذاكرة الوكلاء، مع كومة من الشيفرة الرابطة بينها. أريد أن يعيش التخزين المؤقت وأعمال الذكاء الاصطناعي المبنية حوله في محرك واحد، بجوار بياناتك: التخزين المؤقت بالتطابق التام والتخزين المؤقت الدلالي لاستدعاءات النماذج، والبحث المتجهي، وذاكرة الوكلاء، وميزانيات الرموز. ينبغي أن يعني تشغيل أنظمة أقل أجزاءً متحركة أقل وفاتورة أصغر. تسرد صفحة الذكاء الاصطناعي ما هو متاح اليوم، ويُظهر اختبار أداء توفير الرموز ما وفّره التخزين المؤقت لاستدعاءات النماذج في اختبارنا.
يحافظ HotKV على بروتوكول Redis ومكتبات العملاء المألوفة.
المشكلة
قد يصبح خيط واحد لتنفيذ الأوامر عنق زجاجة على جهاز كثير الأنوية. ومخزن البيانات المبني حول خيط تنفيذ واحد يصل عادةً إلى بقية الجهاز بتشغيل عدة مثيلات أو عنقود (cluster)، وهذا يجلب معه قرارات في النشر وعملًا تشغيليًا. أردت أن ينطلق HotKV من الطرف الآخر، بأوامر تعمل بالتزامن داخل مثيل واحد، حتى تستطيع عملية واحدة استخدام الجهاز كله.
ما الذي يفعله HotKV بشكل مختلف
كُتب HotKV™ بلغة C++20، وصُمّم لتشغيل الأوامر على أنوية كثيرة في آنٍ واحد، فيستطيع مثيل واحد الاستفادة من جهاز كامل. ويتبع Dragonfly، الذي نختبر أداءه أدناه، نهجًا متعدد الخيوط أيضًا.
- أنوية كثيرة، مثيل واحد. تعمل الأوامر بالتزامن عبر أنوية الجهاز، فيستطيع مثيل واحد استخدام خادم كبير بدلًا من عدة خوادم أصغر.
- عملاء وبروتوكول مألوفون. يدعم HotKV بروتوكولي RESP2 وRESP3، فتستطيع مكتبات العملاء المألوفة الاتصال به. وهو يدعم المعاملات (
MULTI/EXEC) والبرمجة النصية بلغة Lua. راجع توثيق الأوامر لمعرفة الأوامر المدعومة وأي اختلافات.
كيف يُبنى ويُختبر
أبني HotKV بنفسي، وأستعين بالذكاء الاصطناعي حيث يفيد. وما يهم أكثر من طريقة كتابة أي سطر هو ما إذا كان يصمد، لذا يُختبر المحرك بصرامة. فلديه أكثر من 2,000 اختبار آلي، ويُبنى تحت AddressSanitizer وThreadSanitizer وUndefinedBehaviorSanitizer. ولديه أيضًا أهداف اختبار بالمدخلات العشوائية (fuzz) لمحلل البروتوكول، وتوزيع الأوامر، وتحميل ملفات RDB وAOF، وتدفق النسخ المتماثل، وناقل العنقود.
إعداد اختبار الأداء وحدوده ونتائجه الكاملة موجودة في صفحة الأداء، لتحكم على الأرقام بنفسك.
لمحة عن اختبار الأداء
حُدّث في أكتوبر 2026: جاءت الأرقام التي نُشرت أولًا في هذه التدوينة من تشغيلات اختبار أداء تبيّن لنا لاحقًا أنها معيبة (من بين أمور أخرى، استخدم كل مولّد حمل البذرة العشوائية نفسها)، لذا وضعنا مكانها نتائج اختبار الأداء الذي أعدنا بناءه.
أكتوبر 2026: HotKV وRedis وValkey وDragonfly
أجرت HotKV Ltd اختبار الأداء هذا. قسنا HotKV، المبني من الشيفرة المصدرية، مقابل Redis 8.10.2 وValkey 9.1.2 وDragonfly 2.0.2. عمل كل خادم منفردًا، بوصفه مثيلًا واحدًا على جميع وحدات vCPU الـ160 في جهاز Azure D160alds_v7 (AMD EPYC 9V45)، مع تعطيل الاستمرارية. وُلّد الحمل من ثلاثة أجهزة منفصلة في كل منها 64 vCPU باستخدام memtier_benchmark: قيم بحجم 256 بايت، وعمق pipeline يساوي 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 الفعلي لهما أعلى.
| الأمر | HotKV (مليون ops/s) | HotKV مقابل Redis | HotKV مقابل Valkey | HotKV مقابل Dragonfly |
|---|---|---|---|---|
| SET | 50.5 | ≥ 14.80x | ≥ 17.51x | ≥ 3.36x |
| GET | 36.6 | ≥ 32.34x | ≥ 22.46x | ≥ 2.73x |
| MGET | 4.6 | 16.61x | 8.60x | 1.97x |
| SETNX | 55.3 | ≥ 39.58x | ≥ 29.73x | ≥ 3.83x |
| APPEND | 25.1 | 16.37x | 19.41x | 2.83x |
| INCR | 90.8 | 43.15x | 47.33x | 4.41x |
| LPUSH | 31.6 | 25.34x | 37.55x | 2.99x |
| RPUSH | 43.8 | ≥ 69.67x | ≥ 49.83x | ≥ 3.97x |
| SADD | 50.6 | ≥ 24.65x | ≥ 56.60x | ≥ 4.20x |
| HSET | 29.0 | ≥ 54.05x | ≥ 37.09x | ≥ 2.96x |
| MSET | 11.3 | ≥ 29.78x | ≥ 24.26x | ≥ 3.83x |
| PING | 125.2 | ≥ 38.70x | ≥ 35.98x | 0.99x (تعادل) |
قراءة الجدول
يقرأ MGET ثمانية مفاتيح ويكتب MSET أربعة أزواج من المفاتيح والقيم في كل أمر، وتُحسب الإنتاجية بعدد الأوامر. يعلّم التقرير سبعة أرقام لـ HotKV (GET وستة أوامر كتابة) لأنها بلغت عتبة استخدام الشبكة لديه البالغة 85%، ويعلّم PING لأن استخدام المعالج في مولّدات الحمل تجاوز 85%. والنسب المبنية عليها حدود دنيا، وهي معلّمة بالرمز ≥. أما GET وPING فحدّاهما حقيقيان. وفي أوامر الكتابة الستة، يجمع رقم استخدام الشبكة في التقرير حركة البيانات الواردة والصادرة ويقارنها بسقف الصادر، لذا فهو يبالغ في تقدير مدى قربها من الحد. أثقلها، SETNX، استخدم نحو 80% على الأكثر من سقف الوارد المقيس. ونُبقي الرمز ≥ عليها اصطلاحًا تحفظيًا. الجداول الكاملة والعلامات (flags) وملاحظات المنهجية موجودة في صفحة الأداء.
نطاق اختبار الأداء
- البناء والضبط. جُمِّع HotKV باستخدام
-march=nativeلمعالج الاختبار، بينما كانت الخوادم الأخرى بنسخ الإصدار القياسية الخاصة بها. - إعدادات الخيوط. حصل كل خادم على جميع أنوية الجهاز: HotKV بإعداد
--threads 160، وDragonfly بـ 160 خيط proactor، وValkey بإعدادio-threads 160، وRedis بإعدادio-threads 128، وهو الحد الأقصى له. ينفّذ Redis وValkey الأوامر على خيط واحد، وقد يبلغان إنتاجية أعلى بعدد أقل من خيوط I/O، لذا قد تكون أرقامهما دون أفضل ما لديهما. ولم نشغّل عناقيد منهما أو عدة مثيلات منهما. - النطاق. اثنا عشر أمرًا، وحجم قيمة واحد، وعمق pipeline واحد، بلا TLS وبلا استمرارية. لم يُقَس
LPOPوRPOP، لأن القراءة الإتلافية بهذه المعدلات تُفرغ أي قائمة تتسع لها الذاكرة في غضون 10 ثوانٍ. يسجّل التقرير زمن الاستجابة واستخدام الذاكرة، لكننا لا نقارنهما هنا. فقد أنجزت الخوادم مقادير مختلفة جدًا من العمل في كل تشغيل مدته 10 ثوانٍ، لذا فإن أرقام الذاكرة ليست قابلة للمقارنة المباشرة. ولم تُقَس أعباء العمل المختلطة. - التباين. تباينت نتائج Redis كثيرًا بين تشغيلاته الثلاثة في عدة أوامر، بما يصل إلى 7.2 ضعف بين أسرع تشغيل وأبطئه في
HSET، والوسيط يخفي ذلك. وعند المقارنة بأسرع تشغيل لكل منافس بدلًا من وسيطه، ظل HotKV متصدرًا في الأوامر الـ11 جميعها.
تُعدّ Redis وValkey وDragonfly علامات تجارية لمالكيها المعنيين. ونذكرها فقط لتحديد البرمجيات التي قسناها، ولا يعني ذلك أي رعاية أو تأييد أو انتساب.
ما يتوفر اليوم
تشمل عائلات الأوامر الأساسية السلاسل النصية (strings)، والقوائم، والمجموعات، وجداول التجزئة (hashes)، والمجموعات المرتبة، والتدفقات (streams)، والفهارس الجغرافية المكانية، وخرائط البت (bitmaps)، وHyperLogLog، والنشر/الاشتراك (pub/sub)، والبرمجة النصية بلغة Lua. تعمل وحدات الذكاء الاصطناعي وميزات المؤسسات ضمن خطط مرخّصة. وتسرد صفحة الأسعار ما تتضمنه كل خطة. راجع التوثيق لمعرفة التغطية الحالية للأوامر. وبالإضافة إلى مجموعة أوامر Redis:
- وسم المفاتيح: صنّف المفاتيح بأي وسوم تختارها واستعلم عنها حسب الوسم (
TAG.SETوTAG.MEMBERSوخمسة أوامر أخرى). - TTL بدقة النانوثانية: تضبط
NEXPIREوNTTLوNEXPIREATانتهاء الصلاحية وتقرؤه بالنانوثانية، فيمكن أن تكون المهل أدق من ملي ثانية. وتُسترد المفاتيح المنتهية الصلاحية بمسح يجري في الخلفية وعند الوصول إليها. - ضغط اختياري للقيم: للقيم التي يتجاوز حجمها عتبة معينة (512 بايت افتراضيًا)، وهو معطّل ما لم تفعّله.
- لقطات دون fork: يكتب
BGSAVEعلى خيط في الخلفية بدلًا من عملية متفرعة (fork). واللقطة ليست نسخة عند نقطة زمنية واحدة (point-in-time). يُحفظ كل مفتاح على الحال التي كان عليها حين وصلت إليه اللقطة. أما إعادة كتابة ملف الإلحاق فقط (append-only file) فتستخدم fork بالفعل. - مقاييس Prometheus: نقطة نهاية HTTP مدمجة، معطّلة افتراضيًا وتُفعَّل عبر
metrics-port، فلا حاجة إلى أداة تصدير (exporter) خارجية.
ويتضمن HotKV أيضًا بحثًا متجهيًا مدمجًا بفهارس HNSW (VSIM.CREATEINDEX وVSIM.SET وVSIM.SEARCH). وقد قسناه مقابل Redis 8 في البحث المتجهي: HotKV مقابل مجموعات المتجهات في Redis 8، من 1 إلى 100 عميل.
ابدأ على HotKV Cloud، أو تواصل مع المبيعات بشأن تشغيل HotKV على خوادمك الخاصة.
تابع النقاش
التعليقات
لديك أسئلة عن المنهجية؟ حصلت على نتيجة مختلفة على عتادك؟ شارك ما توصلت إليه. تُراجَع التعليقات قبل ظهورها.