التخزين المؤقت وتوسيع قواعد البيانات

يوسّع الموضوع السابق ما يشغّل الكود. وهذا الموضوع يعالج الطبقة التي تنكسر بعدها: مخزن البيانات الذي يجلس خلف كل تلك النسخ ولا يتوسّع بإضافة نسخة أخرى منه. والخطوة الأولى ليست توسيعه أصلاً، بل الكفّ عن سؤاله عن جواب أعطاه قبل قليل. وحين لا يعود التخزين المؤقت يكفي، تتباين آليات التوسيع تبايناً حاداً بين RDS وAurora وDynamoDB، وذلك التباين هو ما يختبره Skill 2.1.2 وSkill 2.1.3.

ما الذي يغطّيه هذا الموضوع

• الحدّ بين ذاكرة الحافة وذاكرة قاعدة البيانات: ما يستطيع CloudFront امتصاصه بلا تغيير في الكود، وما لا يعالجه إلا ElastiCache
• مفتاح التخزين في CloudFront وقواعد TTL: كيف تقيّد cache policy ما يقترحه الأصل، ولماذا تتقدّم Minimum TTL على توجيه no-store
• رفع نسبة الإصابة، والاختيار بين invalidation وأسماء الملفات المُصدَّرة، وطبقة Origin Shield
• استراتيجيات ملء ElastiCache: lazy loading وwrite-through وTTL، والعطل الذي تحمله كل واحدة
• اختيار محرّك ElastiCache وأثره على إجراءات التوسيع، ومقاييس CloudWatch التي تحسم بين عقدة أكبر ونسخ للقراءة وshards أكثر
• نسخ RDS للقراءة وتأخّر النسخ، والفرق بينها وبين نسخة Multi-AZ الاحتياطية، والتوسيع التلقائي للتخزين وRDS Proxy
• وحدة التخزين المشتركة في Aurora ونقاط النهاية الأربع، وAurora Auto Scaling وسعة Serverless بوحدات ACU
• وحدات السعة في DynamoDB وحسبتها، والفرق بين on-demand وprovisioned، وسعة burst والسعة التكيّفية والقسم الساخن، وما يخزّنه DAX وما يمرّره

لماذا هذا مهم

أسئلة هذا الموضوع تشخيصية في معظمها. جدول مخنوق وفيه سعة غير مستهلَكة، أو صفحة شخصية تُقدَّم للزائر الخطأ من الحافة، أو سياسة Aurora Auto Scaling ترفض التوسّع رغم قرّاء مثبّتين عند سقفهم، أو دالة Lambda تستنفد اتصالات قاعدة البيانات. وكل واحدة من هذه الحالات لها سبب بنيوي واحد يفصل الجواب الصحيح عن ثلاثة خيارات معقولة الشكل.

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