زمن الاستجابة والإنتاجية وقابلية التوسع الأفقي

العتاد الأكبر ليس أسرع دائماً — لكنه يستطيع عادةً تحمّل حِمل أكبر. والعتاد الأكبر أشبه بطريق أوسع لا بسيارة أسرع: فلا يمكنك القيادة أسرع — حسناً، لا يُسمح لك — لمجرد أن هناك ممرات أكثر. وهذا سبب عدم تحسين العتاد الأكثر لاستعلامات SQL البطيئة تلقائياً.

لم نعد في التسعينيات؛ إذ كانت قدرة الحوسبة للمعالجات أحادية النواة تزداد بسرعة آنذاك، فاختفت معظم مشكلات زمن الاستجابة على العتاد الأحدث — بسبب المعالج المحسَّن فقط. كان الأمر كسيارات جديدة تسير بسرعة ضعف الموديلات القديمة — كل عام! غير أن قوة المعالج أحادي النواة بلغت حدّها في السنوات الأولى من القرن الحادي والعشرين، فلم يبقَ أي تحسن تقريباً على هذا المحور. وللاستمرار في بناء معالجات أقوى، وجب على الموردين التحوّل إلى استراتيجية النوى المتعددة. ومع أنها تتيح تشغيل مهام متعددة تزامنياً، فهي لا تحسّن الأداء إذا كانت هناك مهمة واحدة فقط؛ فالأداء له أكثر من بُعد واحد.

وللتوسع الأفقي (إضافة مزيد من الخوادم) قيود مشابهة؛ فمع أن مزيداً من الخوادم يستطيع معالجة طلبات أكثر، إلا أنها لا تحسّن زمن الاستجابة لاستعلام معيّن واحد. ولجعل البحث أسرع، تحتاج إلى شجرة بحث فعّالة — حتى في الأنظمة غير العلائقية مثل CouchDB وMongoDB.

مهم

الفهرسة السليمة أفضل طريقة لتقليل زمن استجابة الاستعلامات — في قواعد بيانات SQL العلائقية كما في الأنظمة غير العلائقية.

وتهدف الفهرسة السليمة إلى استغلال قابلية التوسع اللوغاريتمية لـفهرس شجرة B استغلالاً كاملاً. للأسف، تجري الفهرسة عادةً بطريقة متهاونة جداً. ويُظهر المخطط في «آثار حجم البيانات في الأداء» أثر الفهرسة المتهاونة ظهوراً جلياً.

الشكل 3.5 زمن الاستجابة حسب حجم البياناتالفرق في زمن الاستجابة بين فهرس متهاون وفهرس سليم مذهل، ويكاد يكون من المستحيل تعويض هذا الأثر بإضافة عتاد أكثر. وحتى إذا نجحت في تقصير زمن الاستجابة بالعتاد، فسيظل ذلك موضع شك في كونه أفضل حل لهذه المشكلة.

وما زالت أنظمة كثيرة مما يسمى NoSQL تزعم حل جميع مشكلات الأداء بقابلية التوسع الأفقي. غير أن هذه القابلية تقتصر غالباً على عمليات الكتابة وتُنجز بنموذج ما يسمى الاتساق النهائي. وتستخدم قواعد بيانات SQL نموذج اتساق صارماً يبطئ عمليات الكتابة، لكن ذلك لا يعني بالضرورة إنتاجية سيئة. اعرف المزيد عن ذلك في المربع المعنون «الاتساق النهائي ومبرهنة CAP».

الاتساق النهائي ومبرهنة CAP

يتطلب الحفاظ على الاتساق الصارم في نظام موزَّع تنسيقاً تزامنياً لجميع عمليات الكتابة بين العُقد. ولهذا المبدأ أثران جانبيان غير سارّين: (1) يضيف أزمنة استجابة ويزيدها؛ (2) يقلل الإتاحة الكلية لأن عدة أعضاء يجب أن تكون متاحة في الوقت نفسه لإتمام عملية كتابة.

وغالباً ما يُخلط بين قاعدة بيانات SQL موزَّعة وعناقيد الحواسيب التي تستخدم نظام تخزين مشتركاً أو تكراراً رئيسياً-تابعاً. وفي الحقيقة، قاعدة البيانات الموزَّعة أشبه بمتجر إلكتروني متكامل مع نظام ERP — وهما غالباً منتجان مختلفان من موردين مختلفين. ويبقى الاتساق بين النظامين هدفاً مرغوباً يتحقق كثيراً باستخدام بروتوكول الإيداع على مرحلتين (2PC). وقد أنشأ هذا البروتوكول معاملات شاملة تقدّم سلوك «الكل أو لا شيء» المعروف عبر قواعد بيانات متعددة. ولا يكون إتمام معاملة شاملة ممكناً إلا إذا كانت جميع الأعضاء المساهمة متاحة، ما يقلل الإتاحة الكلية.

وكلما زاد عدد عُقد النظام الموزَّع، صار الاتساق الصارم أكثر إزعاجاً؛ فالحفاظ عليه شبه مستحيل إذا كان النظام يضم أكثر من عُقد قليلة. أما إسقاط الاتساق الصارم فيحل مشكلة الإتاحة ويزيل زمن الاستجابة المتزايد. والفكرة الأساسية هي إعادة إنشاء الاتساق الشامل بعد إتمام عملية الكتابة على مجموعة فرعية من العُقد. ويترك هذا النهج مشكلة واحدة دون حل: يستحيل منع التعارضات إذا قبلت عقدتان تغييرين متناقضين. ويُبلَغ الاتساق في النهاية بـمعالجة التعارضات لا بـمنعها. وفي هذا السياق، يعني الاتساق أن جميع العُقد تملك البيانات نفسها — وهي ليست بالضرورة البيانات الصحيحة أو الأفضل.

وتصف مبرهنة CAP لـBrewer التبعيات العامة بين الاتساق (Consistency) والإتاحة (Availability) وتحمّل التقسيم (Partition tolerance).

والعتاد الأكثر لن يحسّن أزمنة الاستجابة عادةً، بل قد يجعل النظام أبطأ لأن التعقيد الإضافي قد يراكم أزمنة استجابة أكثر. ولن تكون أزمنة استجابة الشبكة مشكلة إذا عمل التطبيق وقاعدة البيانات على الحاسوب نفسه، لكن هذا الإعداد غير شائع في بيئات الإنتاج حيث تُثبَّت قاعدة البيانات والتطبيق عادةً على عتاد مخصص. وقد تفرض سياسات الأمان حتى جدار حماية بين خادم التطبيق وقاعدة البيانات — ما يضاعف زمن استجابة الشبكة غالباً. وكلما زاد تعقيد البنية التحتية، تراكمت أزمنة الاستجابة وصارت الاستجابات أبطأ. ويؤدي هذا الأثر غالباً إلى الملاحظة المخالفة للحدس بأن عتاد الإنتاج الغالي أبطأ من بيئة الحاسوب المكتبي الرخيص المستخدمة في التطوير.

إن أعجبك هذا الموضوع، قد يعجبك أيضاً…

… أن تشترك في القوائم البريدية، وتحصل على ملصقات مجانية، وتشتري كتابي، أو تنضم إلى دورة تدريبية.

وثمة زمن استجابة مهم آخر هو زمن البحث على القرص. وتحتاج أقراص القرص الصلب الدوّارة (HDD) وقتاً طويلاً نسبياً لضبط الأجزاء الميكانيكية بحيث يمكن قراءة البيانات المطلوبة — بضعة أجزاء من الألف من الثانية عادةً. ويحدث زمن الاستجابة هذا أربع مرات عند اجتياز شجرة B من أربعة مستويات — أي بضعة عشرات من الأجزاء من الألف من الثانية في المجموع. ومع أن ذلك نصف أبد بالنسبة إلى الحواسيب، فهو لا يزال أدنى بكثير من عتبة إدراكنا… عند حدوثه مرة واحدة. غير أنه من السهل جداً إثارة مئات أو حتى آلاف عمليات البحث على القرص بعبارة SQL واحدة، خصوصاً عند دمج عدة جداول بعملية ربط. ومع أن التخزين المؤقت يقلل المشكلة تقليلاً هائلاً، وأن تقنيات جديدة مثل SSD تخفّض زمن البحث بمقدار مرتبة عددية، فما زالت عمليات الربط موضع شك عام في كونها بطيئة. ولذلك سيشرح الفصل التالي كيفية استخدام الفهارس لعمليات ربط فعّالة بين الجداول.

أقراص الحالة الصلبة (SSD) والتخزين المؤقت

أقراص الحالة الصلبة (SSD) تقنية تخزين جماهيري لا تستخدم أجزاء متحركة، وزمن البحث النموذجي فيها أسرع بمقدار مرتبة عددية من زمن البحث في أقراص HDD. وقد صارت أقراص SSD متاحة لتخزين المؤسسات نحو عام 2010، لكنها لا تُستخدم عادةً لقواعد البيانات بسبب كلفتها العالية وعمرها المحدود.

غير أن قواعد البيانات تخزّن البيانات كثيرة الوصول مؤقتاً في الذاكرة الرئيسية، وهذا مفيد بوجه خاص للبيانات اللازمة في كل وصول إلى الفهرس — مثل عُقد جذر الفهرس. وقد تخزّن قاعدة البيانات الفهارس كثيرة الاستخدام مؤقتاً بالكامل بحيث لا يثير البحث في الفهرس أي عملية بحث على القرص.

مربع حقائق

• للأداء بُعدان: زمن الاستجابة والإنتاجية.
• العتاد الأكثر لن يحسّن زمن استجابة الاستعلامات عادةً.
• الفهرسة السليمة أفضل طريقة لتحسين زمن استجابة الاستعلامات.

روابط

• وصف الإعداد الخاص بالمخطط.
• NoSQL والاتساق النهائي ومبرهنة CAP لـBrewer على Wikipedia
• فهارس شجرة B في CouchDB وMongoDB.
• مقال: «اختيار NoSQL للسبب الصحيح»