خدمات قواعد بيانات AWS: RDS، DynamoDB و Aurora

اختيار قاعدة البيانات غالباً ما يكون أكثر القرارات المعمارية تأثيراً. يقيّم المحاورون قدرتك على مطابقة خصائص قاعدة البيانات مع متطلبات حمل العمل.

إطار اختيار قاعدة البيانات

مصفوفة القرار

العامل	العلائقية (RDS/Aurora)	NoSQL (DynamoDB)	في الذاكرة (ElastiCache)
نموذج البيانات	منظم، مُطبَّع	قيمة-مفتاح، مستند	قيمة-مفتاح، مجموعات، قوائم
أنماط الاستعلام	joins معقدة، تجميعات	جدول واحد، متوقع	عمليات بحث بسيطة، عدادات
قابلية التوسع	رأسي (read replicas)	أفقي (تقسيم)	أفقي (تجزئة)
الاتساق	قوي (ACID)	اتساق نهائي (قابل للتكوين)	اتساق نهائي
حالة الاستخدام	المعاملات، التقارير	ويب/موبايل عالي النطاق	التخزين المؤقت، الجلسات

RDS: قواعد البيانات العلائقية المُدارة

مقارنة المحركات

المحرك	نقاط القوة	الاعتبارات
PostgreSQL	الإضافات، دعم JSON، الامتثال	إعداد النسخ المعقد
MySQL	انتشار واسع، نظام الأدوات	دعم JSON محدود
MariaDB	متوافق مع MySQL، مفتوح المصدر	مجتمع أصغر
Oracle	ميزات المؤسسات، PL/SQL	تكاليف الترخيص
SQL Server	نظام Windows، أدوات BI	تكاليف الترخيص

سؤال المقابلة: التوافر العالي لـ RDS

س: "صمم قاعدة بيانات MySQL عالية التوافر لتطبيق مالي يتطلب RPO < 1 دقيقة و RTO < 5 دقائق."

ج: Multi-AZ مع مراقبة محسنة:

التكوين الأساسي:
  - db.r6g.xlarge (Graviton، فعال من حيث التكلفة)
  - نشر Multi-AZ (نسخ متزامن)
  - تخزين gp3 (16,000 IOPS مُجهَّز)
  - نسخ احتياطي تلقائي (احتفاظ 35 يوم)

التوافر العالي:
  - Multi-AZ: تجاوز الفشل التلقائي < 60 ثانية
  - Read Replicas: 2x في نفس المنطقة لتوسيع القراءة
  - Cross-Region Replica: DR في us-west-2

المراقبة:
  - Enhanced Monitoring (دقة ثانية واحدة)
  - Performance Insights مُفعَّل
  - تنبيهات CloudWatch على تأخر النسخ

تحقيق RPO/RTO:

• Multi-AZ: RPO = 0 (متزامن)، RTO < 2 دقيقة
• Cross-Region: RPO < 1 دقيقة (غير متزامن)، RTO < 5 دقائق (ترقية يدوية)

Aurora: علائقية سحابية أصلية

هندسة Aurora

Aurora تفصل الحوسبة والتخزين:

• الحوسبة: مثيلات DB (كاتب + قارئين)
• التخزين: موزع، توسع تلقائي (حتى 128TB)
• النسخ: نسخ 6 طرق عبر 3 AZs

مقارنة Aurora مقابل RDS

الميزة	Aurora	RDS
توسع التخزين	تلقائي (زيادات 10GB)	يدوي (يتطلب توقف)
تأخر النسخ	< 20ms عادةً	دقائق ممكنة
وقت التجاوز	< 30 ثانية	60-120 ثانية
Read Replicas	حتى 15	حتى 5
التكلفة	~20% أعلى	الأساسي
Global Database	نعم (نسخ < 1 ثانية)	نسخة قراءة عبر المناطق فقط

سؤال المقابلة: Aurora Serverless v2

س: "متى تختار Aurora Serverless v2 على Aurora المُجهَّز؟"

ج: Aurora Serverless v2 يناسب:

• أحمال العمل المتغيرة: Dev/test مع استخدام غير متوقع
• حركة المرور الدفعية: يتوسع فوراً (زيادات 0.5 ACU)
• تحسين التكلفة: ادفع لكل ACU-ساعة
• متعدد المستأجرين: مستأجرين مختلفين بأحمال متفاوتة

اختر المُجهَّز عندما:

• حمل عمل ثابت ومتوقع
• الأداء الأقصى مطلوب (لا بدء بارد)
• يقين التكلفة هو الأولوية
• محجوز بالفعل للسعة القصوى

النهج الهجين: كاتب مُجهَّز + قارئين Serverless v2 للتكلفة/الأداء الأمثل.

DynamoDB: NoSQL بدون خادم

أوضاع السعة

الوضع	الأفضل لـ	التسعير
On-Demand	حركة مرور غير معروفة/متغيرة	ادفع لكل طلب
Provisioned	حركة مرور متوقعة	سعة محجوزة، تكلفة أقل
Auto Scaling	أنماط معروفة مع ذروات	يتوسع ضمن الحدود

أنماط DynamoDB

تصميم الجدول الواحد:

PK                  SK                 Attributes
USER#123            PROFILE            {name, email}
USER#123            ORDER#456          {total, status}
USER#123            ORDER#789          {total, status}
ORDER#456           ORDER#456          {userId, items}

أنماط الوصول:

• الحصول على ملف المستخدم: PK=USER#123، SK=PROFILE
• الحصول على طلبات المستخدم: PK=USER#123، SK begins_with ORDER#
• الحصول على تفاصيل الطلب: PK=ORDER#456، SK=ORDER#456

سؤال المقابلة: القسم الساخن في DynamoDB

س: "جدول DynamoDB الخاص بك يعاني من الاختناق بسبب قسم ساخن. كيف تحل؟"

ج: استراتيجيات تخفيف القسم الساخن:

1. حدد المفتاح الساخن: فعّل CloudWatch Contributor Insights
2. أضف عشوائية لمفتاح القسم:

   # بدلاً من: PK = "STATUS#PENDING"
   # استخدم: PK = "STATUS#PENDING#" + random(1-10)
   

3. استخدم تجزئة الكتابة مع قراءات scatter-gather
4. طبق طبقة تخزين مؤقت: DAX للقراءة المكثفة، ElastiCache لتخزين الكتابة
5. اعتبر وضع on-demand: لا اختناق (لكن تكلفة أعلى)

DynamoDB Global Tables

الميزة	فائدة متعددة المناطق
نشط-نشط	الكتابة لأي منطقة
تأخر النسخ	< 1 ثانية عادةً
حل النزاعات	آخر كاتب يفوز
حالة الاستخدام	تطبيقات عالمية، DR

ElastiCache: التخزين المؤقت في الذاكرة

Redis مقابل Memcached

الميزة	Redis	Memcached
هياكل البيانات	سلاسل، قوائم، مجموعات، تجزئة	سلاسل فقط
الثبات	نعم (RDB، AOF)	لا
النسخ	نعم (أساسي-نسخة)	لا
التجميع	نعم (تجزئة)	نعم
حالة الاستخدام	تخزين مؤقت معقد، جلسات	تخزين مؤقت بسيط

سؤال المقابلة: استراتيجية التخزين المؤقت

س: "صمم استراتيجية تخزين مؤقت لكتالوج منتجات تجارة إلكترونية مع 1M منتج."

ج: نهج التخزين المؤقت متعدد المستويات:

الطبقة 1: CloudFront (الحافة)
  - تخزين مؤقت لصور المنتجات الثابتة
  - TTL: 24 ساعة

الطبقة 2: ElastiCache Redis (التطبيق)
  - تخزين مؤقت لـ JSON تفاصيل المنتج
  - TTL: ساعة واحدة (قابل للتكوين لكل فئة)
  - وضع الكتلة: 3 أجزاء، 2 نسخة لكل منها
  - الذاكرة: r6g.large لكل عقدة (13GB)

الطبقة 3: DynamoDB DAX (قاعدة البيانات)
  - تخزين مؤقت للعناصر الساخنة
  - TTL: 5 دقائق
  - يقلل تكاليف قراءة DynamoDB

الإبطال:
  - مدفوع بالأحداث: SNS عند تحديث المنتج
  - النمط: Cache-aside مع التحميل الكسول

شجرة قرار قاعدة البيانات

تحتاج معاملات ACID؟
  └── نعم → علائقية
       ├── سحابية أصلية، توسع تلقائي؟ → Aurora
       └── تقليدية، تكلفة أقل؟ → RDS
  └── لا → NoSQL
       ├── قيمة-مفتاح، وصول متوقع؟ → DynamoDB
       ├── مخزن مستندات، مخطط مرن؟ → DocumentDB
       └── علاقات رسومية؟ → Neptune

تحتاج تخزين مؤقت؟
  └── قيمة-مفتاح بسيط؟ → ElastiCache Memcached
  └── هياكل معقدة، ثبات؟ → ElastiCache Redis
  └── خاص بـ DynamoDB؟ → DAX

نصيحة للمقابلة: ناقش دائماً استراتيجية النسخ الاحتياطي، التشفير في حالة السكون/أثناء النقل، والمراقبة عند تقديم هندسة قاعدة البيانات.

هذا يختتم وحدة هندسة AWS. اختبر معرفتك مع اختبار الوحدة. :::