AWS SAA 06 - Adding a Database Layer

🎯 Adding a Database Layer — إضافة طبقة قاعدة بيانات

اختيار قاعدة البيانات المناسبة لتطبيقك هو قرار مصيري يؤثر في الأداء وقابلية التوسع. يركز هذا المقال على أنواع قواعد البيانات التي تقدمها AWS — من العلائقية (RDS) إلى NoSQL (DynamoDB) وذاكرة التخزين المؤقت (ElastiCache) — لمساعدتك في اختيار الحل الأمثل لاحتياجات تطبيقك.

1️⃣ Database Options in the Cloud — خيارات قواعد البيانات في السحابة

📖 لديك خياران أساسيان لتشغيل قاعدة البيانات: مُدارة بالكامل (managed) أو ذاتية الإدارة (unmanaged) على EC2.
الخدمات المُدارة مثل RDS وDynamoDB تتولى AWS فيها مهام النسخ الاحتياطي والتصحيح والأمان والتوسع، بينما تمنحك القاعدة على EC2 تحكماً كاملاً مقابل مسؤولية إدارة أكبر.

📋 قاعدة بيانات مُدارة مقابل قاعدة على EC2

• قاعدة مُدارة (RDS): AWS تدير كل شيء — التصحيح، النسخ الاحتياطي، التوسع، التوفر العالي — أنت تركز على البيانات والتطبيق فقط.
• قاعدة على EC2: أنت تدير كل شيء — تثبيت المحرك، التصحيح، النسخ الاحتياطي، التوسع — تحكم كامل لكن جهد إداري أكبر.
• الخدمات المُدارة توفر وقتك ومالك على المدى الطويل — مهندس القواعد يكلف أكثر من فرق تكلفة الخدمة المُدارة.

شركة ناشئة تختار بين خيارين لقاعدة بيانات تطبيقها.
الخيار الأول: تثبيت MySQL على مثيل EC2 — يوفر مرونة لكن المهندس يقضي 30% من وقته في الصيانة والنسخ الاحتياطي.
الخيار الثاني: Amazon RDS for MySQL — نفس المحرك لكن AWS تتولى الصيانة والتوسع والنسخ الاحتياطي التلقائي.
تختار RDS وتوفر 15 ساعة أسبوعياً من وقت الفريق تركز فيها على تطوير ميزات جديدة للتطبيق.

2️⃣ AWS Database Services Family — عائلة خدمات قواعد البيانات في AWS

📖 AWS تقدم مجموعة متكاملة من خدمات قواعد البيانات تغطي جميع النماذج: العلائقية وغير العلائقية والتخزين المؤقت ومستودعات البيانات والرسم البياني.
كل خدمة صُممت لحالة استخدام محددة، مما يسمح لك باختيار الأداة المناسبة لكل مهمة بدلاً من استخدام حل واحد للجميع.

📋 عائلة خدمات قواعد البيانات في AWS

• Amazon RDS: قواعد علائقية مُدارة — MySQL, PostgreSQL, Oracle, SQL Server, MariaDB.
• Amazon Aurora: محرك علائقي متوافق مع MySQL وPostgreSQL، أسرع بخمس مرات وأقل تكلفة.
• Amazon DynamoDB: قاعدة بيانات NoSQL مُدارة بالكامل — نموذج مفتاح-قيمة ووثائقي بأداء فائق السرعة.
• Amazon ElastiCache: خدمة تخزين مؤقت في الذاكرة تدعم Redis وMemcached.
• Amazon Redshift: مستودع بيانات تحليلي للاستعلامات المعقدة على نطاق بيتابايت.
• Amazon Neptune: قاعدة بيانات رسم بياني (Graph) مُدارة بالكامل.
• Amazon DocumentDB: قاعدة وثائقية متوافقة مع MongoDB.
• Amazon Keyspaces: قاعدة بيانات واسعة الأعمدة متوافقة مع Apache Cassandra.
• Amazon Timestream: قاعدة بيانات سلاسل زمنية لبيانات IoT والتطبيقات التشغيلية.
• Amazon Quantum Ledger Database (QLDB): سجل حسابات ثابت وشفاف وقابل للتحقق.

منصة توصيل طعام تستخدم أربع خدمات قواعد بيانات مختلفة: RDS لبيانات العملاء والطلبات (علائقية منظمة)، DynamoDB لبيانات السائقين في الوقت الفعلي (سرعة فائقة)، ElastiCache لتخزين قوائم المطاعم مؤقتاً (استجابة أقل من ميلي ثانية)، Redshift لتحليل سلوك المستخدمين شهرياً (استعلامات معقدة). كل خدمة في المكان المناسب تماماً.

🔑 قواعد البيانات المتخصصة الست: Amazon DocumentDB (قاعدة وثائقية متوافقة مع MongoDB للمحتوى والكتالوجات)، Amazon Keyspaces (قاعدة واسعة الأعمدة متوافقة مع Apache Cassandra لأحمال العمل عالية الإنتاجية)، Amazon MemoryDB (قاعدة بيانات في الذاكرة متوافقة مع Redis للمعالجة فائقة السرعة مع متانة عالية)، Amazon Neptune (قاعدة رسم بياني للتطبيقات ذات العلاقات المعقدة مثل محركات التوصية وكشف الاحتيال)، Amazon Timestream (قاعدة سلاسل زمنية لبيانات IoT والمراقبة — أسرع بـ 1,000 مرة وأرخص بـ 90% من قواعد البيانات التقليدية)، Amazon QLDB (سجل حسابات ثابت وشفاف وغير قابل للتغيير — مثالي لسجلات المعاملات المالية وسلاسل التوريد). لكل حالة استخدام قاعدة بيانات متخصصة — لا تجبر كل شيء في قاعدة علائقية واحدة.

✅ خلاصة: Database Considerations — اعتبارات طبقة قاعدة البيانات

• خياران أساسيان: قواعد مُدارة (RDS, DynamoDB) تتولى AWS صيانتها، أو قواعد ذاتية الإدارة على EC2 بتحكم كامل ومسؤولية أكبر.
• عائلة خدمات AWS تضم: RDS (علائقية)، Aurora (الجيل التالي)، DynamoDB (NoSQL)، ElastiCache (تخزين مؤقت)، Redshift (تحليلات)، وقواعد متخصصة.
• القاعدة الذهبية: اختر قاعدة البيانات المناسبة لكل حالة استخدام — لا تفرض نموذجاً واحداً على جميع احتياجات التطبيق.

قواعد البيانات في السحابة مثل أنواع المطابخ المختلفة.
قاعدة بيانات علائقية (RDS) تشبه مطبخ فندق خمس نجوم: منظم بدقة، كل مكون له مكانه، والعلاقات بين الأطباق واضحة (قوائم، فواتير، حجوزات).
قاعدة NoSQL (DynamoDB) تشبه مطبخ وجبات سريعة: سريع، مرن، يتعامل مع أي طلب فوراً دون بنية جامدة.
التخزين المؤقت (ElastiCache) مثل ثلاجة العرض الأمامية: البيانات الأكثر طلباً في متناول اليد مباشرة.
مستودع البيانات (Redshift) مثل أرشيف الوصفات: يستعرض تاريخ المبيعات ويحلل التوجهات لاكتشاف الفرص الجديدة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Managed Database	قاعدة بيانات مُدارة	خدمة تتولى AWS فيها التصحيح والنسخ الاحتياطي والتوسع تلقائياً.
Unmanaged Database	قاعدة بيانات ذاتية الإدارة	قاعدة تشغلها بنفسك على EC2 مع تحكم كامل ومسؤولية إدارة أكبر.
Relational Database	قاعدة بيانات علائقية	تخزن البيانات في جداول مترابطة مع دعم SQL وعلاقات المفاتيح.
NoSQL Database	قاعدة بيانات غير علائقية	تخزن البيانات بنماذج مرنة مثل مفتاح-قيمة أو وثائقي أو عمودي.
Data Warehouse	مستودع بيانات	نظام لتحليل البيانات التاريخية الضخمة باستعلامات SQL معقدة.
In-Memory Cache	تخزين مؤقت في الذاكرة	تخزين البيانات الساخنة في RAM لتقليل زمن الاستجابة إلى ميكروثانية.

1️⃣ What is Amazon RDS? — ما هي خدمة Amazon RDS؟

📖 Amazon RDS تتيح لك تشغيل قواعد بيانات علائقية مُدارة بالكامل في السحابة دون القلق بشأن البنية التحتية.
تتولى AWS المهام الثقيلة: توفير البنية الأساسية، التصحيح التلقائي، النسخ الاحتياطي، والتوسع — أنت تركز على تصميم المخطط والاستعلامات والتطبيق.

📋 محركات قواعد البيانات المدعومة في RDS

• MySQL: الأكثر شعبية للمواقع وتطبيقات الويب ومتوافق مع تطبيقات LAMP وWordPress.
• PostgreSQL: قوي وغني بالميزات المتقدمة مثل JSONB والبحث النصي الكامل وأنواع البيانات المخصصة.
• MariaDB: فرع من MySQL يركز على الأداء والاستقرار بترخيص مفتوح المصدر.
• Oracle: للمؤسسات الكبيرة مع ميزات متقدمة ودعم كامل لتراخيص Bring Your Own License (BYOL).
• SQL Server: لتطبيقات Windows و.NET مع دعم كامل لميزات SQL Server من Microsoft.

شركة تقنية تنتقل من مركز بيانات داخلي إلى AWS.
لديها 3 قواعد بيانات: PostgreSQL لتطبيق الويب، MySQL لنظام إدارة المحتوى، وSQL Server لنظام ERP.
بدلاً من إدارة 3 مثيلات EC2 بأنظمة تشغيل مختلفة، تنشئ 3 مثيلات RDS بمحركات مختلفة وتديرها كلها من نفس وحدة التحكم.
النتيجة: فريق واحد يدير كل شيء من مكان واحد.

2️⃣ RDS Instance Specifications — مواصفات مثيل RDS

📖 لكل مثيل RDS حدود تخزين تصل إلى 64 تيرابايت ويستخدم وحدات تخزين EBS للأغراض العامة (gp3) أو المخصصة للإنتاجية العالية (io2).
التخزين يتوسع تلقائياً عند تفعيل ميزة auto-scaling للتخزين، مما يحمي قاعدة البيانات من التوقف عند امتلاء القرص.

📋 مواصفات مثيل RDS

• يأتي المثيل بأنواع مثل db.t3 (للأغراض العامة) وdb.r6g (محسنة للذاكرة) وdb.m6i (متوازنة).
• التخزين من 20 جيجابايت حتى 64 تيرابايت مع إمكانية التوسع التلقائي عند الوصول إلى حد الامتلاء.
• يدعم التشفير في حالة السكون (at rest) باستخدام AWS KMS وفي حالة النقل (in transit) باستخدام SSL/TLS.
• النسخ الاحتياطي التلقائي اليومي مع إمكانية الاستعادة إلى أي نقطة زمنية خلال فترة الاحتفاظ (حتى 35 يوماً).

3️⃣ High Availability with Multi-AZ — التوفر العالي مع Multi-AZ

📖 نشر RDS في وضع Multi-AZ ينشئ نسخة احتياطية متزامنة في منطقة توفر ثانية لضمان استمرارية العمل عند الفشل.
عند تعطل منطقة التوفر الأساسية، تفشل RDS تلقائياً إلى النسخة الاحتياطية في أقل من دقيقتين، ويتم تحديث DNS تلقائياً ليشير إلى المثيل الجديد.

📋 آلية Multi-AZ

• النسخ المتزامن (synchronous replication): كل كتابة إلى القاعدة الأساسية تُنسخ فوراً إلى القاعدة الاحتياطية.
• اكتشاف الفشل التلقائي: AWS تراقب صحة المثيل الأساسي وتتحول آلياً عند الحاجة.
• لا حاجة لتغيير اتصال التطبيق: اسم DNS لا يتغير، التطبيق يعيد الاتصال تلقائياً.
• مثالي للإنتاج: أي تطبيق يحتاج استمرارية عالية يستفيد من Multi-AZ بدون أي تعديل في الكود.

تطبيق مصرفي يعالج آلاف المعاملات في الدقيقة.
ينشر RDS في وضع Multi-AZ عبر منطقتي توفر (AZ1 وAZ2).
في الساعة 3 صباحاً، يحدث عطل كهربائي في AZ1.
تكتشف AWS الفشل وتنقل تلقائياً إلى AZ2 خلال 60 ثانية فقط.
المستخدمون النهائيون يلاحظون تباطؤاً بسيطاً لمدة دقيقة واحدة ثم يستأنف التطبيق عمله بشكل طبيعي، دون أي تدخل بشري.

4️⃣ Scalable Reads with Read Replicas — قراءة قابلة للتوسع مع Read Replicas

📖 النسخ المتماثلة للقراءة (Read Replicas) تتيح لك توزيع حمل القراءة على عدة نسخ لتحسين الأداء مع بقاء الكتابة حصرية على المثيل الأساسي.
يمكنك إنشاء حتى 15 نسخة قابلة للقراءة ضمن نفس المنطقة أو عبر مناطق مختلفة لتقليل زمن الاستجابة للمستخدمين في أنحاء العالم.

📋 ميزات Read Replicas

• النسخ غير المتزامن (asynchronous): كتابات المثيل الأساسي تُنسخ إلى النسخ القابلة للقراءة مع تأخير بسيط جداً.
• كل نسخة لها نقطة نهاية DNS خاصة بها: التطبيق يوزع استعلامات القراءة بينها باستخدام موازن تحميل أو منطق في طبقة التطبيق.
• يمكن ترقية النسخة إلى مثيل أساسي مستقل: مفيد للتعافي من الكوارث أو إنشاء بيئات اختبار ببيانات حقيقية.
• النسخ عبر المناطق (cross-region): تحسين زمن الوصول للمستخدمين العالميين أو إنشاء خطة تعافي من الكوارث.

منصة تعليم إلكتروني عالمية بقاعدة PostgreSQL في أمريكا الشمالية.
لتحسين أداء الطلاب في آسيا وأوروبا، تنشئ Read Replicas في سنغافورة وفرانكفورت.
تطبيق الهاتف يوجه استعلامات القراءة (عرض الدورات والدرجات) إلى أقرب نسخة جغرافياً، بينما عمليات الكتابة (تسجيل الدورات) تذهب إلى المثيل الأساسي في أمريكا.
زمن الاستجابة ينخفض من 800ms إلى 30ms للطلاب في آسيا.

5️⃣ Backup and Restore — النسخ الاحتياطي والاستعادة

📖 RDS توفر نوعين من النسخ الاحتياطي: تلقائي (automated) ويدوي (snapshot) مع إمكانية الاستعادة إلى نقطة زمنية محددة.
النسخ الاحتياطي التلقائي يخزن سجلات التغيير مما يسمح بالاستعادة لأي ثانية خلال فترة الاحتفاظ، بينما اللقطات اليدوية تبقى حتى تحذفها.

📋 استراتيجية النسخ الاحتياطي

• النسخ التلقائي: يومي مع سجلات معاملات مخزنة كل 5 دقائق، فترة احتفاظ 1–35 يوماً.
• اللقطات اليدوية: تبقى حتى تحذفها، مثالية قبل تغييرات كبيرة في المخطط أو ترقيات.
• الاستعادة تنشئ مثيلاً جديداً منفصلاً: لا تؤثر على المثيل الإنتاجي الأصلي.
• يمكن نسخ اللقطات إلى مناطق AWS أخرى للتعافي من الكوارث.

مهندس DevOps يستعد لترقية كبيرة في مخطط قاعدة بيانات.
قبل البدء، يلتقط لقطة يدوية (snapshot).
أثناء الترقية، يحدث خطأ يؤدي لتلف بعض الجداول.
يستعيد اللقطة إلى مثيل جديد خلال 10 دقائق ويعيد توجيه التطبيق إليه — العودة للإنتاج تتم بنفس البيانات السليمة دون أي فقدان.

✅ خلاصة Amazon RDS:

• خدمة مُدارة تدعم 5 محركات علائقية رئيسية بأتمتة كاملة للصيانة والنسخ الاحتياطي.
• Multi-AZ يوفر توفراً عالياً عبر نسخ متزامن في منطقتي توفر مختلفتين.
• Read Replicas (حتى 15 نسخة) توزع حمل القراءة وتحسن الأداء عالمياً.
• النسخ الاحتياطي التلقائي يدعم الاستعادة لأي نقطة زمنية خلال 35 يوماً.
• التشفير في السكون والنقل مع إدارة المفاتيح عبر AWS KMS.

🔑 امتثال ACID: ACID تعني Atomicity (الذرية — إما تنجح المعاملة كاملة أو تفشل كاملة)، Consistency (الاتساق — البيانات تنتقل من حالة صحيحة إلى أخرى)، Isolation (العزل — المعاملات المتزامنة لا تتداخل)، Durability (المتانة — المعاملة المكتملة تبقى محفوظة حتى بعد انقطاع الطاقة). جميع محركات Amazon RDS تدعم امتثال ACID الكامل، مما يجعلها مثالية للتطبيقات المالية والمصرفية وأنظمة تخطيط موارد المؤسسات (ERP) حيث سلامة البيانات أمر لا يقبل المساومة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon RDS	خدمة قواعد البيانات العلائقية	خدمة مُدارة لتشغيل MySQL وPostgreSQL وOracle وSQL Server وMariaDB.
Multi-AZ	النشر متعدد مناطق التوفر	نسخ متزامن لقاعدة البيانات عبر منطقتي توفر لضمان التوفر العالي والتعافي التلقائي.
Read Replica	النسخة المتماثلة للقراءة	نسخة للقراءة فقط تُوزع حمل الاستعلامات وتُحسن الأداء عالمياً.
Automated Backup	النسخ الاحتياطي التلقائي	نسخ يومي مع سجلات معاملات كل 5 دقائق يدعم الاستعادة لأي نقطة زمنية.
DB Snapshot	لقطة قاعدة البيانات	نسخة يدوية تبقى حتى تُحذف — مثالية قبل الترقيات والتغييرات الكبيرة.
DB Engine	محرك قاعدة البيانات	البرنامج الأساسي لقاعدة البيانات مثل MySQL وPostgreSQL وOracle وSQL Server وMariaDB.

1️⃣ What is Amazon RDS Proxy? — ما هو Amazon RDS Proxy؟

📖 Amazon RDS Proxy هو وسيط قواعد بيانات (Database Proxy) مُدار بالكامل يجلس بين تطبيقك وقاعدة بيانات RDS لتجميع الاتصالات ومشاركتها بكفاءة.
يعمل كطبقة وسيطة شفافة تتولى إدارة مجموعة الاتصالات نيابة عن تطبيقك، مما يحسن قابلية التوسع ويقلل الضغط على قاعدة البيانات ويُسرّع التعافي من الفشل — دون أي تعديل في كود التطبيق.

📋 ميزات Amazon RDS Proxy الأساسية

• تجميع الاتصالات (Connection Pooling): يحتفظ بمجموعة اتصالات جاهزة ويُعيد استخدامها بين طلبات التطبيق، مما يقلل استهلاك وحدة المعالجة المركزية والذاكرة في قاعدة البيانات بشكل كبير.
• تقليل زمن الفشل بنسبة 66%: يُسرّع التعافي من الفشل (Failover) لقواعد Aurora وRDS Multi-AZ — يقلل زمن الانقطاع من دقائق إلى ثوانٍ.
• توثيق IAM وتخزين الأسرار: يفرض توثيق الهوية عبر IAM ويُخزن بيانات الاعتماد في AWS Secrets Manager، مما يلغي الحاجة لتضمين كلمات المرور في كود التطبيق.
• الحماية من طفرات الاتصالات (Thundering Herd): يمتص الزيادة المفاجئة في طلبات الاتصال ويُمررها تدريجياً إلى قاعدة البيانات، مما يمنع تعطلها عند ارتفاع الحمل المفاجئ.
• بدون خادم وتلقائي التوسع: لا حاجة لإدارة السعة — يتوسع تلقائياً مع تغير حجم الطلبات دون أي تكوين مسبق.

متجر إلكتروني أثناء حدث تخفيضات الجمعة البيضاء (Black Friday).
فجأة، 100,000 مستخدم يفتحون التطبيق في نفس الثانية — كل منهم يحتاج اتصالاً بقاعدة بيانات RDS لعرض المنتجات وإضافتها للسلة.
بدون RDS Proxy: كل مستخدم يفتح اتصالاً جديداً مباشرةً إلى RDS — القاعدة تُغرق بـ 100,000 اتصال دفعة واحدة، تستهلك كل الذاكرة، وتتعطل.
مع RDS Proxy: الوكيل يمتص الطلبات ويُدير 200 اتصال فقط مُعاد استخدامها بكفاءة — جميع المستخدمين يخدمون بسلاسة والقاعدة مستقرة.
النتيجة: مبيعات بقيمة 2 مليون ريال دون أي تعطل ودون الحاجة لمثيل RDS أضخم.

✅ خلاصة Amazon RDS Proxy:

• طبقة وسيطة مُدارة بالكامل بين التطبيق وقاعدة البيانات لتجميع الاتصالات ومشاركتها.
• يُقلل زمن التعافي من الفشل بنسبة تصل إلى 66% لقواعد Aurora وRDS Multi-AZ.
• يفرض توثيق IAM ويدير بيانات الاعتماد عبر Secrets Manager — أمان محسن للتطبيق.
• يحمي قاعدة البيانات من طفرات الاتصالات المفاجئة (Thundering Herd Problem).
• بدون خادم، يتوسع تلقائياً دون إدارة للسعة — مثالي لتطبيقات الإنتاج.

Amazon RDS Proxy مثل موظف الاستقبال في فندق كبير.
بدلاً من أن يدخل 500 نزيل دفعة واحدة إلى مكتب المدير (قاعدة البيانات) ويُربكوا العمل، يقف موظف الاستقبال (RDS Proxy) أمام الباب ويُدير الحوار معهم واحداً تلو الآخر بمكتبه الخاص، ثم يُمرر فقط الطلبات المُعالجة إلى المدير بتدفق منتظم — الجميع يحصل على خدمة سريعة والمكتب الخلفي يبقى منظماً.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
RDS Proxy	وسيط RDS	طبقة وسيطة مُدارة تجمع اتصالات قاعدة البيانات وتُحسن التوسع والتعافي من الفشل.
Connection Pooling	تجميع الاتصالات	إعادة استخدام مجموعة اتصالات جاهزة بدلاً من فتح اتصال جديد لكل طلب.
Failover	التعافي من الفشل	التحويل التلقائي إلى مثيل قاعدة بيانات احتياطي عند تعطل الأساسي.
Thundering Herd	مشكلة القطيع الهادر	تدفق مفاجئ لآلاف الاتصالات دفعة واحدة قد يعطل قاعدة البيانات.
Secrets Manager	مدير الأسرار	خدمة AWS لتخزين وإدارة بيانات الاعتماد الحساسة بشكل آمن مع التدوير التلقائي.

1️⃣ Amazon Aurora — Next-Gen Database Engine — محرك قواعد الجيل التالي

📖 Amazon Aurora محرك قواعد بيانات علائقية طورته AWS ليجمع بين أداء القواعد التجارية وبساطة وانفتاح القواعد مفتوحة المصدر.
متوافقة مع MySQL وPostgreSQL لكنها أسرع بخمس مرات وأقل تكلفة بعُشر السعر، مع تخزين موزع ذاتي الإصلاح يصل إلى 128 تيرابايت.

📋 لماذا Aurora مختلفة؟

• التخزين موزع تلقائياً عبر 3 مناطق توفر: كل كتلة بيانات تُنسخ 6 مرات على الأقل عبر AZs مختلفة.
• الإصلاح الذاتي: إذا اكتشفت تلفاً في بيانات أو قرصاً معطوباً، تصلح Aurora البيانات تلقائياً من النسخ الأخرى.
• فصل الحوسبة عن التخزين: طبقة التخزين مستقلة وتتوسع تلقائياً حتى 128 تيرابايت دون توقف.
• نسخ Aurora المتماثلة (حتى 15 نسخة): أسرع من Read Replicas العادية مع زمن تأخير أقل من 10–20 ميلي ثانية.
• نقطة نهاية للقارئ (Reader Endpoint): توازن حمل القراءة تلقائياً بين جميع النسخ المتماثلة دون منطق إضافي في التطبيق.

شركة ألعاب عالمية تنتقل من MySQL على RDS إلى Aurora.
زمن تنفيذ الاستعلامات ينخفض بنسبة 40% بفضل التخزين المُحسّن.
أثناء حدث Black Friday، يتضاعف عدد اللاعبين 10 مرات — Aurora تتوسع تلقائياً وتضيف نسخاً متماثلة خلال دقائق.
بعد الحدث، تتراجع السعة تلقائياً — التكلفة تنخفض مع انخفاض الحمل.
النتيجة: أداء ممتاز طوال الحدث دون تدخل يدوي وبتكلفة أقل بـ 30% من RDS التقليدية.

2️⃣ Aurora Serverless v2 — أورورا بدون خادم

📖 Aurora Serverless v2 تتيح تشغيل Aurora بدون إدارة السعة — تتوسع تلقائياً صعوداً وهبوطاً بالثواني بناءً على الحمل الفعلي.
مثالية لأحمال العمل المتقطعة أو المتغيرة أو التي لا يمكن التنبؤ بها حيث لا تريد الدفع مقابل سعة خاملة.

📋 Aurora Serverless v2

• الحد الأدنى من وحدات Aurora Capacity Units (ACU): تبدأ من 0.5 ACU فقط (حوالي 1 جيجابايت ذاكرة).
• التوسع فوري بالثواني وليس بالدقائق: مثالي لتطبيقات SaaS متعددة المستأجرين.
• تدفع فقط مقابل السعة المستخدمة فعلياً: تخفيض تكلفة يصل إلى 90% لأحمال العمل الخاملة معظم الوقت.
• تدعم كلاً من MySQL وPostgreSQL: نفس التوافق مع الميزات الكاملة.

تطبيق محاسبي يُستخدم فقط في نهاية كل شهر.
خلال 29 يوماً، التطبيق خامل تماماً — Aurora Serverless تنخفض إلى 0.5 ACU (أقل تكلفة).
في آخر 3 أيام من الشهر، ينشط 10,000 محاسب فجأة — Aurora تتوسع تلقائياً إلى 50 ACU.
في اليوم الأول من الشهر الجديد، تعود إلى 0.5 ACU.
مقارنة بمثيل RDS ثابت كبير: التوفير يصل إلى 85% شهرياً.

✅ خلاصة Amazon Aurora:

• محرك قواعد بيانات متوافق مع MySQL/PostgreSQL، أسرع بـ 5x وأقل تكلفة بـ 1/10.
• تخزين موزع ذاتي الإصلاح عبر 3 AZs مع 6 نسخ لكل كتلة بيانات.
• Aurora Serverless v2 للتوسع التلقائي بالثواني ودفع مقابل الاستخدام فقط.
• نقطة نهاية القارئ لتوزيع حمل القراءة تلقائياً.
• مثالية لأحمال العمل عالية الأداء والمتغيرة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Aurora Cluster	مجموعة Aurora	مثيل أساسي + نسخ متماثلة مع تخزين موزع عبر 3 AZs.
Aurora Serverless	Aurora بدون خادم	تتوسع تلقائياً بالثواني وتدفع مقابل الاستخدام فقط.
Reader Endpoint	نقطة نهاية القارئ	توازن حمل القراءة تلقائياً بين النسخ المتماثلة.
Backtrack	التراجع الزمني	استعادة قاعدة البيانات إلى نقطة زمنية سابقة خلال ثوان.
Aurora Global DB	قاعدة Aurora العالمية	نسخ عبر المناطق بزمن تأخير أقل من ثانية للتعافي من الكوارث.

1️⃣ DynamoDB Core Components — مكونات DynamoDB الأساسية

📖 Amazon DynamoDB هي قاعدة بيانات NoSQL مُدارة بالكامل تقدم أداءً ثابتاً بمستوى أجزاء من الثانية في أي نطاق.
بلا خوادم (serverless): لا حاجة لإدارة أو تصحيح أو نسخ احتياطي — تدفع فقط مقابل ما تستخدمه مع إمكانية التوسع إلى ملايين الطلبات في الثانية.

📋 مكونات DynamoDB الأساسية

• الجدول: مجموعة من العناصر (items) — لا يوجد مخطط ثابت، كل عنصر يمكن أن يكون له خصائص مختلفة.
• العنصر (item): يمثل صفاً واحداً بمفتاح أساسي فريد ومجموعة سمات اختيارية.
• السمة (attribute): زوج مفتاح-قيمة — السمة نفسها يمكن أن تكون نصاً أو رقماً أو قائمة أو كائناً JSON متداخلاً.
• المفتاح الأساسي: مفتاح قسمة (partition key) فقط، أو مفتاح قسمة + مفتاح فرز (sort key) للاستعلامات المرتبة.

متجر إلكتروني يخزن بيانات عربات التسوق في DynamoDB.
مفتاح القسمة: CustomerID — يضمن توزيع البيانات بالتساوي بين أقسام التخزين.
مفتاح الفرز: ProductID — يسمح باستعلام جميع منتجات العميل مرتبة أبجدياً.
عند إضافة منتج للعربة: عملية كتابة واحدة في أقل من 10 ميلي ثانية.
عند عرض العربة: استعلام واحد يسترجع جميع المنتجات خلال 15 ميلي ثانية.
حتى مع مليون عربة تسوق متزامنة، الأداء يبقى ثابتاً.

📊 المؤشرات الثانوية (GSI وLSI)

📖 تدعم DynamoDB نوعين من المؤشرات الثانوية لتوسيع خيارات الاستعلام: المؤشر الثانوي العالمي (GSI) والمؤشر الثانوي المحلي (LSI).
المؤشرات الثانوية تتيح لك الاستعلام عن البيانات بطرق مختلفة عن المفتاح الأساسي للجدول، مما يمنحك مرونة إضافية دون الحاجة لإنشاء جداول منفصلة.

📋 الفرق بين GSI وLSI

• Global Secondary Index (GSI): يمتلك مفتاح قسمة (Partition Key) ومفتاح فرز (Sort Key) اختياري مختلفين تماماً عن مفاتيح الجدول الأساسي. يمكنك إنشاؤه أو حذفه في أي وقت — حتى بعد إنشاء الجدول. يدعم التناسق النهائي (Eventual Consistency) والتناسق القوي (Strong Consistency).
• Local Secondary Index (LSI): يمتلك نفس مفتاح القسمة للجدول الأساسي ولكن مفتاح فرز مختلف. يجب إنشاؤه مع الجدول الأساسي عند الإنشاء — لا يمكن إضافته لاحقاً. يقتصر على 10 جيجابايت لكل قيمة مفتاح قسمة. يدعم التناسق القوي فقط.
• الـ GSI مثالي عندما تحتاج استعلامات بمعايير مختلفة كلياً عن المفتاح الأساسي — مثلاً الاستعلام عن الموظفين حسب القسم بدلاً من رقم الموظف.
• الـ LSI مثالي عندما تحتاج ترتيباً مختلفاً للبيانات ضمن نفس مفتاح القسمة — مثلاً عرض طلبات العميل مرتبة حسب التاريخ أو حسب القيمة.

متجر إلكتروني يستخدم DynamoDB لجدول الطلبات (Orders).
المفتاح الأساسي: CustomerID (قسمة) + OrderID (فرز) — يستعلم عن جميع طلبات العميل مرتبة حسب رقم الطلب.
GSI: ProductID (قسمة) + OrderDate (فرز) — يستعلم عن جميع الطلبات التي تحتوي منتجاً معيناً — مفيد لدعم العملاء لمعرفة من اشترى منتجاً معيباً.
LSI: CustomerID (قسمة) + OrderTotal (فرز) — يستعلم عن طلبات العميل مرتبة حسب القيمة — مفيد لبرنامج الولاء "أفضل 5 عملاء إنفاقاً".
كل مؤشر يخدم غرضاً مختلفاً دون الحاجة لإنشاء جداول منفصلة أو نسخ البيانات يدوياً.

📡 DynamoDB Streams — تدفق الأحداث في الزمن الحقيقي

📖 DynamoDB Streams تلتقط سجلاً زمنياً مرتباً لجميع التعديلات على مستوى العنصر (إنشاء، تحديث، حذف) في الجدول بشكل شبه فوري.
هذه الميزة تحول DynamoDB من مجرد مخزن بيانات إلى مصدر أحداث قوي يُمكّن المعماريات المبنية على الأحداث (Event-Driven Architectures).

📋 قدرات DynamoDB Streams

• تلتقط كل تغيير على مستوى العنصر: تُسجل الصورة القديمة (Old Image) والصورة الجديدة (New Image) للعنصر قبل وبعد التعديل.
• الترتيب الزمني مضمون: الأحداث تُخزن بالترتيب الذي حدثت به بالضبط داخل كل قسم (Partition).
• تشغيل دوال Lambda تلقائياً: عند حدوث تغيير في الجدول، تُشغّل AWS Lambda تلقائياً لمعالجة الحدث — مثالية للإشعارات والمزامنة والتدقيق.
• النسخ عبر المناطق: DynamoDB Global Tables تعتمد على Streams لنشر البيانات بين المناطق المختلفة تلقائياً.
• الاحتفاظ لمدة 24 ساعة: البيانات تبقى متاحة للمعالجة لمدة يوم كامل قبل الحذف التلقائي.

تطبيق توصيل طعام يستخدم DynamoDB Streams لتنسيق عملية الطلب بالكامل.
1️⃣ العميل يُنشئ طلباً جديداً — يُكتب العنصر إلى جدول Orders في DynamoDB.
2️⃣ DynamoDB Streams تلتقط الحدث فوراً وتُشغّل دالة Lambda.
3️⃣ Lambda ترسل إشعاراً إلى المطعم عبر SNS، وتُحدث لوحة التتبع للعميل، وتكتب سجل التدقيق في S3.
4️⃣ عند تغيير حالة الطلب إلى "قيد التوصيل"، تلتقط Streams الحدث مجدداً وتُشغّل Lambda أخرى لتحديث موقع السائق على الخريطة وإرسال إشعار للعميل.
النتيجة: نظام أحداث لامركزي بالكامل — كل خدمة تتفاعل مع التغييرات التي تهمها فقط دون اقتران مباشر بين المكونات.

2️⃣ Capacity Modes: On-Demand vs Provisioned — نماذج السعة: عند الطلب مقابل المُجهزة

📖 DynamoDB تقدم نموذجين لإدارة السعة: عند الطلب (On-Demand) للدفع مقابل كل طلب، والمُجهزة (Provisioned) مع مقياس تلقائي لتوفير التكلفة.
اختيار النموذج المناسب يعتمد على نمط استخدام تطبيقك وإمكانية التنبؤ بحجم الطلبات.

📋 مقارنة النموذجين

• عند الطلب (On-Demand): لا حاجة لتخطيط السعة — تدفع مقابل كل قراءة وكتابة، مثالي لأحمال العمل الجديدة أو المتغيرة أو غير المتوقعة.
• المُجهزة (Provisioned): تحدد عدد وحدات القراءة (RCU) والكتابة (WCU) مسبقاً بتكلفة أقل تصل إلى 70% عند الاستخدام المتوقع.
• المقياس التلقائي (Auto Scaling): يضبط السعة المُجهزة تلقائياً حسب الطلب الفعلي مع حد أقصى تحدده.
• التبديل بين النموذجين ممكن في أي وقت ولكل جدول.

3️⃣ DAX and Global Tables — DAX والجداول العالمية

📖 مسرّع DynamoDB (DAX) يضيف طبقة تخزين مؤقت في الذاكرة أمام DynamoDB تقلل زمن القراءة من ميلي ثانية إلى ميكروثانية.
لا حاجة لتعديل كود التطبيق — DAX متوافق تماماً مع واجهة DynamoDB API ويستجيب في أقل من 10 ميكروثانية.

📋 الجداول العالمية (Global Tables)

• تنسخ بيانات DynamoDB تلقائياً عبر مناطق AWS المتعددة.
• القراءة والكتابة من أي منطقة مع حل النزاعات آلياً (last writer wins).
• مثالية للتطبيقات العالمية التي تحتاج وصولاً سريعاً للبيانات محلياً في كل منطقة.
• التعافي من الكوارث: إذا تعطلت منطقة كاملة، التطبيق يواصل العمل من المناطق الأخرى.

تطبيق حجز طيران عالمي يستخدم Global Tables.
بيانات الرحلات والمقاعد تُنسخ تلقائياً بين أمريكا وأوروبا وآسيا.
مسافر في طوكيو يحجز مقعداً — الكتابة تتم في DynamoDB في طوكيو خلال 12ms وتُنسخ تلقائياً إلى بقية المناطق.
بعد ثانية واحدة، مسافر في لندن يستعرض نفس الرحلة ويرى المقعد محجوزاً بفضل المزامنة شبه الفورية.
لا يوجد تضارب في الحجوزات حتى مع ملايين المستخدمين المتزامنين.

🔑 نصيحة أساسية: DynamoDB مقابل RDS
استخدم DynamoDB عندما تحتاج سرعة فائقة (ميلي ثانية) ومرونة في المخطط وتوسعاً تلقائياً — التطبيقات الحديثة بدون خادم، جلسات المستخدمين، بيانات IoT.
استخدم RDS عندما تحتاج علاقات معقدة بين الجداول (JOIN) واستعلامات SQL تقليدية ومخطط بيانات منظم ومحدد مسبقاً — أنظمة ERP وCRM والبنوك.

✅ خلاصة: Amazon DynamoDB

• قاعدة NoSQL مُدارة بالكامل بدون خوادم — أداء ثابت بمستوى ميلي ثانية على أي نطاق.
• المكونات الأساسية: الجدول، العنصر (item)، السمة (attribute)، والمفتاح الأساسي (partition key + sort key اختياري).
• المؤشرات الثانوية: GSI (مفاتيح مختلفة عن الأساسي، يُنشأ في أي وقت) وLSI (نفس مفتاح القسمة، يُنشأ عند إنشاء الجدول فقط).
• DynamoDB Streams تلتقط التغييرات وتُشغّل Lambda تلقائياً — أساس البنى المبنية على الأحداث.
• نموذجان للسعة: On-Demand (للأحمال غير المتوقعة) وProvisioned مع Auto Scaling (للأحمال المتوقعة بتكلفة أقل).
• DAX للتخزين المؤقت (زمن استجابة بالميكروثانية) وGlobal Tables للنسخ العالمي التلقائي.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Partition Key	مفتاح القسمة	يوزع البيانات تلقائياً بين أقسام التخزين لأداء متسق.
Sort Key	مفتاح الفرز	ينظم العناصر داخل القسم الواحد للاستعلامات المرتبة.
RCU/WCU	وحدة القراءة/الكتابة	وحدة قياس سعة DynamoDB للقراءة والكتابة في الثانية.
DAX	مسرع DynamoDB	طبقة تخزين مؤقت تقلل زمن القراءة إلى ميكروثانية.
Global Tables	الجداول العالمية	نسخ تلقائي للبيانات عبر مناطق AWS المتعددة.
TTL	مدة حياة العنصر	حذف تلقائي للعناصر بعد فترة زمنية محددة.

1️⃣ In-Memory Caching — التخزين المؤقت في الذاكرة

📖 Amazon ElastiCache خدمة تخزين مؤقت في الذاكرة مُدارة بالكامل تدعم Redis وMemcached لتسريع التطبيقات عبر تخزين البيانات الأكثر طلباً في ذاكرة RAM.
تقلل زمن استجابة التطبيق من ملي ثانية إلى ميكروثانية وتخفف الضغط عن قواعد البيانات الخلفية بتكلفة منخفضة.

📋 Redis مقابل Memcached

• Redis: يدعم هياكل بيانات غنية (قوائم، مجموعات، مجموعات مرتبة، خرائط Hash)، النسخ المتعدد AZ، الثبات (persistence)، والنشر والاشتراك (pub/sub). مثالي لجلسات المستخدمين ولوحات المتصدرين وتخزين التصويت.
• Memcached: أبسط وأسرع، يدعم فقط أزواج مفتاح-قيمة، متعدد الخيوط، يتوسع أفقياً بسهولة. مثالي لتخزين نتائج استعلامات قواعد البيانات مؤقتاً.
• Redis يقدم ميزات متقدمة مثل التشفير والتوثيق والمجموعات المقسمة (clustering).
• Memcached مثالي لأحمال العمل البسيطة التي لا تحتاج ميزات متقدمة.

موقع إخباري كبير يستخدم ElastiCache لتقليل الحمل عن RDS.
عند نشر خبر جديد، يُكتب إلى RDS (مصدر الحقيقة).
عند طلب زائر للخبر، يفحص التطبيق ElastiCache أولاً — 95% من الطلبات تجد الخبر مخزناً مؤقتاً وتستجيب في 0.5ms.
فقط 5% من الطلبات (الزيارات الأولى للخبر) تذهب إلى RDS وتستجيب في 50ms.
النتيجة: تحسين سرعة الموقع بـ 100 ضعف وتقليل تكلفة RDS إلى الثلث لأن المثيل أصغر بكثير.

2️⃣ Amazon Redshift — Data Warehouse — مستودع البيانات التحليلي

📖 Amazon Redshift هو مستودع بيانات مُدار بالكامل لتحليل البيانات الضخمة باستعلامات SQL على نطاق بيتابايت.
أسرع بثلاث مرات وأقل تكلفة بخمس مرات من مستودعات البيانات التقليدية بفضل التخزين العمودي وضغط البيانات وتنفيذ الاستعلامات المتوازي.

📋 ميزات Redshift الأساسية

• التخزين العمودي (columnar storage): البيانات تُخزن بالأعمدة وليس بالصفوف — مثالي للاستعلامات التحليلية التي تمسح أعمدة محددة.
• المعالجة المتوازية (MPP): يوزع الاستعلامات تلقائياً عبر عدة عُقد للحوسبة المتوازية.
• تكامل مع S3 عبر Redshift Spectrum: استعلام عن البيانات المخزنة مباشرة في S3 دون تحميلها إلى Redshift.
• النسخ الاحتياطي التلقائي إلى S3: مستمر وتزايدي مع إمكانية الاستعادة لأي نقطة.
• يدعم التشفير في السكون والنقل ويتكامل مع AWS KMS.

سلسلة متاجر تجزئة بـ 500 فرع تستخدم Redshift لتحليل المبيعات.
كل ليلة، بيانات 10 ملايين معاملة مبيعات تُحمل من قواعد الفروع إلى Redshift.
صباحاً، مدير التسويق يستعلم: "ما أكثر 5 منتجات مبيعاً في الفروع الساحلية آخر 3 أشهر؟"
Redshift يمسح تيرابايت من البيانات ويعيد النتيجة في 3 ثوانٍ — نفس الاستعلام على RDS يستغرق 12 دقيقة.
النتيجة: قرارات تسويقية أسرع ومبنية على بيانات دقيقة.

3️⃣ Amazon DocumentDB — قاعدة بيانات وثائقية متوافقة مع MongoDB

📖 Amazon DocumentDB هي قاعدة بيانات وثائقية (Document Database) مُدارة بالكامل ومتوافقة مع MongoDB — مصممة لتخزين واستعلام بيانات JSON بمرونة.
مثالية للتطبيقات التي تحتاج مخططاً مرناً (flexible schema) وبيانات شبه منظمة تختلف سماتها من سجل لآخر.

📋 مواصفات Amazon DocumentDB

• أنسب أحمال العمل: التطبيقات التي تحتاج مخططاً مرناً للتطوير السريع والتكراري، وتخزين بيانات بسمات وقيم مختلفة لكل سجل.
• نموذج البيانات: وثائقي (Document) — يُخزّن البيانات بتنسيق JSON مع استعلام على أي سمة، وتداخل الحقول والفهارس والتجميعات.
• الميزات: قاعدة بيانات JSON متوافقة مع MongoDB، مُدارة بالكامل، مناسبة للمستندات المعقدة والديناميكية التي تتطلب استعلامات وفهارس وتجميعات لمرة واحدة.
• حالات الاستخدام: أنظمة إدارة المحتوى (CMS)، ملفات العملاء الشخصية، تخزين وإدارة البيانات التشغيلية من أي مصدر.

🔑 نصيحة أساسية: Amazon DocumentDB متوافقة مع تطبيقات MongoDB الموجودة — يمكنك استخدام نفس التطبيقات والأدوات والسواقات (drivers) التي تستخدمها مع MongoDB مفتوح المصدر. كما تتكامل مع AWS DMS لترحيل قواعد MongoDB إلى DocumentDB دون توقف تقريباً.

منصة تجارة إلكترونية تختار DocumentDB لتخزين كتالوج المنتجات.
كل منتج له سمات مختلفة: الهاتف له معالج وشاشة، والملابس لها مقاس ولون وخامة.
في قاعدة علائقية، ستحتاج جدول منتجات + جداول سمات منفصلة + JOINs معقدة.
في DocumentDB، كل منتج يُخزّن كوثيقة JSON بسماته الخاصة — لا جداول منفصلة، ولا JOINs، ولا مخطط ثابت.
استعلام واحد: db.products.find({category: "electronics", price: {$lt: 500}}) — يعيد جميع المنتجات الإلكترونية تحت 500 في أقل من 10 ميلي ثانية.

4️⃣ Amazon Keyspaces — قاعدة بيانات واسعة الأعمدة متوافقة مع Apache Cassandra

📖 Amazon Keyspaces هي خدمة قواعد بيانات واسعة الأعمدة (Wide-Column Database) مُدارة بالكامل ومتوافقة مع Apache Cassandra — مصممة لأحمال العمل عالية الإنتاجية والكتابة المكثفة.
تمتد القاعدة عبر أنظمة قواعد بيانات موزعة مع أداء ثابت حتى على أحمال الكتابة الثقيلة.

📋 مواصفات Amazon Keyspaces

• أنسب أحمال العمل: استعلام سريع عن كميات ضخمة من البيانات، أحمال كتابة عالية أو قراءة/كتابة متوازنة، قابلية توسع وأداء ثابت.
• نموذج البيانات: عمودي عريض (Wide Column) — يُخزّن البيانات في أعمدة مرنة تتطور مع الوقت، مع توزيع عبر أنظمة قواعد بيانات موزعة.
• الميزات: خدمة قواعد بيانات مُدارة بالكامل متوافقة مع Cassandra، قابلة للتوسع، وذات توفر عالٍ — تدعم لغة الاستعلام Cassandra Query Language (CQL).
• حالات الاستخدام: صيانة المعدات الصناعية، مراقبة التداول المالي، تحسين المسارات اللوجستية — أي تطبيق يحتاج زمن استجابة بالميلي ثانية لكميات ضخمة من البيانات.

🔑 نصيحة أساسية: على عكس قواعد المفتاح-قيمة (key-value) التي تعمل بشكل أفضل لأحمال القراءة الثقيلة، فإن قواعد الأعمدة العريضة تتفوق عندما تكون القراءة والكتابة متوازنة أو للكتابة المكثفة. Keyspaces مثالية لتطبيقات إنترنت الأشياء (IoT) التي تولد ملايين نقاط البيانات كل ثانية.

شركة لوجستية تدير 10,000 شاحنة مزودة بأجهزة استشعار IoT.
كل شاحنة ترسل 100 نقطة بيانات في الثانية (الموقع، السرعة، درجة الحرارة، استهلاك الوقود).
Keyspaces تستقبل مليون عملية كتابة في الثانية وتخزنها في أعمدة مرنة — كل شاحنة لها عمود خاص ببياناتها.
الاستعلام: "ما متوسط استهلاك وقود الشاحنات في الرياض آخر ساعة؟" — يعيد النتيجة خلال 15 ميلي ثانية.
قاعدة علائقية كانت ستنهار تحت هذا الحجم من الكتابات المتزامنة.

5️⃣ Amazon MemoryDB for Redis — قاعدة بيانات داخل الذاكرة متوافقة مع Redis

📖 Amazon MemoryDB for Redis هي قاعدة بيانات مُدارة بالكامل داخل الذاكرة (In-Memory Database) متوافقة مع Redis — تجمع بين سرعة الذاكرة ومتانة البيانات من خلال سجل معاملات موزع.
يمكنك استخدامها كقاعدة بيانات أساسية (primary database) للتطبيقات فائقة الأداء دون الحاجة لإدارة ذاكرة تخزين مؤقت منفصلة.

📋 مواصفات Amazon MemoryDB

• أنسب أحمال العمل: تطبيقات حساسة لزمن الاستجابة، معدلات طلبات عالية جداً (مئات الملايين من الطلبات في الثانية)، إنتاجية بيانات عالية (جيجابايت/ثانية للقراءة)، عدم فقدان بيانات.
• نموذج البيانات: داخل الذاكرة (In-Memory) — يعتمد بشكل أساسي على الذاكرة لتخزين البيانات، مما يلغي الحاجة للوصول إلى الأقراص ويقلص زمن الاستجابة بشكل كبير.
• الميزات: يخزن مجموعة البيانات بالكامل في الذاكرة ويستخدم سجل معاملات موزع (distributed transactional log) لتوفير سرعة الذاكرة مع متانة البيانات واتساقها وقابليتها للاسترداد. متوافق مع Redis مفتوح المصدر — نفس أنواع البيانات والأوامر والأدوات.
• حالات الاستخدام: ملفات العملاء في التجزئة، لوحات المتصدرين في الألعاب، معاملات المستخدمين في البنوك.

🔑 الفرق بين ElastiCache وMemoryDB: ElastiCache هو تخزين مؤقت (Cache) — إذا تعطل، يمكن إعادة بناء البيانات من قاعدة البيانات الأساسية. MemoryDB قاعدة بيانات أساسية (Primary Database) — بياناتك آمنة ومتينة حتى عند إعادة التشغيل. اختر MemoryDB عندما تحتاج سرعة الذاكرة مع ضمان عدم فقدان البيانات.

منصة ألعاب إلكترونية تضم 50 مليون مستخدم نشط شهرياً.
تحتاج لوحة متصدرين فورية (live leaderboard) تُحدّث في الوقت الحقيقي.
MemoryDB تخزن درجات اللاعبين في Redis Sorted Sets — تحديث النتيجة وتحديد الترتيب يتم في أقل من ميلي ثانية.
حتى مع 5 ملايين لاعب يلعبون في نفس الوقت، MemoryDB تعالج 200,000 طلب في الثانية بزمن استجابة 0.5ms.
في حال تعطلت الخدمة، سجل المعاملات الموزع يعيد بناء البيانات كاملة دون فقدان أي نقطة.

6️⃣ Amazon Neptune — قاعدة بيانات رسم بياني (Graph Database)

📖 Amazon Neptune هي قاعدة بيانات رسم بياني (Graph Database) مُدارة بالكامل وعالية الأداء — مصممة لتخزين واستعلام البيانات شديدة الاتصال (highly connected data).
في قواعد الرسم البياني، العلاقات بين البيانات لا تقل أهمية عن البيانات نفسها — عكس القواعد العلائقية حيث العلاقات مستنتجة عبر JOINs.

📋 مواصفات Amazon Neptune

• أنسب أحمال العمل: إيجاد الاتصالات والمسارات في البيانات، دمج بيانات ذات علاقات معقدة عبر صوامع بيانات مختلفة، التنقل في مجموعات بيانات شديدة الاتصال وتصفية النتائج بناءً على متغيرات محددة.
• نموذج البيانات: رسم بياني (Graph) — يخزن البيانات والعلاقات بينها كعناصر متساوية الأهمية. يتكون من عقد (Nodes) تمثل الكيانات وحواف (Edges) تمثل العلاقات بينها.
• الميزات: محرك قواعد بيانات رسم بياني عالي الأداء، يدعم لغات استعلام متعددة: Apache TinkerPop Gremlin وW3C SPARQL وopenCypher. يستخدم معمارية محسّنة للذاكرة للاستعلام السريع على الرسوم البيانية الكبيرة.
• حالات الاستخدام: محركات التوصية، كشف الاحتيال، الرسوم البيانية المعرفية (Knowledge Graphs)، اكتشاف الأدوية، شبكات التواصل الاجتماعي.

تطبيق تواصل اجتماعي يريد تقديم ميزة "أصدقاء مقترحين".
في قاعدة علائقية: استعلام JOIN معقد بين 4 جداول (مستخدمين، أصدقاء، إعجابات، مجموعات) — يستغرق 30 ثانية ويعيد 5 اقتراحات غير دقيقة.
في Neptune: استعلام Gremlin واحد: g.V('user123').repeat(out('friends')).times(2).dedup() — يعيد أصدقاء الأصدقاء خلال 200ms.
Neptune تتتبع كل علاقة (صداقة، إعجاب، متابعة) كحافة (Edge) مستقلة — الاستعلام عن العلاقات أسرع بـ 100 مرة من SQL.
النتيجة: اقتراحات دقيقة في 200ms بدلاً من 30 ثانية.

7️⃣ Amazon Timestream — قاعدة بيانات سلاسل زمنية (Time Series)

📖 Amazon Timestream هي قاعدة بيانات سلاسل زمنية (Time Series Database) مُدارة بالكامل ولا تحتاج خوادم (serverless) — مصممة لتحليل البيانات المتغيرة مع الزمن.
أسرع بـ 1,000 مرة وأرخص بـ 90% من قواعد البيانات التقليدية للبيانات الزمنية، مع طبقات تخزين ذكية تنقل البيانات الساخنة إلى الباردة تلقائياً.

📋 مواصفات Amazon Timestream

• أنسب أحمال العمل: تحديد الأنماط والاتجاهات مع الزمن، قياس القيمة أو الأداء عبر الزمن، معالجة وتحليلات بيانات فعالة، سهولة إدارة البيانات.
• نموذج البيانات: سلاسل زمنية (Time Series) — سلسلة من نقاط البيانات المسجلة عبر فاصل زمني لقياس الأحداث التي تتغير مع الوقت. يوفر القدرة على جمع وتخزين ومعالجة البيانات مرتبة زمنياً.
• الميزات: قاعدة بيانات serverless تبسط الوصول للبيانات وتوفر طريقة متينة وآمنة لاستخلاص الرؤى من البيانات الزمنية. يحتوي محرك الاستعلام على دوال زمنية مدمجة (smoothing, approximation, interpolation) وتحليل SQL متقدم مع دوال نافذة (window functions).
• حالات الاستخدام: تحديد الاتجاهات من بيانات تطبيقات إنترنت الأشياء (IoT)، تحسين الأداء بتحليل حركة مرور الويب في الوقت الفعلي.

محطة أرصاد جوية ترسل 1,000 قراءة في الثانية (درجة الحرارة، الرطوبة، الضغط، سرعة الرياح).
بعد عام، تتراكم 31 مليار نقطة بيانات.
في قاعدة تقليدية، الاستعلام عن "متوسط درجة الحرارة في يوليو" يمسح 31 مليار صف — يستغرق 45 دقيقة ويكلف آلاف الدولارات.
في Timestream: الاستعلام SELECT AVG(temperature) FROM weather WHERE time BETWEEN '2025-07-01' AND '2025-07-31' — يعيد النتيجة في 3 ثوانٍ.
Timestream تنقل تلقائياً البيانات الأقدم من 30 يوماً إلى طبقة تخزين باردة أرخص بـ 10 مرات — البيانات الساخنة تبقى في الذاكرة للاستعلام السريع.

8️⃣ Amazon QLDB (Quantum Ledger Database) — سجل حسابات ثابت وشفاف

📖 Amazon QLDB هي قاعدة بيانات سجل حسابات (Ledger Database) مُدارة بالكامل — توفر سجلاً ثابتاً (immutable) وشفافاً وقابلاً للتحقق تشفيرياً لجميع التغييرات على بيانات التطبيق.
على عكس blockchain، QLDB مركزية ولا تحتاج إجماع (consensus) بين أطراف متعددة — مما يجعلها أسرع وآلاف المرات أرخص لحالات الاستخدام التي تحتاج سجلاً موثوقاً ضمن مؤسسة واحدة.

📋 مواصفات Amazon QLDB

• أنسب أحمال العمل: الحفاظ على تاريخ دقيق لبيانات التطبيق، تتبع تاريخ المعاملات المالية، التحقق من نسب البيانات (data lineage) للمطالبات وسلاسل التوريد.
• نموذج البيانات: سجل حسابات (Ledger) — يوفر تاريخاً ثابتاً وغير قابل للتغيير وقابلاً للتحقق من جميع التغييرات على بيانات التطبيق.
• الميزات: سجل معاملات شفاف وثابت وقابل للتحقق تشفيرياً، تكامل بيانات مضمون، مخزن أحداث ثابت. كل تغيير يُسجل مع الطابع الزمني والتوقيع التشفيري للتدقيق الكامل.
• حالات الاستخدام: تسجيل جميع المعاملات المالية (ائتمان وخصم)، تتبع تاريخ التصنيع والشحن والتخزين والبيع في سلسلة التوريد، تتبع المطالبات على مدى عمرها مع التحقق التشفيري لسلامة البيانات.

🔑 QLDB مقابل Blockchain: QLDB مركزي — مثالي للمؤسسات التي تحتاج سجلاً ثابتاً وموثوقاً ضمن سيطرتها. Blockchain لامركزي — يحتاج إجماع بين أطراف متعددة لا تثق ببعضها. QLDB أسرع وأرخص بكثير لمعظم حالات استخدام المؤسسات.

شركة تأمين تتعامل مع مليون مطالبة سنوياً.
كل مطالبة تمر بمراحل: تقديم ← مراجعة ← موافقة ← دفع.
في QLDB، كل تغيير في حالة المطالبة يُسجل كإدخال ثابت (immutable entry) مع توقيع تشفيري.
بعد سنتين، يُشتبه في تزوير مطالبة — المدقق يسترجع تاريخ المطالبة بالكامل من QLDB ويتحقق تشفيرياً من أن البيانات لم تُعدّل.
الحساب التشفيري يؤكد أن البيانات أصلية — اكتشاف أن الموظف X غيّر مبلغ التعويض بعد الموافقة دون تصريح.
النتيجة: دليل جنائي رقمي مقبول في المحكمة — تستطيع الشركة مقاضاة المتورطين.

✅ خلاصة ElastiCache وRedshift وPurpose-built Databases:

• ElastiCache (Redis/Memcached) يخزن البيانات الساخنة في الذاكرة لتقليل زمن الاستجابة وحمل قاعدة البيانات.
• Redis للهياكل المعقدة وMemcached للبساطة والسرعة القصوى.
• Redshift مستودع بيانات تحليلي للتخزين العمودي والاستعلامات المتوازية على نطاق بيتابايت.
• Redshift Spectrum للاستعلام المباشر عن بيانات S3 دون تحميل.
• DocumentDB قاعدة وثائقية JSON متوافقة مع MongoDB — مثالية للمحتوى وملفات العملاء والبيانات شبه المنظمة.
• Keyspaces قاعدة أعمدة عريضة متوافقة مع Cassandra — تتفوق في أحمال الكتابة المكثفة والتطبيقات الموزعة.
• MemoryDB قاعدة بيانات داخل الذاكرة متوافقة مع Redis — سرعة الذاكرة مع متانة البيانات كقاعدة أساسية.
• Neptune قاعدة رسم بياني — مثالية للتوصيات وكشف الاحتيال وشبكات التواصل الاجتماعي.
• Timestream قاعدة سلاسل زمنية serverless — أسرع بـ 1,000x وأرخص بـ 90% لبيانات IoT والمراقبة.
• QLDB سجل حسابات ثابت وشفاف وقابل للتحقق التشفيري — مثالي للسجلات المالية وسلاسل التوريد.
• القاعدة الذهبية: اختر قاعدة البيانات المناسبة لحالة الاستخدام — لا تجبر كل شيء في قاعدة علائقية واحدة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Redis Cluster	مجموعة Redis	تقسيم البيانات عبر عقد متعددة لتوسيع السعة والأداء.
Memcached	Memcached	تخزين مؤقت بسيط عالي الأداء لأزواج مفتاح-قيمة.
Columnar Storage	التخزين العمودي	تخزين البيانات بالأعمدة لتحسين أداء الاستعلامات التحليلية.
Redshift Spectrum	Redshift Spectrum	استعلام مباشر عن بيانات S3 دون تحميلها إلى Redshift.
MPP	المعالجة المتوازية	توزيع الاستعلامات عبر عقد متعددة للمعالجة المتزامنة.
DocumentDB	قاعدة بيانات وثائقية	قاعدة JSON متوافقة مع MongoDB للمحتوى والبيانات شبه المنظمة.
Keyspaces	قاعدة أعمدة عريضة	قاعدة متوافقة مع Cassandra لأحمال الكتابة المكثفة والبيانات الموزعة.
MemoryDB	قاعدة بيانات داخل الذاكرة	قاعدة Redis متينة تجمع بين سرعة الذاكرة ومتانة البيانات.
Neptune	قاعدة رسم بياني	قاعدة Graph عالية الأداء للبيانات شديدة الاتصال والعلاقات المعقدة.
Timestream	قاعدة سلاسل زمنية	قاعدة serverless لتحليل البيانات الزمنية من IoT وتطبيقات المراقبة.
QLDB	قاعدة سجل حسابات	سجل ثابت وشفاف وقابل للتحقق تشفيرياً للمعاملات المالية.

1️⃣ Database Security in AWS — أمان قواعد البيانات في AWS

📖 أمان قاعدة البيانات في AWS يشمل أربع طبقات: الشبكة (Security Groups)، الوصول (IAM وكلمات المرور)، التشفير (KMS)، والتدقيق (CloudTrail).
كل طبقة تضيف حاجزاً إضافياً يحمي بياناتك من الاختراق.

📋 طبقات أمان قاعدة البيانات

• طبقة الشبكة: مثيل RDS يوضع في شبكة فرعية خاصة (private subnet) ولا يُعرض للإنترنت مباشرة. مجموعات الأمان تتحكم في المنافذ والمصادر المسموحة.
• طبقة الوصول: المصادقة بكلمة مرور قوية أو عبر IAM (لـ DynamoDB وRDS مع IAM DB Authentication).
• طبقة التشفير: تشفير في السكون باستخدام AWS KMS (شفرة AES-256) وتشفير في النقل عبر SSL/TLS.
• طبقة التدقيق: تفعيل سجلات التدقيق (مثل RDS Enhanced Monitoring وCloudTrail) لتتبع كل عملية وصول أو تغيير.

بنك يطبق أمان قاعدة بياناته على 4 طبقات.
قاعدة RDS في شبكة فرعية خاصة — لا يمكن الوصول إليها من الإنترنت.
فقط خوادم التطبيق في نفس الشبكة يمكنها الاتصال عبر Security Group.
كل البيانات مشفرة بـ AES-256 ومفاتيح KMS تُدار وتدور تلقائياً.
كل محاولة وصول تُسجل وتُرسل إلى نظام SIEM لاكتشاف الأنماط المشبوهة.
النتيجة: 4 حواجز متتالية تجعل اختراق البيانات شبه مستحيل.

2️⃣ Database Migration to AWS — ترحيل قواعد البيانات إلى AWS

📖 خدمة AWS Database Migration Service (DMS) هي خدمة ترحيل ونسخ متماثلة مُدارة بالكامل — تنقل قواعد البيانات من البيئات المحلية أو السحابية إلى AWS بأقل وقت تعطل.
المصدر يبقى قيد التشغيل أثناء الترحيل، وDMS تنسخ البيانات باستمرار حتى تصبح القاعدة الهدف جاهزة للتبديل — مع دعم لأشهر قواعد البيانات التجارية ومفتوحة المصدر.

📋 أنواع الترحيل في AWS DMS

• الترحيل المتجانس (Homogeneous): المصدر والهدف نفس محرك القاعدة (PostgreSQL محلي → RDS PostgreSQL أو Aurora PostgreSQL). DMS يتولى الترحيل تلقائياً وبشكل serverless — لا حاجة لإدارة موارد DMS، فهو يتوسع تلقائياً حسب حجم الترحيل.
• الترحيل غير المتجانس (Heterogeneous): المصدر والهدف محركان مختلفان (Oracle → Aurora PostgreSQL، SQL Server → MySQL). يتطلب أدوات تحويل المخطط مثل SCT أو DMS Schema Conversion لتحويل المخططات والإجراءات المخزنة من لغة إلى أخرى.
• يدعم الترحيل المستمر (ongoing replication): البيانات تُنسخ باستمرار حتى لحظة التبديل النهائي (cutover) — مثالي لتقليل وقت التعطل إلى دقائق.
• الترحيل يمكن أن يكون لمرة واحدة (one-time) أو مستمراً لسيناريوهات التهجين (hybrid) والنسخ المتماثل المستمر.

📋 أدوات الترحيل والتقييم

• AWS DMS Fleet Advisor: أداة اكتشاف تلقائية — تمسح بيئتك المحلية وتُجرد جميع قواعد البيانات والخوادم التحليلية، وتُقيّم مدى جاهزيتها للترحيل إلى AWS. توفر تقارير عن التوافق والتبعيات والمخاطر المحتملة.
• AWS Schema Conversion Tool (SCT): يحول المخططات وقواعد البيانات والإجراءات المخزنة تلقائياً بين المحركات المختلفة — مثلاً PL/SQL (Oracle) إلى PL/pgSQL (PostgreSQL) أو T-SQL (SQL Server) إلى MySQL. يوفر أسابيع من العمل اليدوي.
• AWS DMS Schema Conversion: خدمة مُدارة مركزياً لتحليل المخططات وتحويلها — متوفرة ضمن سير عمل DMS في وحدة التحكم. بديل مُدار لـ SCT السطحي (desktop) مع تكامل أعمق مع DMS.

🔑 حالات استخدام AWS DMS الإضافية: إلى جانب الترحيل بين القواعد، يمكن استخدام DMS لنسخ البيانات من قاعدة بيانات إلى متجر بيانات تحليلي — مثلاً نسخ بيانات من قاعدة معاملات (OLTP) إلى Amazon S3 لبناء بحيرة بيانات (Data Lake). DMS ينسخ البيانات باستمرار إلى S3 بصيغ مثل Parquet وJSON، حيث يمكن تحليلها عبر Athena وRedshift Spectrum وQuickSight.

شركة تأمين تنتقل من Oracle (محلي) إلى Aurora PostgreSQL في AWS.
أولاً: تستخدم Fleet Advisor لمسح 30 خادم قاعدة بيانات محلي — تكتشف 20 قاعدة Oracle و5 SQL Server و3 MySQL، مع تقييم كامل للتوافق.
ثانياً: تستخدم SCT لتحويل 200 إجراء مخزن و50 دالة من PL/SQL إلى PL/pgSQL خلال ساعتين فقط (كان سيستغرق 3 أسابيع يدوياً).
ثالثاً: تشغل DMS لنسخ 2 تيرابايت من البيانات بينما النظام القديم ما زال يعمل — مع التوسع التلقائي serverless.
بعد أسبوع من المزامنة المستمرة والتأكد من صحة البيانات، تخطط لتبديل (cutover) في عطلة نهاية الأسبوع.
يوم الأحد عند 2 صباحاً، توقف التطبيق القديم وتوجهه إلى Aurora في AWS — 4 دقائق فقط من التوقف.
إضافياً: تستخدم DMS لنسخ بيانات المطالبات تاريخياً إلى S3 لتحليلات الذكاء الاصطناعي المستقبلية.

جامعة تستخدم DMS لنسخ بيانات نظام معلومات الطلاب (SIS) من قاعدة Oracle محلية إلى S3.
1. تُنشئ DMS نقطة نهاية مصدر (source endpoint) متصلة بقاعدة SIS.
2. تُنشئ مهمة نسخ متماثل (replication task) لنسخ البيانات من قاعدة SIS التجريبية.
3. تُنشئ DMS نقطة نهاية وجهة (destination endpoint) تربط المهمة بمخزن S3 الخام.
4. الآن، يمكن لأدوات التحليل والتصور مثل Athena وQuickSight الوصول إلى البيانات لاستخلاص الرؤى من معلومات الطلاب — كل ذلك دون التأثير على قاعدة الإنتاج.

3️⃣ Well-Architected Pillars for Data — ركائز Well-Architected لطبقة البيانات

📖 تطبيق مبادئ Well-Architected على طبقة البيانات يضمن قاعدة بيانات آمنة وموثوقة وفعالة من حيث التكلفة.
كل ركيزة من الركائز الست تقدم إرشادات محددة لتحسين طبقة البيانات.

📋 تطبيق الركائز الست على قواعد البيانات

• التميز التشغيلي: أتمتة النسخ الاحتياطي والتصحيح والتوسع عبر RDS المُدارة. استخدام Infrastructure as Code (مثل CloudFormation) لتوثيق وإعادة إنشاء البنية.
• الأمان: تشفير البيانات في السكون والنقل، عزل القاعدة في شبكة خاصة، استخدام IAM للمصادقة حيث أمكن.
• الموثوقية: تفعيل Multi-AZ للإنتاج، النسخ الاحتياطي التلقائي مع نقطة زمنية للاستعادة، الجداول العالمية لـ DynamoDB.
• كفاءة الأداء: اختيار المحرك والمثيل المناسبين، استخدام Read Replicas لتوزيع الحمل، ElastiCache لتقليل الضغط، Aurora للتطبيقات عالية الأداء.
• تحسين التكلفة: استخدام Reserved Instances لـ 70% خصم، Aurora Serverless للأحمال المتقطعة، DynamoDB On-Demand للتطبيقات الجديدة.
• الاستدامة: اختيار مناطق AWS القريبة من المستخدمين لتقليل زمن الوصول واستهلاك الطاقة، استخدام الخدمات بدون خادم (DynamoDB, Aurora Serverless) التي لا تهدر سعة حوسبة.

مهندس حلول يراجع بنية قاعدة بيانات لتطبيق توصيل طعام.
يكتشف أن RDS في AZ واحدة بدون Multi-AZ — يضيفها فوراً (ركيزة الموثوقية).
يلاحظ أن 80% من استعلامات التطبيق هي قراءة — يضيف Read Replicas (ركيزة الأداء).
يجد أن التطبيق يستخدم مثيل db.r5.2xlarge طوال الوقت حتى في منتصف الليل — يقترح Aurora Serverless (ركيزة التكلفة).
النتيجة: التطبيق يصبح أسرع بـ 40% وأرخص بـ 50% وأكثر موثوقية.

4️⃣ Best Practice: Architecture Selection — اختيار بنية قاعدة البيانات المناسبة

📖 اختيار بنية قاعدة البيانات المناسبة هو أفضل ممارسة رئيسية ضمن ركيزة كفاءة الأداء (Performance Efficiency).
الحل الأمثل يختلف حسب متطلبات التوفر والاتساق وتحمل التقسيم (partition tolerance) وزمن الاستجابة والمتانة وقابلية التوسع وإمكانيات الاستعلام.

📋 أفضل ممارسات اختيار البنية:

• استخدم نهجاً مدعوماً بالبيانات (Data-Driven Approach): حلل خصائص بياناتك وأنماط الوصول — هل تطبيقك يقرأ كثيراً (read-heavy) أم يكتب كثيراً (write-heavy)؟ هل يحتاج JOINs معقدة أم استعلامات بسيطة بمفتاح أساسي؟ الإجابات تحدد نوع القاعدة المناسبة.
• قيّم المفاضلات (Trade-offs): اختيار قاعدة مفتاح-قيمة (مثل DynamoDB) يحسن الأداء لكنه يفرض تناسقاً نهائياً (eventual consistency) — قيّم كيف سيؤثر هذا على تجربة المستخدمين قبل الاختيار.
• ضع التكلفة في الاعتبار: لا تزيد حجم المثيل لتحسين الأداء دون تقييم تأثير خيارات التهيئة المتاحة — جرب قراءة النسخ المتماثلة (Read Replicas) والتخزين المؤقت (Caching) قبل الترقية.
• اختبر الأداء: شغّل اختبارات تحميل (load tests) لتحديد مقاييس الأداء الرئيسية والاختناقات — جرب تهيئات مختلفة بدلاً من افتراض أن المثيل الأكبر هو الحل.

تطبيق SaaS للفوترة يحتاج استعلامات معقدة متعددة الجداول (JOINs) وإنشاء تقارير شهرية.
الفريق يقيم خيارين: DynamoDB (سرعة فائقة لكن بدون JOINs) أو RDS PostgreSQL (JOINs مدمجة لكن أداء أقل عند الحجم الكبير).
يختارون RDS للبيانات العلائقية الأساسية مع DynamoDB للتخزين المؤقت للبيانات الأكثر طلباً — كل أداة في المكان المناسب.
يضيفون Read Replicas لتوزيع حمل التقارير الشهرية دون التأثير على المعاملات اليومية.
النتيجة: مزيج من قاعدتين يلبي جميع المتطلبات بأفضل أداء وتكلفة.

5️⃣ Best Practice: Data Protection at Rest — حماية البيانات في حالة السكون

📖 حماية البيانات المخزنة في قاعدة البيانات هي جزء أساسي من ركيزة الأمان (Security Pillar).
التشفير يحافظ على سرية البيانات الحساسة في حال الوصول غير المصرح به أو الكشف العرضي — مع AWS KMS لإدارة المفاتيح بشكل آمن.

📋 أفضل ممارسات حماية البيانات في السكون:

• نفّذ إدارة آمنة للمفاتيح (Secure Key Management): حدد نهج تشفير يتضمن تخزين المفاتيح وتدويرها والتحكم في الوصول إليها. AWS KMS يوفر تخزيناً متيناً وآمناً ومكرراً لمفاتيحك ويتكامل مع معظم خدمات AWS.
• فرض التشفير في السكون (Enforce Encryption at Rest): تأكد من أن الطريقة الوحيدة لتخزين البيانات هي عبر التشفير. AWS KMS يتكامل بسلاسة مع خدمات AWS لتشفير جميع البيانات في السكون.
• قواعد البيانات المُدارة: RDS وDynamoDB تستخدم AWS KMS لتأمين البيانات. DynamoDB تشفر جميع بيانات المستخدم في الجداول والفهارس والتدفقات والنسخ الاحتياطية باستخدام مفاتيح تشفير مخزنة في KMS.
• تشفير RDS: قاعدة RDS المشفرة تشفر البيانات المخزنة في التخزين الأساسي، وجميع السجلات والنسخ الاحتياطية واللقطات. RDS تعالج المصادقة على الوصول وفك التشفير بشفافية مع تأثير ضئيل على الأداء.

مؤسسة مالية تخضع لرقابة هيئة السوق المالية (CMA).
تطلب الجهة الرقابية تشفير جميع بيانات العملاء في السكون.
قاعدة RDS الحالية غير مشفرة — تحتاج الترقية لتشفير AES-256.
الخطوات: 1) تلتقط لقطة (snapshot) من القاعدة الحالية. 2) تنسخ اللقطة مع تفعيل خيار التشفير باستخدام مفتاح KMS مخصص. 3) تستعيد النسخة المشفرة كمثيل RDS جديد.
النتيجة: جميع بيانات العملاء مشفرة بـ AES-256، والمفاتيح تدور تلقائياً كل 90 يوماً، والجهة الرقابية توافق على الامتثال.

6️⃣ Best Practice: Cost-Effective Resources — اختيار الموارد الفعالة من حيث التكلفة

📖 اختيار نوع المثيل والحجم والعدد المناسب بناءً على البيانات هو أفضل ممارسة ضمن ركيزة تحسين التكلفة (Cost Optimization).
التحجيم الصحيح (right-sizing) يأخذ في الاعتبار جميع موارد أحمال العمل وخصائص كل مورد والجهد المطلوب لعملية التحجيم.

📋 أفضل ممارسات تحسين التكلفة:

• اختر نوع المثيل بناءً على البيانات: استخدم بيانات عن خصائص الحمل والمورد — هل هو مكثف حوسبة (compute-intensive) أم ذاكرة (memory-intensive) أم إنتاجية (throughput-intensive) أم كتابة (write-intensive)؟ كل نوع له مثيل مناسب (db.r للحوسبة، db.x للذاكرة، db.m المتوازن).
• لا تفرط في توفير الموارد: استخدم Aurora Serverless أو DynamoDB On-Demand للأحمال المتقطعة — تدفع فقط مقابل السعة المستخدمة. قاعدة ثابتة 24/7 بتكلفة RDS كاملة لا معنى لها لتطبيق يستخدم فقط 8 ساعات يومياً.
• استخدم Reserved Instances: للأحمال المستقرة المتوقعة — خصم يصل إلى 70% مقارنة بالتسعير عند الطلب (On-Demand).
• أعد التقييم دورياً: التحجيم الصحيح عملية متكررة — تتغير أنماط الاستخدام، وتنخفض أسعار AWS، وتظهر أنواع موارد جديدة. راجع حجم مثيلات قواعد البيانات كل 6 أشهر.

شركة ناشئة تشغل قاعدة RDS db.r5.2xlarge (8 vCPU, 64 GB RAM) 24/7 بتكلفة ~$700 شهرياً.
تحليل الاستخدام يظهر أن 70% من الوقت، استخدام وحدة المعالجة المركزية أقل من 10% والذاكرة أقل من 20%.
الحل: تنتقل إلى Aurora Serverless v2 — خلال ساعات الذروة تتوسع إلى 32 ACU، وخلال الليل تنخفض إلى 0.5 ACU.
النتيجة: التكلفة تنخفض إلى ~$250 شهرياً (توفير 65%) مع نفس الأداء في ساعات الذروة.
إضافياً: توقع Reserved Instance لمدة 3 سنوات للقاعدة الجديدة — خصم إضافي 50% — التكلفة النهائية ~$125 شهرياً.

✅ خلاصة: Migration and Well-Architected — الهجرة و Well-Architected

• أمان قاعدة البيانات 4 طبقات: الشبكة (Security Groups + شبكات فرعية خاصة)، الوصول (IAM وكلمات مرور)، التشفير (KMS + SSL/TLS)، التدقيق (CloudTrail + Enhanced Monitoring).
• AWS DMS ينسخ البيانات بين قواعد متجانسة (serverless) أو غير متجانسة (مع SCT/DMS Schema Conversion) بأقل وقت تعطل مع إمكانية الترحيل المستمر.
• AWS DMS Fleet Advisor يكتشف ويُقيّم قواعد البيانات المحلية تلقائياً قبل الترحيل.
• AWS SCT وDMS Schema Conversion يحوّلان المخططات والإجراءات المخزنة بين المحركات المختلفة.
• DMS يمكنه نسخ البيانات من قواعد المعاملات إلى S3 لبناء بحيرات بيانات للتحليلات.
• تطبيق ركائز Well-Architected الست على طبقة البيانات يضمن أماناً وموثوقية وكفاءة في الأداء والتكلفة.
• Architecture Selection: اختر بنية القاعدة بناءً على خصائص البيانات وأنماط الوصول — لا تفرض حلاً واحداً للجميع.
• Data Protection: فرض التشفير في السكون عبر AWS KMS مع التدوير التلقائي للمفاتيح.
• Cost-Effective Resources: اختر نوع المثيل وحجمه بناءً على البيانات، واستخدم Serverless للأحمال المتقطعة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon RDS	خدمة قواعد البيانات العلائقية	خدمة مُدارة لتشغيل MySQL وPostgreSQL وOracle وSQL Server وMariaDB في السحابة.
Multi-AZ	النشر متعدد مناطق التوفر	نسخ متزامن لقاعدة البيانات عبر منطقتي توفر لضمان التوفر العالي.
Read Replica	النسخة المتماثلة للقراءة	نسخة للقراءة فقط من قاعدة البيانات لتوزيع حمل الاستعلامات.
Amazon Aurora	أمازون أورورا	محرك قواعد بيانات علائقية عالي الأداء متوافق مع MySQL/PostgreSQL.
Amazon DynamoDB	أمازون دينامو دي بي	قاعدة بيانات NoSQL مُدارة بالكامل، سريعة وبدون خادم.
Amazon ElastiCache	أمازون إلاستيكاش	خدمة تخزين مؤقت مُدارة تدعم Redis وMemcached.
AWS DMS	خدمة ترحيل قواعد البيانات	خدمة لترحيل قواعد البيانات إلى AWS بأقل وقت تعطل.
AWS SCT	أداة تحويل المخطط	تحول مخططات وإجراءات قواعد البيانات بين المحركات المختلفة.
DMS Fleet Advisor	مستشار أسطول DMS	أداة تكتشف وتُقيّم قواعد البيانات المحلية تلقائياً قبل الترحيل.
DMS Schema Conversion	تحويل المخطط في DMS	خدمة مُدارة لتحويل مخططات قواعد البيانات ضمن سير عمل DMS.
Homogeneous Migration	ترحيل متجانس	ترحيل بين نفس محرك القاعدة (MySQL→MySQL) مع توسع تلقائي serverless.
Heterogeneous Migration	ترحيل غير متجانس	ترحيل بين محركات مختلفة (Oracle→PostgreSQL) مع تحويل المخطط عبر SCT.
AWS KMS	خدمة إدارة المفاتيح	تخزين وتدوير مفاتيح التشفير والتحكم في الوصول إليها لتأمين البيانات في السكون.
Right-Sizing	التحجيم الصحيح	اختيار نوع وحجم المثيل الأمثل بناءً على بيانات الاستخدام الفعلية.

🚀 الخاتمة

في هذه الوحدة تعلمنا أن طبقة قاعدة البيانات هي العمود الفقري لأي تطبيق سحابي.
استكشفنا الخيارات المتعددة: القواعد العلائقية المُدارة مع Amazon RDS بمحركاتها الخمسة، ومحرك الجيل التالي Amazon Aurora الأسرع بـ 5 مرات، وقاعدة NoSQL فائقة السرعة Amazon DynamoDB بدون خادم.
تعلمنا آليات التوفر العالي: Multi-AZ للنسخ المتزامن التلقائي وRead Replicas لتوزيع حمل القراءة وصولاً إلى 15 نسخة.
تعمقنا في ElastiCache للتخزين المؤقت في الذاكرة وRedshift للتحليلات على نطاق بيتابايت.
استعرضنا أمان قاعدة البيانات عبر 4 طبقات: الشبكة والوصول والتشفير والتدقيق.
تعرفنا على أدوات الترحيل DMS وSCT التي تنقل بياناتك إلى AWS بأقل انقطاع.
وأخيراً، طبقنا مبادئ Well-Architected على طبقة البيانات لضمان الأمان والموثوقية وكفاءة الأداء والتكلفة.
تذكر: اختر قاعدة البيانات المناسبة لحالة الاستخدام، لا تجبر كل شيء في نموذج واحد.

تعديل المقال