أي قاعدة بيانات تختار؟
علائقية أو مفتاح وقيمة أو مستندات أو رسم بياني أو سلاسل زمنية أو بحث. وش يناسب كل نوع، وكيف تختار من قواعد بيانات AWS الكثيرة بأسئلة بسيطة، وكيف تكبر طبقة البيانات في تطبيق حقيقي خطوة بخطوة.
- الفكرة الأساسية
- تعريف
- متى يُستخدم
- تنبيه
في هذا المقال
في الجزء الثامن والتاسع شفنا RDS وAurora وElastiCache. بس لو فتحت قائمة AWS بتلقى أكثر من عشر خدمات قواعد بيانات، وهنا يبدأ الضياع.
السؤال الصحيح مو "وش أفضل قاعدة بيانات؟"، لأن ما فيه جواب واحد. السؤال: وش يناسب هذي البيانات بالذات؟
أسئلة تبدأ بها
قبل ما تفتح أي خدمة، جاوب على هذي الأسئلة:
| السؤال | ليش يهم |
|---|---|
| وش شكل البيانات؟ | جداول مترابطة، أو مستندات متغيرة، أو علاقات، أو قراءات عبر الزمن |
| كيف بتقراها؟ | بمفتاح، أو باستعلامات معقدة تربط جداول، أو ببحث في النص، أو بتجميع ملايين الصفوف |
| كم القراءة مقابل الكتابة؟ | الكثير من القراءة يتحل بكاش ونسخ قراءة، والكثير من الكتابة يحتاج تصميم مختلف |
| كم الحجم وكم النمو؟ | جيجابايت عادية أو بيانات تكبر بلا سقف |
| كم لازم تكون دقيقة؟ | تحويل مبلغ يحتاج معاملات صارمة، وعدد الإعجابات يتحمل تأخير |
| كم تقدر تدير؟ | فريق صغير يفضل خدمة تتوسّع لحالها |
| وش يعرف فريقك؟ | معرفة الفريق تختصر عليك أخطاء كثيرة |
أنواع قواعد البيانات
| النوع | شكل البيانات | خدمة AWS | مثال |
|---|---|---|---|
| علائقية | جداول مترابطة ومعاملات | RDS وAurora | طلبات وحسابات وفواتير |
| مفتاح وقيمة | قيمة تجيبها بمفتاحها، بحجم ضخم | DynamoDB | سلات شراء وملفات مستخدمين |
| مستندات | JSON بحقول مختلفة | DocumentDB وDynamoDB | كتالوجات ومحتوى |
| في الذاكرة | بيانات سريعة | ElastiCache وMemoryDB | كاش وجلسات |
| أعمدة واسعة | صفوف بأسلوب Cassandra وكتابة عالية | Keyspaces | أنظمة Cassandra قائمة |
| رسم بياني | روابط بين الأشياء | Neptune | شبكات اجتماعية وكشف احتيال |
| سلاسل زمنية | قراءات عبر الزمن | Timestream for InfluxDB | حساسات ومقاييس |
| بحث | نصوص تبحث داخلها | OpenSearch | بحث الموقع والسجلات |
| تحليلات | تجميع على بيانات ضخمة | Redshift | تقارير الإدارة |
| ملفات | ملفات بأي شكل | S3 مع Athena | سجلات وأرشيف |
علائقية أو NoSQL؟
هذا أول قرار، والفرق الحقيقي في طريقة التفكير:
| علائقية (SQL) | NoSQL | |
|---|---|---|
| التصميم | تصمم الجداول، ثم تكتب أي استعلام | تحدد الاستعلامات أولاً، ثم تصمم عليها |
| الاستعلامات | مرنة، مع ربط الجداول | محدودة، وسريعة في المسار اللي صممته |
| المعاملات | قوية | تختلف من خدمة لخدمة |
| التوسّع | القراءة سهلة، والكتابة غالباً بسيرفر أكبر | أفقي، بأداء ثابت مع الحجم |
خدمات بتمر عليك
- DynamoDB: مفتاح وقيمة بدون سيرفرات، وأداء ثابت بأي حجم. بنشرحها في الجزء الحادي والعشرين.
- DocumentDB: مستندات متوافقة مع MongoDB، فتناسبك لو تنقل تطبيق MongoDB قائم.
- MemoryDB: ذاكرة سريعة مثل Valkey لكن بيانات تدوم، فتقدر تستخدمها كقاعدة أساسية وليس كاش فقط.
- Keyspaces: متوافقة مع Apache Cassandra، بدون سيرفرات تديرها.
- Neptune: للبيانات اللي قيمتها في العلاقات، زي "أصدقاء أصدقائي اللي اشتروا هذا".
- Timestream for InfluxDB: لقراءات الحساسات والمقاييس. والنسخة القديمة LiveAnalytics مقفلة على العملاء الجدد.
- OpenSearch: بحث نصي وتحليل سجلات، وعادةً نسخة من بياناتك مو المصدر الأساسي.
- Redshift: مستودع بيانات للتقارير الضخمة. بنشرحه في الجزء الثالث والعشرين.
كيف تقرر؟
مر على الأسئلة من فوق لتحت، وأول "نعم" هي نقطة بدايتك:
وهذا دليل بداية مو قانون. التطبيق الواحد عادةً يستخدم أكثر من نوع، وكل نوع بيانات يروح للي يناسبه.
طبقة بيانات تكبر مع تطبيقك
ما تحتاج كل هذا من أول يوم. تخيل متجر إلكتروني يكبر مع الوقت:
- الإطلاق: قاعدة RDS واحدة تكفي. ولما تبدأ تستقبل طلبات حقيقية، فعّل Multi-AZ.
- الزوار زادوا والقراءة ثقلت: أضف ElastiCache للصفحات الرئيسية والجلسات.
- التقارير صارت تبطّئ الموقع: وجّهها لـ نسخة قراءة.
- بحث المنتجات ضعيف: أضف OpenSearch وعبّيه من قاعدة البيانات.
- الإدارة تبي تحليلات سنوات: انقل البيانات لـ S3 مع Athena أو Redshift.
- صار عندك زوار حول العالم: انتقل لـ Aurora Global Database.
كل خطوة جات بعد مشكلة حقيقية قستها، مو قبلها. أي خدمة زايدة تعني تكلفة وتعقيد وشي ثاني ممكن يتعطّل.
أخطاء شائعة
- اختيار NoSQL لأنها "تتوسّع": ثم تكتشف إنك تحتاج استعلامات ما صممت لها.
- تشغيل التقارير على قاعدة الإنتاج: استعلام واحد ثقيل يبطّئ الموقع كله.
- تخزين الملفات داخل قاعدة البيانات: حطها في S3، واحفظ رابطها في القاعدة.
- معاملة الكاش كمصدر للحقيقة: لو ضاع، لازم ما يضيع معه شي مهم.
- Multi-AZ في بيئة التطوير: تكلفة مضاعفة بدون فايدة غالباً.
الخلاصة
- اسأل عن شكل البيانات وطريقة قراءتها قبل اسم الخدمة.
- ابدأ علائقية إلا لو عندك سبب واضح لغيرها.
- التطبيق الواحد يستخدم أكثر من نوع، وكل بيانات تروح للي يناسبها.
- أضف كل خدمة لما تقيس مشكلة حقيقية، مو قبلها.
اختبر نفسك
قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.
السؤال 1 من 5
عيادة تبني نظام حجوزات فيه مواعيد ومرضى ومدفوعات. البيانات مترابطة، والمدفوعات تحتاج معاملات صارمة، والفريق الصغير لسا ما يعرف كل التقارير اللي بيحتاجها. وين يبدأ؟
اعرض الجواب
الجواب الصحيح: B
البيانات المترابطة والمعاملات والاستعلامات اللي ما تقدر تتوقعها كلها تشير لقاعدة علائقية. وهي الخيار المعقول افتراضياً إلا لو فيه سبب واضح.
- A: بتصمم حول استعلامات معروفة من البداية، وبيصعب إضافة تقارير جديدة.
- C: الكاش مو مصدر الحقيقة، فما ينفع تكون المدفوعات فيه.
- D: Neptune يناسب شبكات العلاقات العميقة، مو الجداول المترابطة العادية.
للمراجعة: علائقية أو NoSQL؟ في هذا الجزء، وChoosing an AWS database service في وثائق AWS.
السؤال 2 من 5
تطبيق اجتماعي يبي يقترح "ناس ممكن تعرفهم" بتتبع أصدقاء الأصدقاء عبر عدة خطوات، وبرد سريع. أي خدمة تناسب أكثر؟
اعرض الجواب
الجواب الصحيح: D
القيمة هنا في العلاقات نفسها، وNeptune مبني يمشي عبر أعداد كبيرة منها بزمن استجابة منخفض.
- A: ينفع لخطوة أو خطوتين، بس الربط يثقل كل ما زادت الخطوات.
- B: تقدر تخزن قوائم جاهزة، بس لسا لازم شي يحسبها.
- C: هذا للقراءات عبر الوقت، وما له علاقة بالعلاقات.
للمراجعة: خدمات بتمر عليك في هذا الجزء، وChoosing an AWS database service في وثائق AWS.
السؤال 3 من 5
عشرة آلاف حساس ترسل قراءة حرارة كل دقيقة، والمهندسين يبون متوسط كل ساعة لكل حساس خلال آخر أسبوع. أي خدمة مبنية لهذا؟
اعرض الجواب
الجواب الصحيح: A
هذي قراءات عبر الوقت، وقواعد السلاسل الزمنية مبنية تخزنها وتجمعها.
- B: هذا للعلاقات بين الأشياء.
- C: هذا لمستندات JSON بحقول مختلفة.
- D: هذا أساساً للبحث في النصوص وتحليل السجلات.
للمراجعة: أنواع قواعد البيانات في هذا الجزء، وWhat is Timestream for InfluxDB? في وثائق AWS.
السؤال 4 من 5
شركة تبي تنقل تطبيق MongoDB قائم إلى خدمة مُدارة في AWS بأقل تغيير في الكود. أي خدمة تناسب؟
اعرض الجواب
الجواب الصحيح: C
DocumentDB متوافق مع MongoDB، فنموذج المستندات وكثير من الكود ممكن يبقون زي ما هم.
- A: واجهتها ونموذج بياناتها مختلفين، فبينكتب كود الوصول للبيانات من جديد.
- B: هذا متوافق مع Cassandra، مو MongoDB.
- D: هذا علائقي، فبتحتاج تعيد تصميم المستندات كجداول.
للمراجعة: خدمات بتمر عليك في هذا الجزء، وWhat is Amazon DocumentDB? في وثائق AWS.
السؤال 5 من 5
فريق مبيعات يبي تقارير على طلبات خمس سنوات، يعني مليارات الصفوف، والاستعلامات ما لازم تبطئ قاعدة الإنتاج. أي طريقتين تناسب؟ (اختر اثنين.)
اعرض الجواب
الجواب الصحيح: B + E
الطريقتين يبعدون التحليل الثقيل عن الإنتاج. وRedshift يناسب التقارير الثقيلة المتكررة، وAthena يناسب الأسئلة العابرة بدون سيرفرات تشغلها.
- A: استعلام ثقيل واحد ممكن يضر أي شي شغال وقتها، وهي قاعدة علائقية مو مبنية لتحليل بهذا الحجم.
- C: الكاش نسخة مؤقتة، وصغير وغالي جداً على بيانات خمس سنوات.
- D: النسخة الاحتياطية في Multi-AZ ما ينقرأ منها.
للمراجعة: أخطاء شائعة في هذا الجزء، وWhat is Amazon Athena? في وثائق AWS.
بهذا نكمل قسم قواعد البيانات. تطبيقك الحين يشتغل ويتوسّع، وبياناته في أمان، بس كيف يوصل له الزوار باسم موقعك؟ هذا موضوع القسم الجاي، ونبدأه في الجزء الحادي عشر مع DNS وRoute 53.