مقارنة ونشر قواعد بيانات AWS: RDS (MySQL، PostgreSQL، MariaDB، Oracle، SQL Server)، Aurora (متوافق PostgreSQL/MySQL، serverless v2)، DynamoDB (NoSQL key-value)، ElastiCache (Redis، Memcached)، DocumentDB، Neptune، Timestream، Keyspaces. الاختيار حسب السيناريو.
للسياق: الدليل الرئيسي AWS SAA-C03 · VPC.
المقدّمة
اختيار قاعدة البيانات الصحيحة حرج في معماريّة AWS. SAA-C03 يختبر بانتظام القرار بين RDS/Aurora/DynamoDB حسب السيناريو. هذا الدرس يقارن الخدمات ويُعلّم كيف ننشرها.
المتطلّبات
- حساب AWS مُهيَّأ.
- VPC مع subnets خاصّة (راجع درس VPC).
- معرفة أساسيّة بـ SQL و NoSQL.
- المستوى المتوسّط.
- الوقت: ساعتان.
الخطوة 1 — مقارنة مُختصرة
RDS : SQL relationnel managé. MySQL/PostgreSQL/MariaDB/Oracle/SQL Server
Single instance أو Multi-AZ. Read replicas لـ scale read.
Vertical scaling، حدّ أقصى ~32 vCPU / 768 Go RAM
Aurora : SQL عالي الأداء متوافق MySQL/PostgreSQL.
Storage auto-scale 10 Go ← 128 To، 6 نسخ multi-AZ.
5x perf MySQL، 3x perf PostgreSQL.
Serverless v2: auto scale 0.5-128 ACU ثانية بثانية
DynamoDB : NoSQL key-value، serverless، ميلّي ثانية latency.
Auto-scale، pay per request أو provisioned. DAX cache.
حدود: 400 KB/item، queries مقيّدة (مفتاح أساسي).
ElastiCache : in-memory cache. Redis (data structures، pub/sub) أو Memcached (key-value بسيط)
DocumentDB : متوافق MongoDB (حتى v5)
Neptune : graph DB (Property Graph + RDF/SPARQL)
Timestream : time-series DB (IoT، monitoring)
Keyspaces : متوافق Cassandra
في الاختبار: اختر حسب use case. موقع e-commerce relational مع حاجة scale = Aurora. Catalog منتجات NoSQL ms latency = DynamoDB. Cache session = ElastiCache Redis.
الخطوة 2 — RDS: Multi-AZ مقابل Read Replicas
Multi-AZ (synchronous standby): DR + HA. الـ standby غير مرئيّ للتطبيقات، failover آليّ عند عطل primary. لا scale read.
Read Replicas (asynchronous): scale read، حتى 5 replicas لكلّ primary، يمكن أن تكون في منطقة أخرى. التطبيقات تقرأ الـ replicas لتخفيف الحمل عن primary.
Multi-AZ Cluster (منذ 2022): 2 standbys قابلتان للقراءة، failover < 35 ثانية. الأفضل في الاثنين.
في الاختبار:
- سؤال HA ← Multi-AZ
- سؤال scale read ← Read Replicas
- سؤال DR cross-region ← Read Replica cross-region (أو Aurora Global Database)
الخطوة 3 — Aurora Serverless v2
# إنشاء cluster Aurora Serverless v2 PostgreSQL
aws rds create-db-cluster \
--db-cluster-identifier lab-aurora \
--engine aurora-postgresql \
--engine-version 15.4 \
--master-username admin \
--manage-master-user-password \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=4
aws rds create-db-instance \
--db-instance-identifier lab-aurora-instance-1 \
--db-cluster-identifier lab-aurora \
--engine aurora-postgresql \
--db-instance-class db.serverless
Aurora Serverless v2: ~0.12 USD/ACU-ساعة (1 ACU = 2 Go RAM + CPU). مثاليّ لـ workloads spiky أو متقطّعة — تدفع لما تستعمل ثانية بثانية.
الخطوة 4 — DynamoDB
NoSQL key-value، scaling هائل (آلاف TPS)، latence ms.
# إنشاء جدول
aws dynamodb create-table \
--table-name Users \
--attribute-definitions AttributeName=userId,AttributeType=S AttributeName=email,AttributeType=S \
--key-schema AttributeName=userId,KeyType=HASH \
--global-secondary-indexes "IndexName=email-index,KeySchema=[{AttributeName=email,KeyType=HASH}],Projection={ProjectionType=ALL},ProvisionedThroughput={ReadCapacityUnits=5,WriteCapacityUnits=5}" \
--billing-mode PAY_PER_REQUEST
# Insert item
aws dynamodb put-item --table-name Users --item '{"userId":{"S":"u001"},"email":{"S":"diallo@example.com"},"name":{"S":"Diallo"}}'
# Query بالمفتاح
aws dynamodb get-item --table-name Users --key '{"userId":{"S":"u001"}}'
# Query عبر GSI
aws dynamodb query --table-name Users --index-name email-index \
--key-condition-expression "email = :e" \
--expression-attribute-values '{":e":{"S":"diallo@example.com"}}'
المفاهيم الواجب معرفتها:
- Partition key (HASH): تُحدّد القسم الفيزيائيّ، التوزيع
- Sort key (RANGE): ترتيب داخل القسم
- GSI / LSI: Global / Local Secondary Index لخصائص أخرى
- Provisioned مقابل On-demand: سعة ثابتة مقابل pay-per-request
- DAX: cache in-memory أمام DynamoDB، latence µs
- DynamoDB Streams: تدفّق التغييرات، قابل للاستهلاك من Lambda
- TTL: انتهاء آليّ للعناصر
في الاختبار: DynamoDB لـ single-digit ms latency، scale هائل، schema مرن. حدود: لا joins، لا SQL.
الخطوة 5 — ElastiCache
Cache in-memory لتخفيف الحمل عن قاعدة البيانات.
Redis : data structures (lists، sets، sorted sets)، pub/sub، Lua scripting
Multi-AZ مع auto-failover، persistence اختياريّة، replication
Cluster mode لـ scaling أفقي (حتى 500 nodes)
Memcached : key-value بسيط، multi-thread، لا persistence
أبسط لكن أقلّ ميزات
أسرع لكلّ node single، scale أفقي
حالات الاستعمال: cache session ويب، cache نتائج DB، leaderboard لحظيّ (Redis sorted sets)، pub/sub إشعارات.
الخطوة 6 — DocumentDB، Neptune، أخريات
DocumentDB : متوافق MongoDB. لتطبيقات قائمة على Mongo.
ملاحظة: متوافق حتى MongoDB 5.0 API
Neptune : graph DB. حالات: شبكات اجتماعيّة، توصيات، fraud detection
Property Graph (Gremlin) أو RDF (SPARQL)
Timestream : time-series. حالات: IoT data، application metrics، DevOps monitoring
Auto-tiering memory store + magnetic store
Keyspaces : Cassandra. لهجرات Cassandra قائمة.
Serverless، pay-per-request، متوافق CQL.
QLDB : ledger DB غير قابل للتغيير. حالات: audit trail، بديل blockchain
History قابل للتحقّق تشفيريّاً
الخطوة 7 — أمن قواعد بيانات AWS
Encryption at rest : KMS (مُفعَّل عند الإنشاء، لا يُضاف لاحقاً لـ RDS)
Encryption in transit : TLS لكلّ الاتّصالات (force_ssl param RDS)
Network isolation : نشر في subnets خاصّة من VPC
Security Groups : تقييد الوصول (مثلاً: SG-DB يسمح SG-WEB على port 5432 PostgreSQL)
IAM authentication : RDS و Aurora يدعمان auth عبر IAM (token 15min)
Secrets Manager : rotation آليّ لـ passwords DB
في الاختبار: معماريّة آمنة قياسيّة = DB في subnet خاصّ + SG مُقيِّد + KMS encryption + Secrets Manager لـ creds.
الخطوة 8 — Backup و restore
RDS Automated Backups : daily snapshot + transaction logs، retention 1-35 يوم، مجّاني حتى 100% حجم DB
RDS Manual Snapshots : عند الطلب، retention غير محدود
Point-in-Time Recovery : restore إلى أيّ ثانية في نافذة الـ retention
Cross-region snapshot : نسخ لـ DR
AWS Backup : خدمة مركزيّة لتخطيط backups multi-services
في الاختبار: سؤال RTO/RPO متكرّر. RDS Multi-AZ failover ~60-120 ثانية. PITR حتى 5 دقائق نضارة. Aurora Backtrack حتى 72h للوراء (دون restore كامل).
الخطوة 9 — الاختيار حسب سيناريو الاختبار
السيناريو الاختيار
------------------------------------------------- ------------------------
تطبيق e-commerce SQL مع موسميّة Aurora Serverless v2
Catalog منتجات مع بحث على خصائص DynamoDB + GSI
Session cache مستخدم ElastiCache Redis
تطبيق قائم MongoDB DocumentDB
IoT logs درجة حرارة 100K مستشعِر Timestream
شبكة اجتماعيّة (أصدقاء-أصدقاء-أصدقاء) Neptune
Audit log غير قابل للتعديل امتثال QLDB
DB legacy Oracle مُهاجَر RDS Oracle
موقع WordPress بسيط RDS MySQL
Analytics SQL على 10 To data lake Athena (على S3)
Data warehouse PB scale Redshift
الخطوة 10 — Aurora مقابل RDS standard
RDS (standard) Aurora
Storage EBS مُسبق التخصيص Auto-scale حتى 128 To
Réplication 1 master + N replicas Master + 5 replicas نفس storage
Failover 60-120 ثانية < 30 ثانية
Performance قياسيّ 5x MySQL، 3x PostgreSQL
Coût ~25% أرخص أغلى لكن أكثر أداءً
Compatibilité 5 engines MySQL/PostgreSQL فقط
Backup Snapshots Continuous + Backtrack
في الاختبار: Aurora للأداء و HA premium، RDS standard لـ Oracle/SQL Server أو ميزانيّة مُقيَّدة.
الأخطاء المتكرّرة
| الخطأ | الحلّ |
|---|---|
| RDS connection timeout | SG، route table، NACL — تحقّق من كلّ الطبقات |
| DynamoDB hot partition | اختر partition key بـ cardinalité عالية |
| تكلفة Aurora مفاجئة | فعّل Performance Insights، راقب ACU usage |
| Encryption غير مُفعَّل | RDS encryption قابل للتفعيل فقط عند الإنشاء |
| Read replica lag | تحقّق من تطابق أنواع instance بين primary و replica |
ما تنساه النظريّة الأوروبيّة في منطقة CEDEAO
E-commerce إفريقيّ (Wave، Jumia، Glovo): Aurora Serverless v2 + DynamoDB لـ catalog + ElastiCache Redis = stack حديث.
البنوك الرقميّة: RDS Multi-AZ + Read Replicas + KMS encryption + IAM auth + Secrets Manager. متوافق امتثال PCI DSS.
الشركات الناشئة: DynamoDB on-demand للانطلاق (pay-per-request)، لا حاجة لتوفير سعة.
أسئلة شائعة
RDS أم Aurora لـ PostgreSQL؟
Aurora للأداء و HA premium إذا الميزانيّة تسمح. RDS standard إذا أقلّ من 10 USD/شهر.
DynamoDB أم MongoDB؟
DynamoDB مُدمج AWS، ms latency، scale آليّ. MongoDB أكثر مرونة queries لكنّه يحتاج إدارة (DocumentDB بديل جزئيّ).
ElastiCache Redis أم Memcached؟
Redis للميزات (data structures، pub/sub، persistence). Memcached لـ key-value بسيط بمعدّل عالٍ جدّاً.
قراءات تكميليّة
- الدليل الرئيسي: AWS SAA-C03
- التتمّة: معماريّة عالية التوفّر متعدّدة الـ AZ.
- التوثيق: AWS RDS، DynamoDB، Aurora.
الكلمات المفتاحيّة: AWS RDS Multi-AZ، Aurora Serverless v2، DynamoDB GSI DAX، ElastiCache Redis Memcached، DocumentDB، Neptune، Timestream، Keyspaces.
دراسات حالات حقيقيّة في غرب إفريقيا
الحالة 1 — Fintech mobile money، داكار. 4 ملايين معاملة/شهر. 4 200 USD/شهر، 99.98% توفّر.
الحالة 2 — تجارة إلكترونيّة عابرة. 80 000 زائر/يوم. multi-region active-active. 8 500 USD/شهر، +23% تحويل.
الحالة 3 — هجرة بنك تقليديّ. 80% workloads في 14 شهراً. توفير 55% في السنة 3.
خمسة سيناريوهات SAA-C03
1: تجارة إلكترونيّة HA. ALB + ASG، CloudFront، Aurora Read Replicas، ElastiCache، SQS.
2: DR cross-region. Pilot Light، Aurora Global Database، Route 53 health checks.
3: تأمين بيانات. S3 SSE-KMS، RDS مُشفَّر، IAM least privilege، CloudTrail، GuardDuty.
4: تحسين تكلفة. Scheduler، RIs، Spot، Compute Savings Plans 3 سنوات. توفير 65-75%.
5: امتثال PCI DSS. تجزئة VPC، WAF + Shield، CloudHSM، AWS Config، Security Hub.
التكاليف بـ FCFA لـ PME
30 موظّفاً، تطبيق SaaS، 10 000 مستخدم/شهر: ~225 USD/شهر ≈ 135 000 FCFA/شهر. مع RIs 3 سنوات: ~87 000 FCFA/شهر.
خطّة مهنة
0-12 شهراً: junior 800K-1.2M FCFA. 12-30 شهراً: DevOps Pro 1.4M-2M. 30-60 شهراً: SAP-C02 2.2M-3.5M محلّياً، 4-7M remote. 60+ شهراً: senior 400-800 USD/يوم.
أدوات تكميليّة
Terraform، AWS CDK، GitHub Actions، ECS/EKS/Fargate، CloudWatch + Datadog، Cost Explorer + Vantage.sh، Prowler + Security Hub + Wiz.