VOL22: Database Cheatsheet for System Design
VOL22: Database Cheatsheet for System Design
أهلًا وسهلا بكم في العدد الثاني والعشرين من النشرة الأسبوعية لاقرأ-تِك 🎉
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثاني والعشرين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية, من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة, ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Database Cheatsheet for System Design
Optimistic Locking in Databases
Database Connection Pool
N+1 Problem
Polymorphic React Components
Database Cheatsheet for System Design
لازم نكون عارفين ان اختيارنا للـ Database في الـ System اللي بنبنيه، هو قرار مش سهل وقرار هنبقى ملزمين بيه لفترة طويلة فلازم نختارها بعناية خصوصًا لو كمان الموضوع هيتضمن Budget وفلوس هتندفع.
عشان نسهل على نفسنا الاختيار هنحاول الأول نجاوب على السؤال ده:
هو ايه نوع الـ Data اللي محتاجين نخزنها في الـ System ؟
والاجابة هتكون حاجة من 3 واللي هنحاول سوا نبني Mind-Map في عقلنا عشان نسهل الاختيار علينا شوية:
Structured Data (Standard SQL Table Schema)
Semi-Structured Data (JSON, XML, etc..)
UnStructured Data (Blob)
بعد معرفتنا بنوع البيانات اللي هنخزنها، هنكون محتاجين نعرف حاجتين اتنين بس:
ايه هي الـ Use-Case أو هدفنا من تخزين البيانات
هل هنروح ناحية الـ Cloud ولا هيبقى اعتمادنا على الـ Open-Source والـ 3rd Party ؟
وده لإن تحديد الهدف من التخزين هيفرق في اختيار الـ Database وهيخلينا نروح لنطاق أقل من الاختيار، واعتمادنا على الـ Cloud من عدمه كذلك هيسهل علينا الاختيار وهيضيق نطاق الاختيار.
Structured Data
لو البيانات اللي هنخزنها Structured فوقتها عندنا 2 Use Cases :
Transactions / OLTP (Online Transaction Processing)
Analytics / OLAP (Online Analytical Processing)
لو هدفنا كان OLTP فوقتها هنتجه للـ Relational Databases اما لو كان OLAP فوقتها هنروح للـ Columnar Database والاتنين مختلفين عن بعض من ناحية طريقة تخزين البيانات وهيكلتها.
ووقتها نقدر بناء على معرفتنا هل هنروح للـ Cloud ولا لا نختار من الجدول اللي موجود في الصورة ، وطبعا بعد قراءتنا عن الفروقات بينهم وايه اللي هيخدمنا أكتر من ناحية الـ Performance, Pricing Model, وعوامل تانية كتير ..
Optimistic Locking in Databases
يعتبر الـ Locking من أهم الآليات اللي بنعتمد عليها في الـ Databases بشكل أساسي عشان نتحكم في الـ Concurrent Access للبيانات من خلال أكثر من Transactions، فلو كان هناك عدد من الـ Transactions بيحاول يوصل للبيانات دي في نفس الوقت فأكيد هيحصل نتيجة لده تضارب بنسميه Conflicts.
نقدر نتخيل الـ Locking كأنه زي القفل اللي بنقفل بيه على أي حاجة عشان نمنع أي حد من الوصول ليها. فالـ Databases أحيانًا بتحط قفل على الـ Row أو الـ Record لما يكون فيه Transaction شغال عليه عشان تمنع أي حد من الوصول للـ Row ده, اكنه دخل (الحمام وقفل وراه الباب) ..
طب هو ليه اصلا بنحتاج للـ Locking ؟
احنا بنحتاج للـ Locking لإنه بيقدملنا فوايد مهمة زي الـ Data Integrity & Data Consistency ودول من أهم الفوايد اللي بنحصل عليها من الـ Locking .. لإنه من غير Locking ممكن Two Concurrent Transactions يغيروا في قيمة الـ Column الواحد في نفس الوقت وده يسبب مشاكل كتير.
وعلى الرغم من فوايد الـ Locking الا انه بيجي مع تحديات كبيرة وتعقيدات في التعامل معاه، فلازم نكون فاهمينه عشان نقدر نتعامل معاه بشكل فعال.
فيه نوعين من الـ Locking وهم الـ Optimistic Locking والـ Pessimistic Locking بس احنا هنتكلم النهاردة عن الـ Optimistic.
ايه هو الـ Optimistic Locking ؟
الـ Optimistic Locking جاي من اسمه انه شخص متفائل، مبيفكرش في المشكلة الا لما تحصل ومبيشغلش باله، ولما تحصل مشكلة يبدأ يشوف هيتصرف ويحلها ازاي.
الـ Optimistic Locking دوره انه يمنع الـ Conflicts بين الـ Transactions واللي بنسبة كبيرة بتحصل نتيجة عملية الـ Concurrent Update فلما يكون فيه Transaction بيحاول يعمل Update لقيمة Row معين هنا هيجي الـ Optimistic Locking ويزود بعض البيانات الإضافية Metadata زي الـ Version أو الـ Timestamp.
الشراكات - Sponsorship
جالنا الفترة اللي فاتت أسئلة من بعض الشركات انهم حابين يبقى في شراكات بينا وبينهم ، وبفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship وتقدروا تشوفوا التفاصيل من هنا 🚀
لا تدع شيء يفوتك!
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Database Connection Pool
تخيل تروح فرع لبنك او أي فرع لشركة تليفون عشان تستفسر عن حاجة معينة وتلاقي مفيش غير شباك واحد , وفيه مئات الناس مستنيين أدوارها تيجي , وعلى ما يجي دورك وتستفسر ومسئول الشباك يساعدك بتكون استهلكت وقت كبير جدًا.
طب هيكون ايه رد فعلك لو مع كل حد هيجي يسال عن حاجة معينة, الفرع هيروح يدور على حد يوظفه يقعد في الشباك يساعدك وبعدين يمشي الموظف ده ؟
هو ده كان هيبقى شكل حياة تطبيقاتنا من غير Database Connection Pool بكل بساطة
Database Connection Lifecycle
خلونا قبل ما نتكلم عن الـ Database Connection Pool , نعرف ايه اللي بيحصل اما بنعوز نتصل بقاعدة البيانات من خلال التطبيق بتاعنا :
التطبيقات بتستعمل Database Drivers عشان تفتح Connection مع قاعدة البيانات
بيتم فتح Network Socket عشان نوصل التطبيق بقاعدة البيانات
المستخدم بيتعمله Authentication وفي حالتنا هنا بيكون التطبيق
بعد ما العملية تتم بنجاح , ممكن الـ Connection يتقفل
ومن ثم الـ Network Socket بيتقفل هوا كمان
فزي ما احنا شايفين فتح وقفل الـ Connection مع قواعد البيانات عملية مش سهلة وبتضمن أكتر من خطوات بالإضافة لكونها مستهلكة للـ Resources.
وطبعًا هنلاحظ ان ده ممكن يكون عادي في لو التطبيقات كانت صغيرة , ولكن مع نمو وتطور التطبيقات بتاعتنا هيواجهنا مشكلة كبيرة بخصوص الموضوع ده.
N+1 Problem
الـ N+1 Problem هي مشكلة في طريقة تعاملنا مع قواعد البيانات ، ومن المشاكل اللي لازم احنا كمطورين ناخد بالنا منها لانها ليها ضريبة كبيرة أوي خصوصا في التعامل مع البيانات الكبيرة.
فورقة وقلم وتعالوا نتعرف على المشكلة دي وازاي نقدر نتجنبها
N+1 Problem
الـ N+1 Problem هي مشكلة بتخلينا نعمل عدد Requests أكبر بكتير من اللي محتاجينه وعشان نكون محددين فبالتحديد N+1 Requests على الرغم اننا ممكن نحل نفس المشكلة بعدد Requests أقل.
وطبعًا الـ Requests الكثيرة اللي ملهاش لزمة بتشغل الـ Database وبالتالي الموقع أو التطبيق بتاعنا بيكون أبطأ و بيدينا Performance سيء.
وعشان نفهم كويس خلينا ناخد مثال, أنت بتبرمج موقع لمكتبة وعاوز بيانات الكتب الأكثر مبيعًا وكمان بيانات عن المؤلفين للكتب دي عشان تعرضها في صفحة مخصصة.
بيانات الكتب الأكثر مبيعًا في Books Table وبيانات المؤلفين في Authors Table
فأول حل هيجي في بالنا:
نكتب Query نجيب بيه List of Books من Books Table
Select * from books;لكل كتاب في قائمة الكتب هنعمل Request علي ال
Authors Tableعشان نجيب معلومات مؤلف الكتاب.
Select * from authors where authorID = <>;هنا إحنا روحنا للـ Database مرة عشان قائمة الكتب و عدد N من المرات - بعدد الكتب - عشان نجيب معلومات مؤلف كل كتاب.
دا هيخلي تحميل الصفحة بتاعت الكتب الأكثر مبيعًا على موقعك بطيئة جدًا بينما ممكن نحسّن من ال Performance بتاعنا بإننا نطلب البيانات من قاعدة البيانات في عدد أقل من ال Requests ودا بإننا نعمل اعادة هيكلة للـ Queries بتاعتنا.
Polymorphic React Components
من الصعب دعم جميع الخيارات والمكونات المحتملة التي قد يرغب المطور في استخدامها ضمن مكتبة مُكونات (ui components library) أو نظام تصميم مُعين (Design System).
في هذا المقال سنستعرض كيف يمكن لمكونات React متعددة الأشكال (Polymorphic React components) أن تساعد في التغلب على هذا التحدي. سنتطرق إلى الإمكانيات التي توفرها هذه المكونات لتصميم واجهات مستخدم ديناميكية ومرنة تُلبي متطلبات متنوعة بكفاءة عالية.
طُرق إنشاء مُكونات رياكت مُتعددة الأشكال
يُعتبر التعدد الشكلي (Polymorphism) طريقة حيث يُمكن لعنصر واحد أن يتخذ أشكالا متعددة، مثل زر (Button) يُمكن أن يعمل أيضا كرابط (Link). استخدام هذه الطريقة بكفاءة يُمكن أن يُسهم في تقليل الجهد اللازم لصيانة عدة نسخ مختلفة من المكونات؛ فبدلاً من امتلاك مكونين منفصلين لكل من الزر والرابط، نستطيع الاعتماد على مكون واحد (Button) مرن يُمكنه القيام بالوظيفتين.
من الطرق الشائعة لتطبيق التعدد الشكلي في React هي استخدام نمط "as" ونمط "asChild".
تُعتبر المكونات متعددة الأشكال شائعة جدا، حيث تستخدمها العديد من المكتبات (libraries) وأنظمة التصميم (design systems). من مكتبات CSS-in-JS مثل Styled Components، مرورا بمكتبات المكونات مثل Chakra UI، وصولا إلى أنظمة التصميم مثل React Spectrum، تُظهر هذه الأدوات كيف يمكن للمكونات المتعددة الأشكال أن تُسهم بشكل فعال في تبسيط تطوير واجهات المستخدم وتعزيز المرونة.
مشاركة من أحمد عطية في مجتمع اقرأ-تِك 😂
تقدروا دلوقتي تشتركوا في اقرأ-تِك بخصم الـ 20% وتنضموا لمجتمع مهتم بالقراءة في هندسة البرمجيات بـ 50 جنيه بس 🎉
وتستمتعوا بحرية كاملة في قراءة المقالات في مواضيع مختلفة بجودة عالية زي:
Data Structure & Algorithms , System Design , Distributed Systems , Micro-Services, Clean Code, Refactoring, Databases , Web Development, DevOps وغيرهم كتير باللغة العربية!
بالاضافة لمحتوى ورقة وقلم اللي بنشرح فيه مفاهيم برمجية بطريقة سهلة وباستعمال صور توضيحية 🚀
ولو فيه مشاكل في الدفع الأونلاين فمتاح دلوقتي الاشتراك من خلال InstaPay و VodafoneCash 💪
تقدروا تتواصلوا معانا من خلال الـ WhatsApp Business أو من خلال الرسايل على مواقع التواصل الاجتماعي أو من خلال البريد الالكتروني contact@eqraatech.com 😍
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
