قواعد البيانات: Amazon RDS مقابل Amazon DynamoDB

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

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

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

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

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

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

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

SELECT v.name, date_trunc('month', e.starts_at) AS month, count(*) AS events
FROM events e
JOIN venues v ON v.id = e.venue_id
GROUP BY v.name, month
ORDER BY month DESC, events DESC;

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

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

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

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

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

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

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

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

الاختيار

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

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