{"id":"l-aws-3-3","courseId":"aws-cloud-foundations","lang":"ar","kind":"lesson","summary":"اختر بين Amazon RDS وAmazon DynamoDB انطلاقًا من أنماط الوصول في حمل العمل، واضبط كلًّا منهما مع النسخ الاحتياطية والتشفير والوصول الخاص منذ البداية.","html":"

كان لخادم Lantern القديم قاعدة بيانات PostgreSQL واحدة لكل شيء: الفعاليات والأماكن والمنظّمون وكل تأكيد حضور. وخلال ذروة المهرجان، اصطفّت عمليات كتابة تأكيدات الحضور خلف استعلام تقرير بطيء، فتجمّد الموقع كله. على AWS يمكنك أن تمنح كل نوع من البيانات قاعدة البيانات التي تناسبه. الاثنتان اللتان ستتعرّف إليهما أولًا هما Amazon RDS وAmazon DynamoDB، وتختلفان في معظم الجوانب التي تعنيك فعلًا.

\n

Amazon RDS: قاعدة بيانات SQL الخاصة بك، تُشغَّل نيابة عنك

\n

يشغّل Amazon Relational Database Service محرّكًا علائقيًا على بنية تحتية تديرها AWS. ومن المحرّكات المتاحة PostgreSQL وMySQL وMariaDB وOracle وSQL Server وDb2، إضافة إلى Amazon Aurora، المحرّك الخاص بـ AWS والمتوافق مع MySQL وPostgreSQL.

\n

تتولّى AWS الأعمال الروتينية التي كان فريق Lantern ينجزها في الثانية فجرًا: تجهيز الموارد، وتحديث نظام التشغيل والمحرّك في نافذة صيانة تختارها، والنسخ الاحتياطية التلقائية مع الاستعادة إلى نقطة زمنية، ونشر Multi-AZ مع standby متزامن في منطقة توافر أخرى يتولّى العمل تلقائيًا. ويبقى لك المخطّط، والـ indexes، والاستعلامات، ومستخدمو قاعدة البيانات، وحجم الـ instance، ومن يستطيع الاتصال.

\n

إليك كيف ينشئ Lantern قاعدة بيانات الفعاليات، مع توضيح الخيارات الآمنة:

\n
Terminal
aws rds create-db-instance \\\n  --db-instance-identifier lantern-events \\\n  --engine postgres --db-instance-class db.t4g.micro \\\n  --allocated-storage 20 --storage-encrypted \\\n  --master-username lantern_admin --manage-master-user-password \\\n  --backup-retention-period 7 --multi-az \\\n  --no-publicly-accessible
\n

يخزّن --manage-master-user-password كلمة مرور المدير في AWS Secrets Manager بدلًا من سجل أوامر الـ shell. ويُبقي --no-publicly-accessible قاعدة البيانات بعيدة عن الإنترنت؛ والدرس القادم يضعها في شبكة فرعية خاصة. ولأن تطبيق Lantern الحالي يعتمد على SQL، فالترحيل مجرد pg_dump ثم استعادة، مع بقاء الاستعلامات كما هي:

\n
SQL
SELECT v.name, date_trunc('month', e.starts_at) AS month, count(*) AS events\nFROM events e\nJOIN venues v ON v.id = e.venue_id\nGROUP BY v.name, month\nORDER BY month DESC, events DESC;
\n

كيف يحتسب RDS: لكل ساعة تشغيل للـ instance (مع Savings Plans أو reserved instances للاستخدام الثابت)، إضافة إلى التخزين لكل غيغابايت شهريًا، والنسخ الاحتياطية التي تتجاوز حصة مجانية، ونقل البيانات. ونشر Multi-AZ يضاعف تقريبًا تكلفة الـ instance لأن هناك اثنتين منها. والأهم أن الـ instance تُحتسب طوال الشهر مشغولة كانت أم خاملة. ويستطيع Aurora Serverless v2 أن يوسّع السعة مع الحمل وأن يتوقّف مؤقتًا عند الخمول، وهذا يناسب قواعد البيانات ذات الحمل المتقطّع أو قواعد بيانات التطوير.

\n

Amazon DynamoDB: صمّم المفاتيح، واحصل على السرعة بأي حجم

\n

DynamoDB قاعدة بيانات serverless من نوع مفتاح-قيمة ومستندات. لا توجد instance تحدّد حجمها: تنشئ جدولًا، وتختار مفتاحًا أساسيًا (primary key)، وتقرأ العناصر (items) وتكتبها (وهي مستندات شبيهة بـ JSON) بزمن استجابة ثابت بأجزاء قليلة من الألف من الثانية، سواء كانت عشرة طلبات يوميًا أو عشرات الآلاف في الثانية.

\n

العقبة أنك تصمّم المفاتيح حول الأسئلة التي ستطرحها. بالنسبة إلى تأكيدات الحضور، أسئلة Lantern هي «من سيحضر الفعالية X؟» و«هل أكّد هذا الشخص حضوره إلى X من قبل؟». وهذا يعطي مفتاح تقسيم (partition key) هو eventId ومفتاح ترتيب (sort key) هو email:

\n
Terminal
aws dynamodb create-table --table-name lantern-rsvps \\\n  --attribute-definitions AttributeName=eventId,AttributeType=S \\\n                          AttributeName=email,AttributeType=S \\\n  --key-schema AttributeName=eventId,KeyType=HASH \\\n               AttributeName=email,KeyType=RANGE \\\n  --billing-mode PAY_PER_REQUEST
\n

عندئذٍ يصبح عدّ تأكيدات الحضور لفعالية واحدة Query رخيصًا:

\n
Terminal
aws dynamodb query --table-name lantern-rsvps \\\n  --key-condition-expression \"eventId = :e\" \\\n  --expression-attribute-values '{\":e\": {\"S\": \"evt-2026-street-food\"}}' \\\n  --select COUNT
\n

كيف يحتسب DynamoDB: في نمط on-demand (PAY_PER_REQUEST)، لكل طلب قراءة وكتابة إضافة إلى التخزين لكل غيغابايت شهريًا، ولا شيء مقابل وقت الخمول. أما نمط provisioned، مع التوسّع التلقائي، فقد يكون أرخص للزيارات الثابتة المتوقّعة. ابدأ بـ on-demand؛ ولا تنتقل إلا حين تُظهر الفاتورة حملًا ثابتًا. والاستعادة إلى نقطة زمنية (point-in-time recovery) إعداد تفعّله لكل جدول، ويجب أن تفعّله.

\n\n

الاختيار

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
السؤالRDSDynamoDB
هل الأسئلة متنوّعة أو تُطرح عند الطلب؟نعم: SQL يتعامل مع الجديد منهالا: المفاتيح تجيب عن المعروف منها
هل تحتاج إلى JOIN وقيود بين عدة جداول؟نعمنادرًا؛ تلغي التطبيع (denormalise)
زيارات متقطّعة مع أوقات خمول؟تدفع ثمن ساعات الخمولتدفع لكل طلب
كود SQL موجود تريد الاحتفاظ به؟احتفظ بهأعد كتابة طبقة الوصول إلى البيانات
العمليات التي تبقى عليكتحديد الحجم، والاتصالات، والترقياتتصميم المفاتيح

ينتهي Lantern بـ الاثنتين: الفعاليات والأماكن والمنظّمون في RDS for PostgreSQL، حيث تعمل التقارير وصفحات الإدارة الحالية دون تغيير؛ وتأكيدات الحضور في DynamoDB، حيث تكلّف ذروة الكتابة في فعالية منتشرة بضعة سنتات من الطلبات بدلًا من تجميد قاعدة البيانات المشتركة.

\n\n

قاعدة البيانات خاصة، لكنها محجوبة عن ماذا بالضبط؟ يبني الدرس التالي الشبكة التي تعيش فيها قطع Lantern.

\n","toc":[{"id":"sec-1","text":"Amazon RDS: قاعدة بيانات SQL الخاصة بك، تُشغَّل نيابة عنك","level":2},{"id":"sec-2","text":"Amazon DynamoDB: صمّم المفاتيح، واحصل على السرعة بأي حجم","level":2},{"id":"sec-3","text":"الاختيار","level":2}],"takeaways":["يشغّل Amazon RDS محرّكًا علائقيًا مثل PostgreSQL نيابة عنك، ويتولّى التحديثات والنسخ الاحتياطية والتحويل التلقائي في نمط Multi-AZ، بينما تملك أنت المخطّط والاستعلامات والاتصالات.","Amazon DynamoDB قاعدة بيانات serverless من نوع مفتاح-قيمة ومستندات، تصمّم فيها المفاتيح حول الأسئلة التي ستطرحها.","يحتسب RDS في الغالب لكل ساعة تشغيل للـ instance، مشغولة كانت أم خاملة؛ أما DynamoDB بنمط on-demand فيحتسب لكل طلب ولكل غيغابايت مخزّن.","استخدم Query من DynamoDB على المفاتيح في المسارات الساخنة، لأن Scan يقرأ الجدول كله ويحتسبه.","كثير من الأنظمة الحقيقية تستخدم الاثنين، البيانات العلائقية في RDS، وعمليات البحث البسيطة عالية الحجم في DynamoDB."],"further":[{"title":"What is Amazon RDS?","url":"https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html"},{"title":"What is Amazon DynamoDB?","url":"https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html"},{"title":"DynamoDB throughput capacity (on-demand and provisioned)","url":"https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html"},{"title":"Configuring and managing a Multi-AZ deployment for Amazon RDS","url":"https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html"}],"quiz":[{"q":"

يريد أمين صندوق Lantern تقارير مخصّصة عند الطلب مثل «الفعاليات لكل مكان في كل شهر، مع أسماء المنظّمين»، والأسئلة تتغيّر كل ربع سنة. أيّ قاعدة بيانات تناسبه؟

","options":[{"text":"DynamoDB، لأنها serverless وتتوسّع تلقائيًا.","why":"التوسّع ليس المشكلة هنا. تجيب DynamoDB عن الأسئلة التي صمّمت المفاتيح لها؛ وكل JOIN جديد عند الطلب يعني indexes أو تصديرات جديدة في كل مرة."},{"text":"RDS for PostgreSQL، لأن عمليات JOIN والتجميع في SQL تجيب عن الأسئلة الجديدة دون إعادة تصميم البيانات.","why":"صحيح. تتألّق قواعد البيانات العلائقية حين تكون الأسئلة متنوّعة وتتغيّر مع الوقت."},{"text":"S3 Standard، لأن التقارير ملفات.","why":"يمكن أن تعيش مخرجات التقرير في S3، لكن S3 ليست قاعدة بيانات ولا تستطيع ربط الصفوف أو تجميعها بنفسها."}],"answer":1},{"q":"

مفتاح التقسيم (partition key) في جدول تأكيدات الحضور هو eventId ومفتاح الترتيب (sort key) هو email. أيّ استدعاء يعيد كل تأكيدات الحضور لفعالية واحدة بكفاءة؟

","options":[{"text":"Scan مع ترشيح على eventId.","why":"يقرأ Scan كل عنصر في الجدول ثم يطبّق الترشيح بعد ذلك، فتدفع ثمن قراءة الجدول كله."},{"text":"GetItem مع eventId فقط.","why":"يحتاج GetItem إلى المفتاح الأساسي كاملًا، أي مفتاح التقسيم ومفتاح الترتيب، ويعيد عنصرًا واحدًا."},{"text":"Query مع شرط المفتاح eventId = :e.","why":"صحيح. لا يقرأ Query إلا العناصر تحت مفتاح التقسيم ذاك، فتنمو التكلفة مع تأكيدات الحضور لتلك الفعالية، لا مع حجم الجدول."}],"answer":2},{"q":"

أيّ إعداد في RDS يحمي قاعدة بيانات الفعاليات في Lantern من خسارة منطقة توافر واحدة؟

","options":[{"text":"نشر بنمط Multi-AZ، يحتفظ بنسخة احتياطية جاهزة (standby) في منطقة توافر أخرى ويتحوّل إليها تلقائيًا.","why":"صحيح. ينسخ RDS البيانات إلى الـ standby بشكل متزامن، ويتحوّل إليه حين تواجه منطقة توافر النسخة الرئيسية مشكلة."},{"text":"نسخ احتياطية تلقائية بفترة احتفاظ مدتها سبعة أيام.","why":"تتيح لك النسخ الاحتياطية الاستعادة إلى نقطة زمنية، لكن الاستعادة تنشئ instance جديدة وتستغرق وقتًا. إنها ليست تحويلًا تلقائيًا."},{"text":"فئة instance أكبر.","why":"المزيد من المعالج والذاكرة يساعد مع الحمل، لكن instance أكبر في منطقة توافر واحدة تسقط مع تلك المنطقة."},{"text":"تشفير التخزين.","why":"التشفير يحمي البيانات المخزّنة من القراءة. ولا يفعل شيئًا للتوافرية."}],"answer":0}],"exercise":{"kind":"choice","multiple":true,"options":["rsvps","reports","ticket-lookup","relational-admin","rate-limit"],"correct":["rsvps","ticket-lookup","rate-limit"],"title":"أيّ البيانات مكانها DynamoDB؟","prompt":"

يقسّم Lantern قاعدة بيانات PostgreSQL الوحيدة لديه. قرّر لكل ميزة هل Amazon DynamoDB مناسبة لها. اختر كل ميزة يجب أن تستخدم DynamoDB؛ أما البقية فتبقى في Amazon RDS for PostgreSQL.

\n","hints":["تكون DynamoDB في أقوى حالاتها حين تستطيع أن تحدّد مسبقًا المفتاح الذي سيستخدمه كل طلب بالضبط.","الأسئلة المتنوّعة والمتغيّرة وعمليات JOIN عبر عدة جداول تشير إلى SQL.","الميزات ذات البيانات قصيرة العمر تستطيع استخدام Time to Live (TTL) في DynamoDB لحذف العناصر تلقائيًا دون تكلفة إضافية."],"explanation":"

تأكيدات الحضور، والبحث عن التذاكر، وعدّادات تحديد المعدّل، لكلٍّ منها نمط وصول واحد معروف، بمفتاح هو معرّف ما، وتشهد اندفاعات مفاجئة من الزيارات، وهنا يتألّق تسعير DynamoDB لكل طلب وزمن استجابتها الثابت. كما أن عدّادات تحديد المعدّل تنتهي صلاحيتها، ويحذفها TTL نيابة عنك (عادةً خلال يوم أو يومين من انتهائها، لذا يظل الكود يقارن وقت الانتهاء بنفسه). أما تقارير أمين الصندوق فتطرح أسئلة جديدة كل ربع سنة مع عمليات JOIN وتجميع، وتعتمد صفحات الإدارة على مفاتيح خارجية (foreign keys) بين المنظّمين والأماكن والفعاليات؛ وكلاهما عمل علائقي يؤدّيه كود SQL الحالي جيدًا في RDS.

\n","checkLabels":{},"optionText":{"rsvps":{"text":"تأكيدات الحضور: كتابة واحد لكل شخص في كل فعالية، وسردها حسب الفعالية، والتحقّق من التكرار.","why":"مناسبة. كل طلب يستخدم eventId، إضافة إلى email للتحقّق من التكرار، وتقفز عمليات الكتابة حين تنتشر فعالية ما."},"reports":{"text":"تقارير ربع سنوية يعيد أمين الصندوق تصميمها كل مرة، وتربط الفعاليات والأماكن والمنظّمين.","why":"غير مناسبة. الأسئلة المخصّصة عند الطلب مع عمليات JOIN هي بالضبط ما يتعامل معه SQL ولا تتعامل معه مفاتيح DynamoDB."},"ticket-lookup":{"text":"التحقّق من تذكرة بمعرّفها عند بوابة المهرجان، آلاف المرات في الدقيقة.","why":"مناسبة. GetItem بمفتاح واحد بحجم كبير وزمن استجابة منخفض هو نقطة القوة الأساسية في DynamoDB."},"relational-admin":{"text":"صفحات الإدارة، التي تعدّل المنظّمين والأماكن والفعاليات مع مفاتيح خارجية بينها.","why":"غير مناسبة. العلاقات والقيود بين عدة جداول عمل علائقي، وكود SQL الحالي يستمر في العمل في RDS."},"rate-limit":{"text":"عدّادات لكل عنوان IP تحدّ من الرسائل المزعجة في تأكيدات الحضور، وتنتهي صلاحية كلٍّ منها بعد عشر دقائق.","why":"مناسبة. مفتاح واحد لكل عنوان IP، وعمليات كتابة صغيرة متكرّرة جدًا، ويزيل TTL العدّادات المنتهية تلقائيًا."}}},"words":709,"readMinutes":4}