مفاهيم قواعد بيانات (databases) مهمة لكل شخص تقني

اليوم بكتب لكم عن واحد من اهم (وفي بعض الاحيان اهم) جزء من اي نظام تطوره في مكان عملك او مشروعك الخاص: الـdatabase او قاعدة البيانات 💾

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

حاكون ممتن لو ساعدتني على نشر العمل هذا عن طريق ارسال المدونة لاحد ممكن يستفيد منها، فالاخير الهدف هو نشر محتوى عربي تقني بجودة عالية مجانا؛ مساعدتك لي في هذا الهدف يعني لي الكثير :) ♥️

اليوم باغطي بعض من اهم االمفاهيم اللي تعتبر أساسية في عالم قواعد البيانات، وهي:

• مقدمة 🙇‍♂️
• SQL و NoSQL والفرق بينها 🗼
  • SQL - Structured Query Language
    • طيب ليش ممكن استخدم SQL database؟
      • الثقة في البيانات (trust me bro)
      • سهولة تشكيل البيانات بحسب الرغبة بكفاءة عالية
      • دعم وضمان صفات الـACID
        • Atomicity ⚛️
        • Consistency 🥣
        • Isolation 🚶‍♂️
        • Durability 🗿
      • لما الـdatabase يصير عندها مخ ومو بس تحفظ بيانات 🧠
  • NoSQL - Not Only SQL
    • أنواع NoSQL Databases
    • أهم الاحتياطات عند تصميم قاعدة بيانات NoSQL
    • توجد ميزات كثيرة للـNoSQL database، ومن اهمها التالي:

مقدمة 🙇‍♂️

مثل ما قلنا في البداية، قواعد البيانات واحدة من اهم الاعمدة اللي يقوم عليها (تقريبا كل) مشروع تقني كبير ويقدم قيمة. هذا العامود متفرع وصعب جدا انك تلم بكل فروعه في نفس الوقت. ولكن، انا عندي قناعة قوية وهي ان مهما كان دورك في تطوير حل تقني (backend, frontned, cloud, embedded systems, data scientist/engineer, او اي شيء غيرها) مهم جدا انك تكون ملم عالاقل بالمفاهيم اللي تحت بعمق يخليك تفهم اللي بيصير خلف الكواليس ويمكنك من التواصل مع اعضاء فريقك بشكل سلس وتفهم عليهم ويفهموا عليك.

ومثل ما يقول صديقي الحبيب م. عبدالرحمن الرحمة:

لما تبغا تعطي اهمية لشيء، اعطيه اسم وتواصل مع غيرك بالاسم هذا.

ومن هنا، ومن دون ما طول فالمقدمات، خلينا ندخل مع بعض في الفرق بين اهم فرعين قواعد بيانات: SQL & NoSQL. 🚀

SQL و NoSQL والفرق بينها 🗼

هذا القسم حيكون في تفصيل بشكل عميق شويه، لانه اذا فهم صح، حيكون مبين لخارطة الطريق لك في بحر الـdatabases وكيف تصنفها وتتعامل ومعاها وايش الاختيار اللي قد يكون أسلم بحسب الحالة والمشكلة اللي تحاول حلها. وتذكر، هدفك دائما هو انك تلاقي الاختيار الاقل سوءا، وليس الافضل(لان “الافضل” مجرد اسطورة)

SQL - Structured Query Language

النوع الاساسي من قواعد البيانات، ومثل ما يقول معملي المعماري المخضرم م. سامح دعبس:

استخدامك لـSQL Database هو الاساس، الى ما يتم اثبات العكس

طبعا هذا النوع واحد من الاكثر شيوعا، ولما اي واحد فينا يتعمل قواعد بيانات في الجامعة او غيره، في الغالب هذا المكان اللي يبدأ فيه. الفرق الوحيد الاساسي بين هذا النوع والنوع الثاني (NoSQL) هو انه في الـSQL لازم تعرف لمحرك قاعدة البيانات كيف تبغا البيانات تنحفظ وكمان ايش نوع كل معلومة في مخططك او الـschema.

واحد من اهم الاشياء اللي تميز الـSQL كصفة هو ايضا انها دائما تكون عبارة عن جداول (tables) وفي داخلها صفوف وعواميد (rows & columns) ولابد انك ترسم شكل كل واحدة من الـtables في ما يسمى فالمخطط او الـschema. الصورة التالية تبين معنا هذه المفاهيم بشكل واضح:

طيب ليش ممكن استخدم SQL database؟

الثقة في البيانات (trust me bro)

أسباب كثيرة، ومن اهمها هي ثقتك في البيانات (حرفيا)، وما يسمى فالمجال بالـData Integrity والموضوع دا كبير (صدقني…)، فمثلا، تقدر تكون كلك ثقة ان البيانات اللي موجودة عندك في قاعدة البيانات كلها تتماشى مع مجموعة قوانين، على سبيل المثال:

• عامود السعر دائما فيه رقم (floating point) مكون من نقتطين عشريتين
• عامود تاريخ الميلاد فيه تاريخ يتماشى مع تصنيف معتمد مثل ISO 8601
• مافيه اي اسم في عامود الاسماء اطول من 20 حرف
• كل عامود ايميل في قاعدة البيانات موجود (اكيد مو فاضي - no null) وغيرها الكثير والكثير من الامثلة على سلامة البيانات. 🦺

سهولة تشكيل البيانات بحسب الرغبة بكفاءة عالية

سبب ثاني مهم هو سهولة الوصول للبيانات وتشكيلها مثل ما تحب من دون ما يكون استخراج البيانات بطيء، خصوصا لو كنت تعرف كيف تتقسم بيانات من بداية المشروع. والسبب ان الـSQL databases تساعدك بكل سهولة على انك تسوي Joins او دمج للبيانات من مختلف الجداول بكل سهولة، طالما عندك Primary Key و Foreign Key في كل واحدة من الجداول. سبب اساسي ايضا يخليك تختار هذا النوع من قواعد البيانات هو انك تقدر تسجل جميع البيانات بشكل منظم جدا ويسهل استخدامه عن طريق مفهوم يسمى بالـNormalization. ويتكون من عدة مستويات، وانصح (عشان تكون عملي برضه) تحاول تكون دائما في المستوى الثالث (3NF)؛ بحسب خبرتي المتواضعة، غالبا هذا المستوى يعطيك توازن جيد بين تعقيد العلاقات بين الجداول والمرونة في الدمج بين البيانات و تحديثها بشكل آمن.

الفيديو التالي مرجع رهيب يشرح مستويات الـnormalization بشكل ظريف ويوضح بأمثلة ممتازة:

حأكتب اكثر عن هذا المفهوم لاهميته، لكن خلينا نكمل الآن حتى ما نتشعب كثير. 👍

دعم وضمان صفات الـACID

والآن مع السبب الاكبر والاهم لسؤال “ليش ممكن استخدام SQL database”: المعاملات او الـTransactions وضمانك للـACID Compliance

كلام كبير، ايش معناه؟

معناه يا طويل العمر انك تقدر تحدث قاعدة البيانات الحلوة حقتك بدون ما تخاف على البيانات اللي فيها، وبحكم ان عندنا جزء كامل حنتكلم فيه عن الـtransactions، حتكلم الآن بس عن ضمانات الـACID وايش معناها:

ACID هي اختصار لثلاث كلمات:

• A - Atomicity
• C - Consistency
• I - Isolation
• D - Durability

خلينا نعرفها ونتكلم عنها واحدة واحدة:

Atomicity ⚛️

المعنى الحرفي هو “الذرية”، والمقصود هو التالي (بأقل حشي ممكن): لا يمكن تجزيء العملية الى اجزاء اصغر. لو كانت عندك بيانات وقاعد تقوم بعملية لتحديثها، مافي الا معلومة “قبل العملية” او “بعد العملية”، مافي شيء اسمه في “نص العملية”. اسمعك تقول “طيب غوني بالله مثال لانك ضيعتني اكثر…“، ابشر، خد هذا المثال:

Consistency 🥣

والمعنى هنا انه فيه “مسلمات” في قاعدة البيانات دائما تكون صحيحة. ولكن، الـconsistency مختلفة شويه عن قريناتها في ACID لانها ما تعتمد على قاعدة البيانات بس، بل قاعدة البيانات وقوانين التطبيق كمان. على سبيل المثال، لو كان عندنا لعبة لابد ان يكون فيها نقود اللاعب اكثر من صفر، وجمع نقود اللاعبين كلهم مليون، نقدر نكون متطمنين ان هذا القانون دائما صحيح ولكن لابد كتابة هذه القوانين في نظام الـbackend المسؤول عن العمليات بين اللاعبين.

الزبدة، Consistency لا تعتمد على الـdatabase فقط.

Isolation 🚶‍♂️

الفكرة انه كل عملية تحصل في الـdatabase تحصل في فقاعة وبيئة مختلفة عن غيرها كأنه مافي احد يستخدم قاعدة البيانات غير هذه العملية اللي تحصل الآن (مافي عمليات تصير مع بعض - in-parallel)، طبعا هذا غير صحيح حرفيا، لانه الاداء حيكون ضعيف جدا لو كان لابد كل عملية تسمك طابور الى ما يجي دورها (ما ينفع انا وانت وغيرها يشتري من امازون في نفس الوقت، لازم ننتظر بعض!). عشان نقدر نحل هذه المشكلة، في طرق مختلفة لتحقيق هذه النتيجة بتفاوت مراحل المرونة بينها، الموضوع هذا في نظري رهيب ومهم ومرتبط بشكل كبير مع مراحل التناسق (Consistency Types/Levels).

Durability 🗿

اسهل “اسده” في الفهم: لو صار فيه transaction وتم اعتماده (commited)، حيكون فعلا معتمد وبيتم حفظه في الذاكرة، حتى لو احد فصل فيش سيرفر الـdatabase 🔌

لما الـdatabase يصير عندها مخ ومو بس تحفظ بيانات 🧠

روعة، خلينا الآن نختم بآخر سبب ليش الـSQL databases خيار جيد: Stored Procedures & Materialized Views

الفكرة بسيطة، تقدر تكتب وتحفظ استفسار (query) على قاعدة البيانات وتحفظه. وهذه الـquery المحفوظة تقدر تستخدمها في اي وقت.

Materialized Views: الـquery المحفوظة تقدر تسوي منها جدول “افتراضي”، والجدول هذا تقدر انك تحدث البيانات اللي فيه بحسب وقت معين او بحسب الطلب (on-demand). فمثلا، تقدر تحسب عدد النتجات اللي في سلة العملاء، وتحفظها في جدول (table) وكل ما العميل يضيف منتج تزيد العدد بـ1، بحيث انه ما تحتاج تعد المنتجات في الـbackend كل مره المستخدم يسوي تحديث للصفحة.

Stored Procedures: تخيل معايا انه تقدر تكتب منطق الخادم (backend logic) في قاعدة البيانات، هذا معنى الـstored procedures. تقدر حتى تحدد المدخلات (parameters/arguments) لكل خاصية وتشغلها بحسب قوانين او triggers معينه او في وقت معين او حتى حسب الطلب.

والآن اتخيل صار عندنا مفهوم عام عن الـSQL databases يمكننا نتكلم عنها مع زملاءنا ونفهمهم ويفهموا علينا. خلينا نستكشف الوجه الآخر من العملة، NoSQL databases 🪙

NoSQL - Not Only SQL

النوع هذا من قواعد البيانات رهيب جدا، لكن له استخداماته. في حال احنا غير متأكيد من هيكل البيانات او حتى في حال ما عندنا تحكم على البيانات المحفوظة (تكامل مع خدمات خارجية)، هذا النوع يعطيك المرونة اللازمة والمطلوبة عشان تقدر تحقق اللي تحتاجه بشكل سلس.

اذا لقيت نفسك في سيناريو فيه القوانين الثلاث للبيانات الضخمة، (Velocity, Variety, Volume) غالبا انك تختار قاعدة بيانات NoSQL خيار أسلم.

النوع هذا من قواعد البيانات يأتينا باشكال ونكهات مختلفة، الاشهر منها:

• Key-Value Pairs
• Document
• Wide Column
• Graph
• Time-Series

خلينا نتعرف عليهم بشكل مختصر، بعدين نتكلم عن بعض الفوائد للـNoSQL databases.

أنواع NoSQL Databases

Key-Value Pairs 🔑

الطابع العام على هذا النوع هو انها تحفظ البيانات على شكل مفاتيح (keys) وقيم لكل مفتاح (values). القانون الاساسي هو انه لا يمكن تكرار المفتاح الواحد اكثر من مره لكل صف (row). غير كدا، امورك فالسليم تقدر تحفظ اللي تبغاه ومافي هيكل ممكن يحدك بحكم انه مافي تقنين على schema او خطة معينه لبياناتك.

Document Databases 📄

شبيهة جدا بالنوع الاول، ولكن الفرق الوحيد انها تقدر تحفظ بيانات بأنواع اكثر (Binary، JSON، BSON، XML و غيرها) في نفس الـtable, وكمان تقدر تسترجع جزء من البيانات المحفوظة. فالغالب تكون ابطأ من الـKey-Value Pairs databases ولكن عندها مقومات تسمح لنا نكتب استفسارات (queries) معقدة أكثر. جدير بالذكر انه كثير من الـDocument databases ممكن تكون Key-value databases برضه، على سبيل المثال AWS DynamoDB و MongoDB ممكن تستخدم Document او Key-Value pairs

Wide Column 🏗️

في هذا النوع نتوقع ان البيانات اللي موجودة ضخمة، وان طريقة استخدامها غالبا يكون بدمج البيانات مع بعضها عشان نقدر نستنج معلومة. على سبيل المثال، لنفترض ان عندنا الكثير جدا من المشتريات في متجرنا الالكتروني (كثير يعني ملايين كل اسبوع، البزنس شغاال 🔥)، ودائما نحتاج معلومة كم بعنا حتى الآن كل يوم وايضا كم متوسط مشتريات كل عميل؛ ونحتاج هذه العلومات بشكل دقيق ولحظي (near real-time). في هذه الحالة، وبحكم ان في استخدامنا، مجموعة الصفوف اهم من الصف مفردا، يكون هذا النوع جدا فعال.

Graph Databases 🗺️

يعتمد هذا النوع على ان البيانات المحفوظة في قاعدة البيانات بينها علاقات كثيرة، والعلاقات هذه مختلفة في طبيعتها وغير ومنتظمة. اشهر مثال على هذا النوع من قواعد البيانات هو شبكات التواصل الاجتماعي، حيث فيه مستخدمين وبينهم علاقات كثيرة جدا بمعاني مختلفة؛ فهذا النوع فالغالب يكون الانسب.

Time-Series ⏱️

النوع هذا بعتمد بشكل اساسي على وقت دخول الصف او المعلومة الى قاعدة البيانات، حيث انها تعتمد على ان الوقت معلومة دائما موجودة وتعتبر من اهم المعلومات اللي بناء عليها سيتم استخدام قاعدة البيانات. واحدة من اكثر الاستخدامات الشائعة لهذا النوع من قواعد البيانات هو الـlog aggregation بحيث انه يمكن بسهولة استخدام السجلات الصادرة من الخدمات وفهم والتحري عن اي حادثة حصلت.

حلوين، والآن عشان نغطي الموضوع بشكل شامل ووافي، خلينا نتكلم عن المنطق اللي غالبا من الافضل نتبعه في تصميم البيانات اللي نبغا نحفظها في قاعدة البيانات الجديدة حقتنا من نوع NoSQL.

أهم الاحتياطات عند تصميم قاعدة بيانات NoSQL

من أهم الاشياءاللي بيقولها لك اي خبير NoSQL هو انك تتصالح مع فكرة انه الـnormalization ليست مهمة ابدا، يعني يا عزيزي التقني كرر بيانات و احفظ المعلومات في داخل بعضها (nested) ولا تخاف انك تحفظ بعض الـkeys بأنواع بيانات مركبة مثل المصفوفات وغيرها.

حلوين، اذا كيف اقدر ارتب بياناتي في NoSQL database بشكل جيد؟ هذه بعض القواعد اللي ممكن تتبعها:

1. حدد كيف تبغا تحصل على البيانات (Access Patterns): تتذكر الـnormalization؟ حلو، ابغاك تنساها :). اول شيء اكتب استعلاماتك (queries)، وصمم قاعدة البيانات بناء عليها. مو مهم فالـNoSQL اننا نعرف ايش هيكل البيانات، ولا اننا نثبت مخطط (schema)، ولكن مهم اننا نعرف كيف نبغا نستعلم عن البيانات ونستخدمها، وبناء على هذه المعلومات نقدر نحدد مفتاح التقسيم (partition key) المفتاح المركب (composite key) لانه بناء عليهم تترتب البيانات وقد هذا يكون الفيصل بين انه استعلاماتك تكون سرعة وذات كفاءة عالية، او بطيئة وتاخذ وقت طويل. والآن خلينا نتعرف على هذه المفاتيح بشكل سريع:
   1. مفتاح التقسيم (partition key): بالضبط نفس الـprimary key، لازم يكون مميز لكل مدخل في قاعدة البيانات، واسمه مفتاح التقسيم لانه عن طريقة يتم تفسيم البيانات بين الـnodes الخاصة بقاعدة البيانات
   2. المفتاح المركب (composite key): ويتكون من معلومتين، الـpartition key وايضا مفتاح الترتيب (sort key)، والفكرة منه انه هو الدلالة اللي من خلالها يعرف محرك قاعدة البيانات كيف يرتب البيانات في الذاكرة
2. كرر بياناتك لو تحتاج: لو كنت تحتاج تكرر بعض البيانات عشان تتفادى انك تدمج بين جدولين (JOIN)، 99% من المرات تكرار البيانات هو الخيار الافضل. وفي حال كان عندك علاقات بين البيانات بعضها ببعض، افضل طريقة هي انك ترتب البيانات بحسب ما تحتاج عشان تقدر توصلها بشكل سهل. خلينا ناخد مثال مع بعض:
   1. السيناريو: عندنا نظام فيه المستخدمين ممكن يتابعوا بعض (many-to-many relationship)، كيف ممكن نحفظ البيانات؟
   2. الحل: في جدول المستخدمين، يكون الـpartition key هو الـuser_id حتى يعرف المستخدم بشكل فريد. بعدها، نسوي جدول جديد يحتوي على كل مستخدم فيه مفتاح التقسيم بدلالة user_id، ومفتاح الترتيب للمستخدم المتابع (followee_id) من نوع user_id لمستخدم آخر.
3. استخدم الفهارس (index) بشكل صحيح: فيه نوعين من الفهارس:
   1. Global Secondary Index (GSI): النوع هذا من الفهارس يسمح لك تستفسر عن معلومة مختلفة عن الـprimary key، و في اي node من الـnodes.
   2. Local Secondary Index (LSI): نفس الـGSI، ولكن ما يسمح لك تبحث عن معلومة في جميع الـnodes، بل لابد تكون في الـnode الصحيحة (سواء باستخدام primary key او GSI) وبعدها البحث عن معلومة داخل الـnode.

توجد ميزات كثيرة للـNoSQL database، ومن اهمها التالي:

• دعم كبير جدا للتوسع بشكل افقي: يعني ضيف سيرفر جديد وضيفه للكتلة (cluster) اللي حاليا موجودة مو دون ما تشيل هم.
• سهولة حفظ البيانات: واحدة من اهم اسباب وجود هذا النوع من قواعد البيانات هو المرونة في حفظ البيانات. خصوصا لو كانت متغيرة بشكل كبير وعشوائي و/او يصعب التحكم في مصدر البيانات بشكل كامل.
• دعم للكتابة بشكل سريع: بحكم السببين الاولى، قد يمكنك التخمين ان هذا النوع من قواعد البيانات يساعدك في الكتابة فيها بشكل كبير وسريع. فمثلا لو عندك حساس يحفظ بيانات كل جزء من الثانية، او عدد المستخدمين هائل وكلهم يكتبوا في نفس الوقت، هذا النوع من قواعد البيانات قد يكون الخيار الامثل لك.

هذا كان مقال تكلمت فيه عن مقدمة في قواعد البيانات، النوعين الاساسية، والفروقات بينهم ومتى ممكن تستخدم كل نوع.

اتمنى اعجبك المقال واتمنى ضاف لك ولو القليل من المعلومات. 🙏

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

شكرا لكم، وفي أمان الله. 👋🏻

فيديو بيفابت اللي اتكلمنا فيه عن الـdatabases: