Benchmarking Real-Time Database Synchronisation Architectures: REST Polling, WebSocket Push, and CockroachDB CDC
تقدم هذه الورقة بحثاً معيارياً منضبطاً يقارن بين بنيات الاستعلام الدوري عبر REST (REST polling)، والدفع عبر WebSocket (WebSocket push)، وتغيير بيانات كوكروتش دبي (CockroachDB CDC) لمزامنة قواعد البيانات في الوقت الفعلي، كاشفةً أنه في حين يوفر الدفع عبر WebSocket أدنى وسيط زمن استجابة (median latency) ويوفر الاستعلام الدوري عبر REST تأخيراً محدوداً يمكن التنبؤ به، فإن تقنية CDC تقدم أوساطاً تنافسية لكنها تعاني من تأخر كبير في زمن الاستجابة عند الذيل (tail latency) بسبب عمليات التجميع وعدم التوافق في البروتوكولات المحددة.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في عالم البرمجيات الحديثة، هناك رغبة متزايدة في تطبيقات تشعر وكأنها تعيش على جهازك، حتى عندما لا تكون متصلاً بالإنترنت. هذا النهج، الذي يُطلق عليه غالباً البرمجيات ذات الأولوية المحلية (local-first software)، يتيح لك تحرير مستند أو تحديث قائمة أثناء عدم الاتصال، مع انتظار التغييرات ليتم إرسالها إلى خادم مركزي بمجرد عودة اتصالك. ويكمن التحدي في اللحظة التي يتم فيها استعادة الاتصال: كيف يقرر الكمبيوتر أي نسخة من البيانات هي الصحيحة، وما مدى سرعة تحديث الخادم المركزي دون أن ينتظر المستخدم؟ ولكي يعمل هذا بسلاسة، يحتاج النظام إلى طريقة موثوقة للاستماع إلى المعلومات الجديدة وتسليمها فوراً. فإذا كان التحديث بطيئاً جداً، يشعر المستخدم ببطء في الاستجابة؛ وإذا كان النظام معقداً للغاية، فإنه يستنزف البطارية أو يتسبب في الانهيار. السؤال الجوهري للمهندسين هو كيفية بناء آلية الاستماع هذه: هل يجب على الجهاز أن يسأل الخادم باستمرار عما إذا كان قد تغير شيء ما، أم يجب على الخادم أن يصرخ بالتغييرات فور حدوثها، أم يجب على قاعدة البيانات نفسها أن تحتفظ بسجل مستمر لكل إجراء ليتم قراءته لاحقاً؟
لقد شرع باحث في المعهد الهندي للتكنولوجيا في كهارغبور في اختبار هذه الاستراتيجيات الثلاث الشائعة جنباً إلى جنب ليرى أياً منها يعمل بشكل أفضل في بيئة محكومة. قارنت الدراسة طريقة يتحقق فيها العميل من التحديثات في فترات زمنية ثابتة، وطريقة يقوم فيها الخادم بدفع التغييرات فوراً عبر اتصال دائم، وطريقة تقوم فيها قاعدة البيانات ببث سجل لكل تغيير للمشتركين. ولضمان اختبار عادل، قام الباحث ببناء ثلاثة أنظمة تبدو متطابقة للمستخدم ولكنها تستخدم تروساً داخلية مختلفة. استخدم أحد الأنظمة قاعدة بيانات قياسية مع حلقة "تحقق" بسيطة. واستخدم نظام آخر نفس قاعدة البيانات ولكن أضاف "محفزاً" (trigger) يطلق إشارة في اللحظة التي يحدث فيها تغيير. أما النظام الثالث، فقد استخدم قاعدة بيانات موزعة مختلفة مصممة لبث تاريخها الخاص. كان الهدف هو قياس الوقت الدقيق الذي يستغرقه التغيير الذي أجراه المستخدم للعبور من خلال النظام والظهور على شاشة المستمع، واختبار كل شيء بدءاً من مستخدم واحد وصولاً إلى خمسين مستخدماً يكتبون في نفس الوقت.
رسمت النتائج صورة واضحة لكيفية سلوك كل طريقة تحت الضغط. أثبت النظام الذي اعتمد على صراخ الخادم بالتغييرات فوراً عبر اتصال دائم أنه الأسرع. ففي أفضل الحالات، ظهر التغيير على شاشة المستمع في غضون مللي ثانٍين فقط، وحتى عندما كان خمسون شخصاً يكتبون في وقت واحد، نادراً ما تجاوز التأخير ثلاثة وستين مللي ثانية. حافظت هذه الطريقة على سرعتها بشكل ثابت ومثير للإعجاب، حيث وصلت أبطأ التحديثات إلى أقل من ربع ثانية. أما الطريقة التي اعتمدت على طلب العميل للتحديثات كل مائة مللي ثانية فكانت يمكن التنبؤ بها ولكنها أبطأ. ولأن العميل كان عليه الانتظار لدوره للسؤال، بلغ متوسط التأخير حوالي ستين مللي ثانية، لكنه لم يكن بإمكانه أبداً أن يكون أسرع من الوقت بين عمليات التحقق. وعندما كتب العديد من المستخدمين في وقت واحد، زاد وقت الانتظار هذا، مما دفع متوسط التأخير إلى أكثر من مائة مللي ثانية. وأظهر النظام الذي استخدم سجل التغييرات الداخلي لقاعدة البيانات أداءً مختلطاً؛ فبينما وصل التحديث النموذجي بسرعة، غالباً في أقل من ثانية، عانى النظام من تأخيرات شديدة في أبطأ التحديثات القليلة. وفي بعض الأحيان، استغرق التغيير أكثر من ثانيتين للوصول، وفي حالات معينة، امتد التأخير إلى أكثر من ثلاث ثوانٍ ونصف.
اكتشف الباحث أن أبطأ التحديثات في النظام القائم على السجلات لم تكن عيباً في فكرة تسجيل التغييرات نفسها، بل كانت نتيجة لكيفية اتصال برنامج معين. فقد استخدم النظام حلاً بديلاً (workaround) لقراءة سجل قاعدة البيانات لأن أداة الاتصال القياسية لم تكن تتحدث لغة قاعدة البيانات بشكل صحيح. تطلب هذا الحل البديل بدء عملية جديدة في كل مرة ينقطع فيها الاتصال، مما أضاف عقوبة ثقيلة تتراوح من ثانية إلى أربع ثوانٍ إلى التأخير. لولا هذا العائق التقني المحدد، لربما كان أداء الطريقة القائمة على السجلات أفضل بكثير، ولكن في هذا الاختبار، جعلت التأخيرات الطويلة هذه الطريقة غير مناسبة للتطبيقات التي يتوقع فيها المستخدمون استجابة فورية. كما أكدت الدراسة قاعدة بسيطة لطريقة التحقق: كلما طال الانتظار بين عمليات التحقق، زاد متوسط التأخير. فإذا كان النظام يتحقق كل خمسين مللي ثانية، فإن متوسط الانتظار يكون حوالي ستة وثلاثين مللي ثانية؛ وإذا انتظر خمسمائة مللي ثانية بين عمليات التحقق، يقفز متوسط الانتظار إلى أكثر من ثلاثمائة مللي ثانية.
تقدم هذه النتائج دليلاً عملياً لبناء برمجيات تحتاج إلى البقاء متزامنة. بالنسبة للتطبيقات التي تكون فيها السرعة حاسمة، مثل أدوات التحرير التعاوني حيث يكتب المستخدمون معاً في الوقت الفعلي، فإن الطريقة التي يدفع فيها الخادم التغيات فوراً هي الخيار الأمثل. فهي توفر أقل قدر من التأخير وأكثر الأداء اتساقاً، حتى عندما يستخدم الكثير من الناس النظام في وقت واحد. أما الطريقة التي يتحقق فيها العميل من التحديثات على فترات منتظمة فهي خيار جيد للتطبيقات الأبسط حيث يكون التأخير لعدة مئات من المللي ثوانٍ مقبولاً، أو حيث يكون الحفاظ على الاتصال مفتوحاً صعباً، كما هو الحال في الأجهزة المحمولة التي تحاول توفير البطارية. أما الطريقة التي تبث سجل قاعدة البيانات فهي قوية لنقل كميات كبيرة من البيانات أو إنشاء النسخ الاحتياطية، ولكن التنفيذ المحدد الذي تم اختباره كان بطيئاً وغير متوقع للاستخدام التفاعلي. وتخلص الدراسة إلى أنه بينما تعمل جميع الطرق الثلاث، فإن الخيار الأفضل يعتمد تماماً على ما إذا كانت الأولوية هي الاستجابة الفورية أو البساطة التشغيلية.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.