dragonfly
v1.25.4
قبل المضي قدمًا، يرجى التفكير في منحنا نجمة GitHub ️. شكرًا لك!
لغات أخرى: 简体中文 日本語 한국어
موقع الويب • المستندات • البداية السريعة • خلاف المجتمع • منتدى Dragonfly • انضم إلى مجتمع Dragonfly
مناقشات GitHub • مشكلات GitHub • المساهمة • Dragonfly Cloud
Dragonfly عبارة عن مخزن بيانات في الذاكرة مصمم لأحمال عمل التطبيقات الحديثة.
متوافق تمامًا مع واجهات برمجة تطبيقات Redis وMemcached، ولا يتطلب Dragonfly أي تغييرات في التعليمات البرمجية لاعتماده. بالمقارنة مع مخازن البيانات القديمة في الذاكرة، يوفر Dragonfly إنتاجية أكبر بمقدار 25 مرة، ومعدلات أعلى لذاكرة التخزين المؤقت مع زمن استجابة أقل، ويمكن تشغيله على موارد أقل بنسبة تصل إلى 80% لنفس حجم العمل.
قمنا أولاً بمقارنة Dragonfly مع Redis على مثيل m5.large الذي يُستخدم بشكل شائع لتشغيل Redis نظرًا لبنيته أحادية الترابط. يتم تشغيل البرنامج المعياري من مثيل آخر لاختبار التحميل (c5n) في نفس منطقة توافر الخدمات باستخدام memtier_benchmark -c 20 --test-time 100 -t 4 -d 256 --distinct-client-seed
يُظهر Dragonfly أداءً مشابهًا:
--ratio 1:0 ):| ريديس | مدافع |
|---|---|
| QPS: 159K، P99.9: 1.16 مللي ثانية، P99: 0.82 مللي ثانية | QPS:173K، P99.9: 1.26 مللي ثانية، P99: 0.9 مللي ثانية |
--ratio 0:1 ):| ريديس | مدافع |
|---|---|
| QPS: 194K، P99.9: 0.8 مللي ثانية، P99: 0.65 مللي ثانية | QPS: 191K، P99.9: 0.95 مللي ثانية، P99: 0.8 مللي ثانية |
يوضح المعيار أعلاه أن الطبقة الخوارزمية الموجودة داخل DF والتي تسمح لها بالتوسع عموديًا لا تسبب خسائر كبيرة عند تشغيل خيط واحد.
ومع ذلك، إذا أخذنا مثالًا أقوى قليلاً (m5.xlarge)، فإن الفجوة بين DF وRedis تبدأ في الاتساع. ( memtier_benchmark -c 20 --test-time 100 -t 6 -d 256 --distinct-client-seed ):
--ratio 1:0 ):| ريديس | مدافع |
|---|---|
| QPS: 190K، P99.9: 2.45 مللي ثانية، P99: 0.97 مللي ثانية | QPS: 279K، P99.9: 1.95 مللي ثانية، P99: 1.48 مللي ثانية |
--ratio 0:1 ):| ريديس | مدافع |
|---|---|
| QPS: 220K، P99.9: 0.98 مللي ثانية، P99: 0.8 مللي ثانية | QPS: 305K، P99.9: 1.03 مللي ثانية، P99: 0.87 مللي ثانية |
تستمر سعة إنتاجية Dragonfly في النمو مع حجم المثيل، في حين أن Redis أحادي الترابط يعوقه وحدة المعالجة المركزية ويصل إلى الحد الأقصى المحلي من حيث الأداء.
إذا قارنا Dragonfly وRedis على المثيل الأكثر قدرة على الشبكة c6gn.16xlarge، فقد أظهر Dragonfly زيادة بمقدار 25 مرة في الإنتاجية مقارنة بعملية Redis الفردية، متجاوزًا 3.8 مليون QPS.
مقاييس زمن الوصول المئوية التاسعة والتسعين لـ Dragonfly في ذروة الإنتاجية:
| مرجع سابق | r6g | c6gn | c7g |
|---|---|---|---|
| تعيين | 0.8 مللي ثانية | 1 مللي ثانية | 1 مللي ثانية |
| يحصل | 0.9 مللي ثانية | 0.9 مللي ثانية | 0.8 مللي ثانية |
| setex | 0.9 مللي ثانية | 1.1 مللي ثانية | 1.3 مللي ثانية |
تم تنفيذ جميع المعايير باستخدام memtier_benchmark (انظر أدناه) مع عدد المواضيع التي تم ضبطها لكل خادم ونوع المثيل. تم تشغيل memtier على جهاز c6gn.16xlarge منفصل. لقد قمنا بتعيين وقت انتهاء الصلاحية على 500 لمعيار SETEX لضمان بقاءه بعد نهاية الاختبار.
memtier_benchmark --ratio ... -t < threads > -c 30 -n 200000 --distinct-client-seed -d 256
--expiry-range=... في وضع خط الأنابيب --pipeline=30 ، يصل Dragonfly إلى 10M QPS لعمليات SET و 15M QPS لعمليات GET.
قمنا بمقارنة Dragonfly مع Memcached على مثيل c6gn.16xlarge على AWS.
مع زمن استجابة مماثل، تفوقت إنتاجية Dragonfly على إنتاجية Memcached في كل من أحمال عمل الكتابة والقراءة. أظهر Dragonfly زمن وصول أفضل في أعباء عمل الكتابة بسبب التنافس على مسار الكتابة في Memcached.
| الخادم | QPS (آلاف QPS) | الكمون 99% | 99.9% |
|---|---|---|---|
| اليعسوب | ؟ 3844 | ؟ 0.9 مللي ثانية | ؟ 2.4 مللي ثانية |
| ميمكاشد | 806 | 1.6 مللي ثانية | 3.2 مللي ثانية |
| الخادم | QPS (آلاف QPS) | الكمون 99% | 99.9% |
|---|---|---|---|
| اليعسوب | ؟ 3717 | 1 مللي ثانية | 2.4 مللي ثانية |
| ميمكاشد | 2100 | ؟ 0.34 مللي ثانية | ؟ 0.6 مللي ثانية |
أظهرت Memcached زمن استجابة أقل لمعيار القراءة، ولكن أيضًا إنتاجية أقل.
لاختبار كفاءة الذاكرة، ملأنا Dragonfly وRedis بحوالي 5 غيغابايت من البيانات باستخدام الأمر debug populate 5000000 key 1024 ، وأرسلنا حركة مرور التحديث باستخدام memtier ، وبدأنا عملية اللقطة باستخدام الأمر bgsave .
يوضح هذا الشكل كيفية تصرف كل خادم من حيث كفاءة الذاكرة.
كان Dragonfly أكثر كفاءة في الذاكرة بنسبة 30% من Redis في حالة الخمول ولم يُظهر أي زيادة واضحة في استخدام الذاكرة أثناء مرحلة اللقطة. في الذروة، زاد استخدام ذاكرة Redis إلى ما يقرب من 3 أضعاف استخدام Dragonfly.
أنهى Dragonfly اللقطة بشكل أسرع، في غضون ثوانٍ قليلة.
لمزيد من المعلومات حول كفاءة الذاكرة في Dragonfly، راجع مستند Dashtable الخاص بنا.
يدعم Dragonfly وسيطات Redis الشائعة حيثما أمكن ذلك. على سبيل المثال، يمكنك تشغيل: dragonfly --requirepass=foo --bind localhost .
يدعم Dragonfly حاليًا الوسائط التالية الخاصة بـ Redis:
port : منفذ اتصال Redis ( default: 6379 ).bind : استخدم localhost للسماح فقط باتصالات المضيف المحلي أو عنوان IP عام للسماح بالاتصالات بعنوان IP هذا (أي من الخارج أيضًا). استخدم 0.0.0.0 للسماح بجميع عناوين IPv4.requirepass : كلمة المرور لمصادقة المصادقة ( default: "" ).maxmemory : الحد الأقصى للذاكرة (بالبايت الذي يمكن قراءته بواسطة الإنسان) التي تستخدمها قاعدة البيانات ( default: 0 ). تعني قيمة maxmemory 0 أن البرنامج سيحدد تلقائيًا الحد الأقصى لاستخدام الذاكرة.dir : يستخدم Dragonfly Docker المجلد /data لالتقاط اللقطات بشكل افتراضي، ويستخدم سطر الأوامر "" . يمكنك استخدام خيار -v Docker لتعيينه إلى مجلد المضيف الخاص بك.dbfilename : اسم الملف لحفظ وتحميل قاعدة البيانات ( default: dump ).هناك أيضًا بعض الحجج الخاصة بـ Dragonfly:
memcached_port : المنفذ لتمكين واجهة برمجة التطبيقات المتوافقة مع Memcached ( default: disabled ).
keys_output_limit : الحد الأقصى لعدد المفاتيح التي تم إرجاعها في أمر keys ( default: 8192 ). لاحظ أن keys أمر خطير. نقوم باقتطاع نتيجتها لتجنب حدوث تضخم في استخدام الذاكرة عند جلب عدد كبير جدًا من المفاتيح.
dbnum : الحد الأقصى لعدد قواعد البيانات المدعومة select .
cache_mode : راجع قسم تصميم ذاكرة التخزين المؤقت الجديد أدناه.
hz : تكرار تقييم انتهاء صلاحية المفتاح ( default: 100 ). يستخدم التردد المنخفض وحدة معالجة مركزية أقل عندما يكون خاملاً على حساب معدل إخلاء أبطأ.
snapshot_cron : تعبير جدول Cron للقطات النسخ الاحتياطي التلقائي باستخدام بناء جملة cron القياسي مع دقة الدقائق ( default: "" ). فيما يلي بعض الأمثلة على تعبيرات جدول cron أدناه، ولا تتردد في قراءة المزيد حول هذه الوسيطة في وثائقنا.
| تعبير جدول كرون | وصف |
|---|---|
* * * * * | في كل دقيقة |
*/5 * * * * | في كل 5 دقائق |
5 */2 * * * | في الدقيقة 5 بعد كل ساعتين |
0 0 * * * | الساعة 00:00 (منتصف الليل) كل يوم |
0 6 * * 1-5 | الساعة 06:00 (الفجر) من الاثنين إلى الجمعة |
primary_port_http_enabled : يسمح بالوصول إلى وحدة تحكم HTTP على منفذ TCP الرئيسي إذا كان true ( default: true ).
admin_port : لتمكين وصول المسؤول إلى وحدة التحكم على المنفذ المخصص ( default: disabled ). يدعم كلا من بروتوكولات HTTP وRESP.
admin_bind : لربط اتصال TCP لوحدة التحكم الإدارية بعنوان معين ( default: any ). يدعم كلا من بروتوكولات HTTP وRESP.
admin_nopass : لتمكين الوصول الإداري المفتوح إلى وحدة التحكم على المنفذ المخصص، دون الحاجة إلى رمز المصادقة المميز ( default: false ). يدعم كلا من بروتوكولات HTTP وRESP.
cluster_mode : وضع المجموعة مدعوم ( default: "" ). يدعم حاليا فقط emulated .
cluster_announce_ip : عنوان IP الذي تعلنه أوامر المجموعة للعميل.
announce_port : المنفذ الذي تعلنه أوامر المجموعة للعميل وللنسخ المتماثل الرئيسي.
./dragonfly-x86_64 --logtostderr --requirepass=youshallnotpass --cache_mode=true -dbnum 1 --bind localhost --port 6379 --maxmemory=12gb --keys_output_limit=12288 --dbfilename dump.rdbيمكن أيضًا تقديم الحجج عبر:
--flagfile <filename> : يجب أن يدرج الملف علامة واحدة في كل سطر، مع علامات المساواة بدلاً من المسافات لعلامات القيمة الرئيسية. ليست هناك حاجة لعلامات الاقتباس لقيم العلامة.DFLY_x ، حيث x هو الاسم الدقيق للعلامة، وهو حساس لحالة الأحرف. لمزيد من الخيارات مثل إدارة السجلات أو دعم TLS، قم بتشغيل dragonfly --help .
يدعم Dragonfly حاليًا حوالي 185 أمرًا من أوامر Redis وجميع أوامر Memcached إلى جانب cas . على قدم المساواة تقريبًا مع Redis 5 API، سيكون الإنجاز التالي لـ Dragonfly هو تحقيق الاستقرار في الوظائف الأساسية وتنفيذ واجهة برمجة التطبيقات للنسخ المتماثل. إذا كان هناك أمر تحتاجه ولم يتم تنفيذه بعد، فيرجى فتح مشكلة.
بالنسبة للنسخ المتماثل لـ Dragonfly الأصلي، فإننا نقوم بتصميم تنسيق سجل موزع يدعم سرعات أعلى من حيث الحجم.
بعد ميزة النسخ المتماثل، سنواصل إضافة الأوامر المفقودة لإصدارات Redis 3-6 APIs.
يرجى الاطلاع على مرجع الأوامر الخاص بنا للتعرف على الأوامر الحالية التي يدعمها Dragonfly.
يحتوي Dragonfly على خوارزمية تخزين مؤقت واحدة وموحدة وقابلة للتكيف، وهي بسيطة وفعالة في الذاكرة.
يمكنك تمكين وضع التخزين المؤقت عن طريق تمرير العلامة --cache_mode=true . بمجرد تشغيل هذا الوضع، سيقوم Dragonfly بطرد العناصر التي من غير المرجح أن يتم العثور عليها في المستقبل ولكن فقط عندما تكون قريبة من الحد maxmemory .
نطاقات انتهاء الصلاحية تقتصر على ~ 8 سنوات.
يتم تقريب المواعيد النهائية لانتهاء الصلاحية بدقة ميلي ثانية (PEXPIRE، PSETEX، وما إلى ذلك) إلى أقرب ثانية للمواعيد النهائية الأكبر من 2^28 مللي ثانية ، والتي تحتوي على خطأ أقل من 0.001% ويجب أن تكون مقبولة للنطاقات الكبيرة. إذا لم يكن هذا مناسبًا لحالة الاستخدام الخاصة بك، فاتصل بنا أو افتح مشكلة تشرح حالتك.
لمزيد من الاختلافات التفصيلية بين المواعيد النهائية لانتهاء صلاحية Dragonfly وتطبيقات Redis، راجع هنا.
افتراضيًا، يسمح Dragonfly بالوصول إلى HTTP عبر منفذ TCP الرئيسي (6379). هذا صحيح، يمكنك الاتصال بـ Dragonfly عبر بروتوكول Redis وعبر بروتوكول HTTP - يتعرف الخادم على البروتوكول تلقائيًا أثناء بدء الاتصال. تفضل وجربه مع متصفحك. لا يحتوي الوصول عبر HTTP حاليًا على الكثير من المعلومات ولكنه سيتضمن معلومات مفيدة حول تصحيح الأخطاء والإدارة في المستقبل.
انتقل إلى عنوان URL :6379/metrics لعرض المقاييس المتوافقة مع Prometheus.
تتوافق مقاييس Prometheus المصدرة مع لوحة معلومات Grafana، انظر هنا.
مهم! من المفترض أن يتم الوصول إلى وحدة تحكم HTTP ضمن شبكة آمنة. إذا كشفت عن منفذ TCP الخاص بـ Dragonfly خارجيًا، فننصحك بتعطيل وحدة التحكم باستخدام --http_admin_console=false أو --nohttp_admin_console .
بدأت Dragonfly كتجربة لمعرفة كيف يمكن أن يبدو مخزن البيانات في الذاكرة إذا تم تصميمه في عام 2022. واستنادًا إلى الدروس المستفادة من تجربتنا كمستخدمين لمخازن الذاكرة ومهندسين عملوا في شركات سحابية، علمنا أننا بحاجة إلى الحفاظ على اثنين من مخازن الذاكرة. الخصائص الرئيسية لـ Dragonfly: تضمن Atomicity لجميع العمليات وزمن وصول منخفض أقل من مللي ثانية على إنتاجية عالية جدًا.
كان التحدي الأول الذي واجهنا هو كيفية الاستفادة الكاملة من موارد وحدة المعالجة المركزية والذاكرة والإدخال/الإخراج باستخدام الخوادم المتوفرة اليوم في السحابات العامة. لحل هذه المشكلة، نستخدم بنية لا شيء مشترك، والتي تسمح لنا بتقسيم مساحة المفاتيح الخاصة بمخزن الذاكرة بين الخيوط بحيث يتمكن كل مؤشر ترابط من إدارة شريحة بيانات القاموس الخاصة به. نحن نسمي هذه الشرائح "شظايا". المكتبة التي تدعم إدارة الخيط والإدخال/الإخراج لهندسة لا شيء مشتركة مفتوحة المصدر هنا.
لتوفير ضمانات ذرية للعمليات متعددة المفاتيح، نستخدم التطورات التي تم تحقيقها من الأبحاث الأكاديمية الحديثة. لقد اخترنا الورقة البحثية "VLL: إعادة تصميم مدير القفل لأنظمة قواعد بيانات الذاكرة الرئيسية" لتطوير إطار المعاملات لـ Dragonfly. وقد أتاح لنا اختيار بنية عدم المشاركة وVLL إنشاء عمليات ذرية متعددة المفاتيح دون استخدام كائنات المزامنة أو أقفال الدوران. كان بمثابة معلم رئيسي في إثبات المفهوم (PoC) الخاص بنا وتميز أداؤه عن الحلول التجارية ومفتوحة المصدر الأخرى.
وكان التحدي الثاني الذي واجهنا هو تصميم هياكل بيانات أكثر كفاءة للمتجر الجديد. لتحقيق هذا الهدف، قمنا ببناء هيكلنا الأساسي القابل للتجزئة على الورقة "Dash: Scalable Hashing on Persistent Memory". تتمحور الورقة نفسها حول مجال الذاكرة الدائمة ولا ترتبط مباشرة بمخازن الذاكرة الرئيسية، ولكنها لا تزال الأكثر قابلية للتطبيق على مشكلتنا. سمح لنا التصميم القابل للتجزئة المقترح في الورقة بالحفاظ على خاصيتين خاصتين موجودتين في قاموس Redis: قدرة التجزئة التزايدية أثناء نمو مخزن البيانات، والقدرة على اجتياز القاموس تحت التغييرات باستخدام عملية مسح عديمة الحالة. بالإضافة إلى هاتين الخاصيتين، تعد الداش أكثر كفاءة في استخدام وحدة المعالجة المركزية والذاكرة. ومن خلال الاستفادة من تصميم داش، تمكنا من الابتكار بشكل أكبر باستخدام الميزات التالية:
بمجرد أن قمنا ببناء الأساس لـ Dragonfly وكنا سعداء بأدائه، واصلنا تنفيذ وظائف Redis وMemcached. لقد قمنا حتى الآن بتنفيذ حوالي 185 أمرًا من أوامر Redis (أي ما يعادل تقريبًا Redis 5.0 API) و13 أمرًا من أوامر Memcached.
وأخيرا،
تتمثل مهمتنا في إنشاء مخزن بيانات في الذاكرة مصمم جيدًا وفائق السرعة وفعال من حيث التكلفة لأحمال العمل السحابية التي تستفيد من أحدث التطورات في الأجهزة. نعتزم معالجة نقاط الضعف في الحلول الحالية مع الحفاظ على واجهات برمجة تطبيقات المنتجات ومقترحاتها.
