The rise of distributed applications and cloud computing has created a demand for scalable, high-performance key-value storage systems. This paper presents a performance evaluation of three prominent NoSQL key-value stores: Redis, Aerospike, and Dragonfly, using the Yahoo! Cloud Serving Benchmark (YCSB) framework. We conducted extensive experiments across three distinct workload patterns (read-heavy, write-heavy), and balanced while systematically varying client concurrency from 1 to 32 clients. Our evaluation methodology captures both latency, throughput, and memory characteristics under realistic operational conditions, providing insights into the performance trade-offs and scalability behaviour of each system
academic- معرّف الورقة: 2510.08863
- العنوان: تحليل الأداء المقارن لتقنيات بيانات NoSQL الحديثة: Redis و Aerospike و Dragonfly
- المؤلفون: Deep Bodra (جامعة هاريسبرج للعلوم والتكنولوجيا)، Sushil Khairnar (جامعة فرجينيا التقنية)
- التصنيف: cs.DB cs.DC
- المجلة المنشورة: مجلة البحث والابتكار والتقنيات، المجلد الرابع، العدد 2(8)، 2025
- رابط الورقة: https://doi.org/10.57017/jorit.v4.2(8).05
مع ظهور التطبيقات الموزعة والحوسبة السحابية، يتزايد الطلب على أنظمة تخزين المفاتيح والقيم القابلة للتوسع وعالية الأداء. تقدم هذه الورقة تقييماً للأداء لثلاثة أنظمة NoSQL رئيسية لتخزين المفاتيح والقيم: Redis و Aerospike و Dragonfly، باستخدام إطار عمل Yahoo! Cloud Serving Benchmark (YCSB). أجريت الدراسة تجارب واسعة النطاق تحت ثلاثة أنماط عبء عمل مختلفة (قراءة مكثفة، كتابة مكثفة، ومتوازنة)، مع تغيير عدد العملاء المتزامنين بشكل منهجي من 1 إلى 32. يوفر نهج التقييم رؤى عميقة حول المقايضات الأداء والسلوك القابل للتوسع لكل نظام، مع التقاط خصائص الكمون والإنتاجية والذاكرة في ظروف التشغيل الواقعية.
- تحديات احتياجات التطبيقات الحديثة: يتضمن البيئة الرقمية الحديثة إنشاء واستخدام كميات ضخمة من البيانات، والتوسع السريع لتطبيقات الويب وتقنيات الهاتف المحمول وأجهزة إنترنت الأشياء يفرض تحديات جديدة على أنظمة قواعد البيانات
- قيود قواعد البيانات التقليدية: بينما تتمتع أنظمة إدارة قواعد البيانات العلائقية التقليدية بقوة وظيفية، إلا أنها تواجه صعوبات في تلبية متطلبات الأداء والقابلية للتوسع للتطبيقات الحديثة، خاصة تلك التي تتطلب أوقات استجابة دون الميلي ثانية ومعالجة ملايين العمليات في الثانية
- ظهور قواعد بيانات NoSQL: تتغلب قواعد بيانات NoSQL، خاصة تخزين المفاتيح والقيم، على هذه التحديات من خلال التركيز على الأداء والقابلية للتوسع
- القيمة العملية: توفير إرشادات عملية لمهندسي الأنظمة في اختيار حل تخزين المفاتيح والقيم المناسب
- القيمة الأكاديمية: سد الفجوة في التقييم المقارن المنهجي لأنظمة Redis و Aerospike و Dragonfly
- القيمة التقنية: الكشف عن خصائص الأداء لكل نظام من خلال التقييم المنهجي لأنماط عبء العمل المختلفة ومستويات التزامن
على الرغم من الاستخدام الواسع لهذه الأنظمة، يوجد نقص في الدراسات المقارنة الشاملة التي تقيّم بشكل منهجي خصائص أدائها تحت أنماط عبء عمل ومستويات تزامن متنوعة.
- مقارنة أداء شاملة: توفير تحليل مقارنة أداء كامل يشمل مقاييس الكمون والإنتاجية
- تحليل خصائص استهلاك الذاكرة: دراسة متعمقة لأنماط استخدام الذاكرة والكفاءة للأنظمة الثلاثة
- تقييم متعدد أنماط عبء العمل: تقييم منهجي تحت ثلاثة أنماط عبء عمل: قراءة مكثفة وكتابة مكثفة ومتوازنة
- تحليل القابلية للتوسع: الكشف عن خصائص التوسع لكل نظام من خلال اختبار 1-32 عميل متزامن
- إرشادات عملية: توفير توجيهات فعلية لمهندسي الأنظمة في اختيار حل تخزين المفاتيح والقيم المناسب
Redis:
- متجر بنية بيانات في الذاكرة مفتوح المصدر، تم تطويره عام 2009
- معمارية أحادية الخيط، مما يلغي آليات القفل المعقدة لكن يحد من قابلية التوسع في الأنظمة متعددة النوى
- يدعم بنى بيانات متعددة: السلاسل النصية والجداول والقوائم والمجموعات والمجموعات المرتبة وغيرها
- يحقق الاستمرارية من خلال لقطات دورية أو ملفات إضافة فقط
Aerospike:
- قاعدة بيانات NoSQL موزعة، تأسست عام 2009
- معمارية ذاكرة هجينة: تخزين الفهارس في DRAM وتخزين البيانات على SSD
- معمارية بدون مشاركة، حيث يعمل كل عقدة بشكل مستقل
- توفر اتساقاً قوياً وتحويل فشل تلقائي
Dragonfly:
- متجر بيانات في الذاكرة تم إطلاقه عام 2022، كبديل مباشر لـ Redis
- معمارية متعددة الخيوط وبدون مشاركة، يمكنها الاستفادة من نوى CPU متعددة
- متوافق مع بروتوكول Redis
- ينفذ إدارة ذاكرة معقدة وبنى بيانات خالية من الأقفال
البيئة الحاسوبية:
- النظام: Mac OS مع معالج Apple M3 Pro
- التكوين: 12 نواة، 36GB RAM، macOS Sequoia
- النشر: استخدام حاويات Docker لضمان بيئة متسقة ومعزولة
إطار عمل الاختبار:
- استخدام Yahoo! Cloud Serving Benchmark (YCSB)
- نهج ثنائي المرحلة: مرحلة التحميل لملء البيانات الأولية، مرحلة التشغيل لتنفيذ عمليات الاختبار
- مستويات التزامن: 1، 2، 4، 8، 16، 32 عميل
- توزيع اختيار المفاتيح: توزيع Zipfian، محاكاة أنماط الوصول غير المنتظمة الواقعية
عبء العمل المكثف للقراءة:
- 95% عمليات قراءة، 5% عمليات تحديث
- 1KB بيانات لكل سجل (10 حقول، كل حقل 100 بايت)
- تحميل 1,474,560 سجل
- محاكاة سيناريوهات التخزين المؤقت وأنظمة توزيع المحتوى
عبء العمل المتوازن:
- 50% عمليات قراءة، 50% عمليات تحديث
- نفس بنية السجل 1KB
- يمثل أنماط الوصول المختلطة لمنصات وسائل التواصل الاجتماعي والتطبيقات التعاونية
عبء العمل المكثف للكتابة:
- 10% عمليات قراءة، 90% عمليات إدراج
- بيانات السلاسل الزمنية، 64 حقل، كل حقل 8 أحرف
- تنفيذ 2,949,120 عملية إدراج في مرحلة التشغيل
- محاكاة سيناريوهات تطبيقات إنترنت الأشياء وأنظمة المراقبة وسيناريوهات البلع العالي للبيانات
أداء Aerospike الأمثل:
- كمون P99: 436ms (عميل واحد) إلى 2,979ms (32 عميل)
- الإنتاجية: 3,348 ops/s إلى 32,592 ops/s
- مصدر الأفضلية الأداء هو المعمارية الهجينة للذاكرة والتصميم بدون مشاركة
أداء Redis المتوسطة:
- كمون P99: 862ms إلى 4,447ms
- الإنتاجية: 1,656 إلى 17,158 ops/s
- تصبح المعمارية أحادية الخيط عنق الزجاجة في الأداء تحت التزامن العالي
كمون Dragonfly الأعلى:
- كمون P99: 1,137ms إلى 4,883ms
- الإنتاجية: 1,371 إلى 16,328 ops/s
- تعوض تكاليف التنسيق متعدد الخيوط مزايا المعالجة المتوازية
الحفاظ على التسلسل الهرمي للأداء:
- Aerospike: كمون P99 441ms-2,409ms، إنتاجية 3,372-33,741 ops/s
- Redis: كمون P99 874ms-4,017ms، إنتاجية 1,664-17,004 ops/s
- Dragonfly: كمون P99 1,187ms-4,631ms، إنتاجية 1,278-16,497 ops/s
أفضل أداء لجميع الأنظمة:
- Aerospike: كمون P99 410ms-2,233ms، إنتاجية 3,562-34,896 ops/s
- Redis: كمون P99 808ms-3,547ms، إنتاجية 1,757-17,170 ops/s
- Dragonfly: كمون P99 1,124ms-3,859ms، إنتاجية 1,331-16,925 ops/s
| النظام | قبل التشغيل (MB) | بعد التشغيل (MB) | معامل النمو |
|---|
| Redis | 36.32 | 2610 | 72x |
| Aerospike | 232.1 | 772.3 | 3.3x |
| Dragonfly | 58.98 | 2350 | 40x |
النتائج الرئيسية:
- أعلى كفاءة ذاكرة لـ Aerospike، بفضل نموذج التخزين الهجين
- أكبر نفقات ذاكرة لـ Redis، مما يعكس قيود التخزين في الذاكرة للعقدة الواحدة
- Dragonfly في المنتصف، مع تكاليف إضافية من بنى التنسيق متعددة الخيوط
خصائص توسع الإنتاجية:
- Aerospike: توسع شبه خطي، تحسن 9-10x
- Redis: تحسن 10-11x، لكن نمو الكمون أكثر وضوحاً
- Dragonfly: تحسن 12-13x، أداء أساسي أقل
تستشهد الورقة بعدة دراسات ذات صلة:
- أطر عمل الاختبار: إطار عمل YCSB من Cooper et al. (2010) يضع الأساس لاختبار أنظمة الخدمات السحابية
- دراسات مقارنة NoSQL: المقارنة التجريبية لتخزين المفاتيح والقيم من Anthony و Rao
- دراسات خاصة بالنظام: بحث Volminger (2021) حول Aerospike، تحليل Charan et al. لـ Redis
- التطورات الأخيرة: تقييم Mohan et al. (2024) لـ NoSQL لأحمال عمل OLAP
- قيادة Aerospike الشاملة: تحقيق أفضل أداء تحت جميع أنماط عبء العمل ومستويات التزامن، مع أفضل قابلية توسع للإنتاجية وكمون نسبي منخفض
- استقرار Redis وموثوقيته: أداء مستقرة وقابلة للتنبؤ تحت جميع أنماط عبء العمل، لكن محدود بسبب المعمارية أحادية الخيط
- إمكانات Dragonfly والتحديات: على الرغم من التصميم الحديث، أداء كمون ضعيفة، مع إظهار إمكانات في سيناريوهات الكتابة المكثفة
- تأثير عبء العمل كبير: تحقق جميع قواعد البيانات أفضل أداء تحت ظروف الكتابة المكثفة
- متطلبات الأداء القصوى: اختيار Aerospike
- أولوية البساطة التشغيلية: Redis كافٍ لتلبية الاحتياجات
- متطلبات توافق Redis: Dragonfly خيار مثير للاهتمام، لكن يتطلب تقييماً دقيقاً للتطبيقات الحساسة للكمون
- بيئة اختبار على جهاز واحد: أجريت جميع الاختبارات على جهاز واحد، مما لم يعكس بشكل كامل مزايا الأنظمة الموزعة
- ظروف شبكة محدودة: لم تأخذ في الاعتبار تأثير تأخير الشبكة والتقسيم على الأداء
- توزيع بيانات واحد: استخدام توزيع Zipfian فقط، قد تحتوي التطبيقات الفعلية على أنماط مختلفة
- غياب وضع العنقود: لم يتم اختبار سيناريوهات النشر الموزع الحقيقي
- اختبار بيئة الإنتاج: تقييم أداء الأنظمة في ظروف الإنتاج الحقيقية
- السيناريوهات الموزعة: اختبار قابلية التوسع الموزعة الحقيقية في وضع العنقود
- دراسة نماذج الاتساق: تأثير نظرية CAP على تصميم كل نظام
- آليات تحمل الأخطاء: تقييم آليات تحمل الأخطاء أثناء فشل العقدة
- النسخ المتماثل عبر مراكز البيانات: تأخير الاتساق والنسخ المتماثل للبيانات تحت تقسيم الشبكة
- منهجية صارمة: استخدام إطار عمل YCSB القياسي يضمن مقارنة عادلة
- تجارب شاملة: تغطي أنماط عبء عمل ومستويات تزامن متعددة
- تحليل متعمق: توفير ليس فقط بيانات الأداء بل أيضاً تحليل عميق للأسباب المعمارية
- قيمة عملية عالية: توفير إرشادات واضحة لاختيار النظام الفعلي
- كتابة واضحة: هيكل منطقي ووصف تقني دقيق
- قيود البيئة: بيئة Docker على جهاز واحد لا تعكس بشكل كامل مزايا الأنظمة الموزعة
- تكوين واحد: لم يتم اختبار تأثير معاملات التكوين المختلفة على الأداء
- غياب الاستمرارية: عدم تقييم تفصيلي لتأثير آليات الاستمرارية على الأداء
- غياب تحليل التكلفة: عدم النظر في تكاليف الأجهزة وتعقيد العمليات
- الاستقرار طويل الأجل: نقص اختبارات الاستقرار لفترات تشغيل طويلة
- القيمة الأكاديمية: توفير منهجية منهجية لبحث أداء قواعد بيانات NoSQL
- القيمة العملية: توفير مرجع لاختيار نظام تخزين المفاتيح والقيم المناسب للصناعة
- مساهمة المنهجية: إظهار كيفية مقارنة أداء أنظمة NoSQL بشكل منهجي
- قابلية التكرار: وصف تفصيلي لإعداد التجربة يسهل التكرار والتوسع
- اختيار النظام: توفير مرجع لمشاريع تحتاج إلى اختيار نظام تخزين المفاتيح والقيم
- تحسين الأداء: توفير معايير لتحسين أداء الأنظمة الموجودة
- تصميم المعمارية: توفير أساس لتصميم معمارية الأنظمة الموزعة الكبيرة
- البحث الأكاديمي: توفير بيانات أساسية وإرشادات منهجية لبحث المجالات ذات الصلة
تستشهد الورقة بعدة مراجع مهمة، تشمل:
- Cooper, B.F. et al. (2010). Benchmarking cloud serving systems with YCSB
- Anthony, A., & Rao, Y. N. M. Memcached, Redis, and Aerospike Key-Value Stores Empirical Comparison
- Mohan, R. K. et al. (2024). Evaluating NoSQL Databases for OLAP Workloads
- والوثائق الرسمية والمواد التقنية لأنظمة قواعد البيانات المختلفة
تقدم هذه الورقة مساهمة قيمة في مجال تقييم أداء قواعد بيانات NoSQL، وتوفر من خلال تصميم تجريبي منهجي وتحليل متعمق مرجعاً مهماً لفهم خصائص أداء أنظمة تخزين المفاتيح والقيم الحديثة واختيار الحل التقني المناسب.