تُعد قاعدة البيانات ذلك الجزء من التطبيق المسؤول عن تخزين البيانات لضمان بقائها متاحة حتى بعد إعادة تشغيل التطبيق، أو تعطل الخادم، أو انقطاع التيار الكهربائي. ويمكن للتطبيق لاحقاً استرجاع تلك البيانات بأشكال محددة، مثل جلب سجل واحد باستخدام المعرّف (ID) أو عرض قائمة مُصفّاة حسب المستخدم.
لتوضيح مفهوم “البيانات” بشكل ملموس، لنأخذ مثالاً لتطبيق بسيط لإدارة قوائم المهام. تُمثَّل كل مهمة بسجل يحتوي على حقول مثل task_id (معرّف المهمة)، وuser_id (معرّف المستخدم)، وtitle (العنوان)، وcompleted (حالة الإنجاز)، وcreated_at (تاريخ الإنشاء). ويحتاج التطبيق إلى إجراءين أساسيين: الأول لإنشاء مهمة جديدة، والثاني لعرض قائمة بمهام المستخدم.
في نموذج يعتمد على خادم واحد، يرسل العميل (Client) طلبات HTTP إلى خادم التطبيق، الذي يقوم بدوره بقراءة وكتابة السجلات في قاعدة بيانات واحدة. تضمن قاعدة البيانات سلامة البيانات من خلال فرض قواعد محددة —مثل “كتابة سجل المهمة مرة واحدة فقط لكل طلب”— ولكنها تتسبب أيضاً في حدوث تأخير (Latency) نظراً لأن عمليات القراءة والكتابة تستغرق وقتاً للمعالجة على القرص وفي الذاكرة. دعونا نتتبع مساري الطلبين في مخطط توضيحي واحد.
عند إرسال طلب لإنشاء مهمة، يقوم خادم التطبيق بالتحقق من صحة المدخلات، ثم يطلب من قاعدة البيانات إدراج سجل جديد للمهمة، وبعد ذلك يعيد مُعرِّف المهمة الجديد (task_id) إلى العميل. لا يعتبر العميل عملية الكتابة ناجحة ومكتملة (أي أنها أصبحت دائمة ومحفوظة) إلا بعد تأكيد قاعدة البيانات لها؛ ولهذا السبب تُعد قاعدة البيانات عنصراً حاسماً لضمان صحة البيانات وسلامتها.
عند إرسال طلب لعرض قائمة المهام، يطلب خادم التطبيق من قاعدة البيانات جلب جميع المهام المرتبطة بمعرِّف مستخدم معين (user_id)، وعادةً ما تكون مرتبة حسب وقت الإنشاء (created_at)، ثم يقوم الخادم بتنسيق الاستجابة. عندما تقوم الاستعلامات بمسح عدد من السجلات يفوق حاجتها الفعلية، يزداد العبء على قاعدة البيانات وتطول فترة انتظار العميل؛ ومن ثم يصبح الأداء معتمداً بشكل أساسي على كيفية عثور قاعدة البيانات على السجلات المطابقة.
مع قيام المزيد من المستخدمين بإضافة مهام، يظهر أول خلل ملموس عادةً في بطء عملية عرض قائمة المهام، وذلك لأن قاعدة البيانات تضطر لقراءة كميات كبيرة من البيانات لتلبية استعلام واحد. بعد ذلك، قد يتسبب وجود مستخدم نشط للغاية أو قائمة مشتركة في حدوث حالات انتظار ناتجة عن “أقفال” البيانات (lock waits)؛ حيث تحاول عمليات كتابة متعددة تحديث نفس السجل أو مجموعة السجلات، مما يؤدي إلى اصطفاف الطلبات في طابور بدلاً من إتمامها بشكل متوازٍ. وأخيراً، إذا توقفت عملية قاعدة البيانات الوحيدة أو تعطل الخادم الذي تعمل عليه، يتوقف التطبيق بأكمله عن تقديم خدماته نظراً لاعتماد كافة الطلبات عليه. يوضح الرسم البياني التالي نقاط الضغط الثلاث هذه على نفس الخط المرجعي.