يعني إيه singleton في Laravel؟
الـ singleton في Laravel هو طريقة لتسجيل خدمة (service) معينة بحيث يتم إنشاء instance واحد منها فقط خلال دورة حياة Request (يعني من وقت ما السيرفر يستقبل الـ Request لغاية ما ينتهى) ببساطة كده ان الـ singleton في Laravel يعني إنك تنشئ نسخة واحدة بس من كلاس معين وتستخدم النسخة دي في أي مكان في التطبيق.
يعني بدل ما كل مرة تحتاج تستخدم الكلاس ده تنشئ نسخة جديدة منه، بتنشيء نسخة واحدة وتفضل تستخدمها طول الوقت.
ده بيكون مفيد لما تكون عندك خدمة معينة مش محتاج تنشئ منها أكتر من instance عشان ما تستهلكش موارد بدون داعي.
والـ Singleton Pattern هو نمط تصميم (Design Pattern) بيضمن إنه يكون فيه instance واحد بس من الكلاس في أي وقت.
خلينى اقولك على مثال توضيحي للـ Singleton في الحياة اليومية
تخيل عندك مكتب في شركتك فيه طابعة واحدة بس وكل الموظفين في الشركة بيستخدموا نفس الطابعة عشان يطبعوا مستنداتهم، بدل ما يكون لكل موظف طابعة خاصة بيه، كلهم بيستخدموا نفس الطابعة.
تعالى نطبيق المثال ده في البرمجة
بدون Singleton:
كل مرة موظف جديد عاوز يطبع حاجة، بنجيب طابعة جديدة مخصوص له، ده بيستهلك وقت وفلوس على الفاضي.
باستخدام Singleton:
عندنا طابعة واحدة في المكتب وكل الموظفين بيستخدموها، الطابعة دي زي الـ instance الواحدة اللي بتتم إنشاؤها لما نستخدم Singleton.
ليه بنستخدم اصلا الـ singleton؟
لو الكلاس ده بياخد وقت أو موارد كتير عشان يتنشئ (زي الاتصال بقاعدة بيانات) يبقى ألافضل تعمل نسخة واحدة منه وتستخدمها بدل ما تعمل نسخة جديدة كل مرة.
ولو الكلاس ده بيحتفظ ببيانات معينة وعاوز البيانات دي تفضل ثابتة، يبقى استخدام singleton هيكون مفيد لانه بيساعد على تحسين أداء التطبيق لأنك مش بتنشيء instance جديدة في كل مرة تحتاج تستخدم الخدمة.
ولو عندك خدمة بتعتمد على بيانات مشتركة بشكل عام بيفضل إنك تستخدم singleton عشان تضمن إن البيانات دي متغيرش أثناء التشغيل.
وفي Laravel بنسجل الكلاس ده كـ singleton في AppServiceProvider عشان نضمن إن فيه نسخة واحدة بس منه في التطبيق كله.
الخلاصه ان الـ singleton في Laravel بيساعدك إنك تضمن وجود instance واحدة بس من الخدمة خلال دورة حياة التطبيق و ده بيكون مفيد للـ performance
وهاوضح بأذن الله امثلة عملية بالصور فى التعليقات علشان المقال مش مكفى 😅 وكمان الصور هاتكون موضحه الكود وهايبقى ابسط للفهم ان شاء الله.
وفي النهاية طبعا ماننساش ندعو الله أن يحفظ إخواننا فى غزة ويمنحهم القوة والصبر، اللهم كن لهم عوناً وسنداً، وبدِّل ضعفهم قوة، وهمَّتهم عزيمة، واحقن دماءهم، وطمئن قلوبهم، واجعل لهم الفرج القريب.
وصلى الله وسلم وبارك على نبينا محمد، وعلى آله وصحبه أجمعين.
الـ singleton في Laravel هو طريقة لتسجيل خدمة (service) معينة بحيث يتم إنشاء instance واحد منها فقط خلال دورة حياة Request (يعني من وقت ما السيرفر يستقبل الـ Request لغاية ما ينتهى) ببساطة كده ان الـ singleton في Laravel يعني إنك تنشئ نسخة واحدة بس من كلاس معين وتستخدم النسخة دي في أي مكان في التطبيق.
يعني بدل ما كل مرة تحتاج تستخدم الكلاس ده تنشئ نسخة جديدة منه، بتنشيء نسخة واحدة وتفضل تستخدمها طول الوقت.
ده بيكون مفيد لما تكون عندك خدمة معينة مش محتاج تنشئ منها أكتر من instance عشان ما تستهلكش موارد بدون داعي.
والـ Singleton Pattern هو نمط تصميم (Design Pattern) بيضمن إنه يكون فيه instance واحد بس من الكلاس في أي وقت.
خلينى اقولك على مثال توضيحي للـ Singleton في الحياة اليومية
تخيل عندك مكتب في شركتك فيه طابعة واحدة بس وكل الموظفين في الشركة بيستخدموا نفس الطابعة عشان يطبعوا مستنداتهم، بدل ما يكون لكل موظف طابعة خاصة بيه، كلهم بيستخدموا نفس الطابعة.
تعالى نطبيق المثال ده في البرمجة
بدون Singleton:
كل مرة موظف جديد عاوز يطبع حاجة، بنجيب طابعة جديدة مخصوص له، ده بيستهلك وقت وفلوس على الفاضي.
باستخدام Singleton:
عندنا طابعة واحدة في المكتب وكل الموظفين بيستخدموها، الطابعة دي زي الـ instance الواحدة اللي بتتم إنشاؤها لما نستخدم Singleton.
ليه بنستخدم اصلا الـ singleton؟
لو الكلاس ده بياخد وقت أو موارد كتير عشان يتنشئ (زي الاتصال بقاعدة بيانات) يبقى ألافضل تعمل نسخة واحدة منه وتستخدمها بدل ما تعمل نسخة جديدة كل مرة.
ولو الكلاس ده بيحتفظ ببيانات معينة وعاوز البيانات دي تفضل ثابتة، يبقى استخدام singleton هيكون مفيد لانه بيساعد على تحسين أداء التطبيق لأنك مش بتنشيء instance جديدة في كل مرة تحتاج تستخدم الخدمة.
ولو عندك خدمة بتعتمد على بيانات مشتركة بشكل عام بيفضل إنك تستخدم singleton عشان تضمن إن البيانات دي متغيرش أثناء التشغيل.
وفي Laravel بنسجل الكلاس ده كـ singleton في AppServiceProvider عشان نضمن إن فيه نسخة واحدة بس منه في التطبيق كله.
الخلاصه ان الـ singleton في Laravel بيساعدك إنك تضمن وجود instance واحدة بس من الخدمة خلال دورة حياة التطبيق و ده بيكون مفيد للـ performance
وهاوضح بأذن الله امثلة عملية بالصور فى التعليقات علشان المقال مش مكفى 😅 وكمان الصور هاتكون موضحه الكود وهايبقى ابسط للفهم ان شاء الله.
وفي النهاية طبعا ماننساش ندعو الله أن يحفظ إخواننا فى غزة ويمنحهم القوة والصبر، اللهم كن لهم عوناً وسنداً، وبدِّل ضعفهم قوة، وهمَّتهم عزيمة، واحقن دماءهم، وطمئن قلوبهم، واجعل لهم الفرج القريب.
وصلى الله وسلم وبارك على نبينا محمد، وعلى آله وصحبه أجمعين.
15 من أوامر ال Git لازم تكون عارفهم
1- git clone:
-يتيح لك هذا الأمر تنزيل repository لجهازك الخاص.
في المرة الأولى التي نبدأ فيها العمل على مشروع جديد ، يتعين علينا استنساخه من Github أو خادم آخر باستخدام الأمر أدناه، ستحتاج إلى توفير عنوان URL الذي يوجد به المستودع.
git clone <repository-url>
2- git fetch:
-سنستخدم هذا الأمر بمجرد استنساخ الrepository بالفعل ونريد الحصول على فروع جديدة من خادم التحكم في المصدر عن بُعد.
3- git branch:
-سيعرض هذا الأمر على الشاشة الbranch الحالي الذي نعمل عليه والbranches المحلية الأخرى التي عملنا عليها في الماضي.
بوصف بسيط للbranch: هو المكان الذي ننشئ فيه نسخة جديدة من الكود دون إزعاج المطورين الآخرين، وبهذه الطريقة يمكننا العمل بشكل مستقل عنهم ومنع خطر حذف عمل الآخرين.
4- git checkout:
-العمل في branch منفصل لمهام مختلفة هو حقًا منهجية عمل يجب أن يعتمدها كل فرق المطورين؛ لذا ربما تسأل نفسك كيف نقوم بالفعل بإنشاء branch جديد، فقط باستخدام الأمر التالي سيفعل السحر:
git checkout -b <your-branch-name>
لاحظ أن السمة -b ضرورية هنا. إذا حذفت هذا ، فستتمكن من مشاهدة رمز branch آخر موجود بالفعل.
5- git pull:
-لنفترض أن لديك branch لمطور آخر في جهازك المحلي قمت بفحصه منذ عدة أيام، هناك احتمال كبير أنه قد تم تحديث بعض أجزاء التعليمات البرمجية؛ للحصول على أحدث التغييرات، فقط قم بتنفيذ الأمر التالي:
git pull
6- git stash:
-يأتي هذا الأمر لمساعدتنا في حفظ أجزاء من التعليمات البرمجية التي لم تكن جاهزة بعد لدفعها إلى الbranch.
7- git add:
- انتهيت من تطوير جزء من التعليمات البرمجية ولا تريد أن تفقده؟ هذا هو الوقت المناسب لحفظ عملنا في الbranch الحالي!
يرجى ملاحظة أنه من أجل القيام بذلك، يتعين علينا استخدام ثلاثة أوامر مختلفة، بشكل متتالي:
git add, git commit, git push
والطريقة كالتالي:
انتقل إلى المجلد الأساسي لمشروعك باستخدام الأمر التالي:
cd “/your/main/folder”
ثم استخدم ما يلي لإضافته:
git add .
8- git status:
من أجل التحقق من إضافة جميع الملفات، نستخدم git status :
إذا رأينا جميع الملفات باللون الأخضر ، فكل شيء على ما يرام، وإلا سيتم عرض بعض الملفات باللون الأحمر؛ تعني الملفات باللون الأحمر أننا لم نستخدم git add. في المجلد الرئيسي لمشروعنا، أو تم إجراء تغييرات أخرى بعد تنفيذ هذا الأمر.
9- git commit:
- بعد إضافة الكود الخاص بنا، نعلن أن كل شيء على ما يرام وهذا هو كل الكود الذي نريد دفعه إلى الbranch، بالشكل التالي:
git commit -m “A message that describes the changes”
يرجى ملاحظة أن السمة -m ضرورية لإضافة وصف للعمل الذي نضيفه إلى الفرع.
إذا كنا نرغب في إضافة جزء من التعليمات البرمجية إلى الcommit الحالي؛ فهذا يعني أنه لا داعي لإضافة وصف جديد يمكننا استخدام الشكل التالي:
git commit --amend --no-edit
10- git log:
-من أجل رؤية الcommit الحالي، او الcommits السابقة نستخدم هذا الأمر.
وهناك أمر يسهل عليك عرض التفاصيل المختصرة لكل commit في سطر واحد وهو:
git log –oneline
11- git cherry-pick:
يسمح لنا هذا الأمر بأخذ commit واحد مفقود في الbranch الخاص بنا من branch آخر:
git cherry-pick <commit-hash-string>
12- git push:
في الوقت الذي يتم فيه الانتهاء من الكود الخاص بنا وجاهزًا ، يمكننا دفعه إلى ال branch الخاص بنا باستخدام هذا الأمر:
git push origin <your-branch-name>
نواجه أحيانًا مواقف يكون فيها تسلسل الالتزامات في ال branchالمحلي غير متوافق مع ال remote ستؤدي محاولة دفع الكود الخاص بنا إلى الrepository إلى ظهور خطأ، هذه المرة إذا كنا متأكدين تمامًا من أن الbranch المحلي هو الأكثر تحديثًا؛ فيمكننا فرض العملية:
git push origin <your-branch-name> --force
git push origin <your-branch-name> --force-with-lease
يوصى اكثر بإستخدام الأمر الثاني؛ لأنه بهذه الطريقة سنقوم بالكتابة فوق الكود في الbranch البعيد فقط في حالة ما إذا كان الbranch المحلي على دراية بجميع الالتزامات في التحكم بالمصادر عن بُعد.
13- git diff:
للمقارنة بين التغييرات في التزامين، سنستخدم أمرًا مفيدًا للغاية:
git diff <first-commit-hash> <second-commit-hash>
14- git rebase:
في حالة عملنا في فريق، من المحتمل أن تكون منهجية العمل هي إنشاء branch جديد لكل ميزة ثم يقوم كل مطور بإنشاء branch خاص به من branch الميزات.
نستخدم هذا الأمر من أجل مواءمة الbranch الخاص بنا مع الالتزامات الجديدة التي يمكن إضافتها إلى branch الميزات خلال الوقت الذي عملنا فيه من جانبنا:
git rebase origin/<feature-branch-name>
15- git bisect:
1- git clone:
-يتيح لك هذا الأمر تنزيل repository لجهازك الخاص.
في المرة الأولى التي نبدأ فيها العمل على مشروع جديد ، يتعين علينا استنساخه من Github أو خادم آخر باستخدام الأمر أدناه، ستحتاج إلى توفير عنوان URL الذي يوجد به المستودع.
git clone <repository-url>
2- git fetch:
-سنستخدم هذا الأمر بمجرد استنساخ الrepository بالفعل ونريد الحصول على فروع جديدة من خادم التحكم في المصدر عن بُعد.
3- git branch:
-سيعرض هذا الأمر على الشاشة الbranch الحالي الذي نعمل عليه والbranches المحلية الأخرى التي عملنا عليها في الماضي.
بوصف بسيط للbranch: هو المكان الذي ننشئ فيه نسخة جديدة من الكود دون إزعاج المطورين الآخرين، وبهذه الطريقة يمكننا العمل بشكل مستقل عنهم ومنع خطر حذف عمل الآخرين.
4- git checkout:
-العمل في branch منفصل لمهام مختلفة هو حقًا منهجية عمل يجب أن يعتمدها كل فرق المطورين؛ لذا ربما تسأل نفسك كيف نقوم بالفعل بإنشاء branch جديد، فقط باستخدام الأمر التالي سيفعل السحر:
git checkout -b <your-branch-name>
لاحظ أن السمة -b ضرورية هنا. إذا حذفت هذا ، فستتمكن من مشاهدة رمز branch آخر موجود بالفعل.
5- git pull:
-لنفترض أن لديك branch لمطور آخر في جهازك المحلي قمت بفحصه منذ عدة أيام، هناك احتمال كبير أنه قد تم تحديث بعض أجزاء التعليمات البرمجية؛ للحصول على أحدث التغييرات، فقط قم بتنفيذ الأمر التالي:
git pull
6- git stash:
-يأتي هذا الأمر لمساعدتنا في حفظ أجزاء من التعليمات البرمجية التي لم تكن جاهزة بعد لدفعها إلى الbranch.
7- git add:
- انتهيت من تطوير جزء من التعليمات البرمجية ولا تريد أن تفقده؟ هذا هو الوقت المناسب لحفظ عملنا في الbranch الحالي!
يرجى ملاحظة أنه من أجل القيام بذلك، يتعين علينا استخدام ثلاثة أوامر مختلفة، بشكل متتالي:
git add, git commit, git push
والطريقة كالتالي:
انتقل إلى المجلد الأساسي لمشروعك باستخدام الأمر التالي:
cd “/your/main/folder”
ثم استخدم ما يلي لإضافته:
git add .
8- git status:
من أجل التحقق من إضافة جميع الملفات، نستخدم git status :
إذا رأينا جميع الملفات باللون الأخضر ، فكل شيء على ما يرام، وإلا سيتم عرض بعض الملفات باللون الأحمر؛ تعني الملفات باللون الأحمر أننا لم نستخدم git add. في المجلد الرئيسي لمشروعنا، أو تم إجراء تغييرات أخرى بعد تنفيذ هذا الأمر.
9- git commit:
- بعد إضافة الكود الخاص بنا، نعلن أن كل شيء على ما يرام وهذا هو كل الكود الذي نريد دفعه إلى الbranch، بالشكل التالي:
git commit -m “A message that describes the changes”
يرجى ملاحظة أن السمة -m ضرورية لإضافة وصف للعمل الذي نضيفه إلى الفرع.
إذا كنا نرغب في إضافة جزء من التعليمات البرمجية إلى الcommit الحالي؛ فهذا يعني أنه لا داعي لإضافة وصف جديد يمكننا استخدام الشكل التالي:
git commit --amend --no-edit
10- git log:
-من أجل رؤية الcommit الحالي، او الcommits السابقة نستخدم هذا الأمر.
وهناك أمر يسهل عليك عرض التفاصيل المختصرة لكل commit في سطر واحد وهو:
git log –oneline
11- git cherry-pick:
يسمح لنا هذا الأمر بأخذ commit واحد مفقود في الbranch الخاص بنا من branch آخر:
git cherry-pick <commit-hash-string>
12- git push:
في الوقت الذي يتم فيه الانتهاء من الكود الخاص بنا وجاهزًا ، يمكننا دفعه إلى ال branch الخاص بنا باستخدام هذا الأمر:
git push origin <your-branch-name>
نواجه أحيانًا مواقف يكون فيها تسلسل الالتزامات في ال branchالمحلي غير متوافق مع ال remote ستؤدي محاولة دفع الكود الخاص بنا إلى الrepository إلى ظهور خطأ، هذه المرة إذا كنا متأكدين تمامًا من أن الbranch المحلي هو الأكثر تحديثًا؛ فيمكننا فرض العملية:
git push origin <your-branch-name> --force
git push origin <your-branch-name> --force-with-lease
يوصى اكثر بإستخدام الأمر الثاني؛ لأنه بهذه الطريقة سنقوم بالكتابة فوق الكود في الbranch البعيد فقط في حالة ما إذا كان الbranch المحلي على دراية بجميع الالتزامات في التحكم بالمصادر عن بُعد.
13- git diff:
للمقارنة بين التغييرات في التزامين، سنستخدم أمرًا مفيدًا للغاية:
git diff <first-commit-hash> <second-commit-hash>
14- git rebase:
في حالة عملنا في فريق، من المحتمل أن تكون منهجية العمل هي إنشاء branch جديد لكل ميزة ثم يقوم كل مطور بإنشاء branch خاص به من branch الميزات.
نستخدم هذا الأمر من أجل مواءمة الbranch الخاص بنا مع الالتزامات الجديدة التي يمكن إضافتها إلى branch الميزات خلال الوقت الذي عملنا فيه من جانبنا:
git rebase origin/<feature-branch-name>
15- git bisect:
❤1
هذا الأمر مفيد جدًا في حالة تلف الأشياء ، لكننا لا نعرف متى و / أو في سبب حدوث ذلك.
الخطوة الأولى هي بدء bisect mode.
git bisect start
الآن نقول في اي commit نحن على يقين تام من أن الأشياء تعمل بشكل صحيح:
git bisect good <commit-hash>
ثم نقول ما هو ال commit الذي لا تعمل فيه الأشياء بشكل صحيح:
git bisect bad <commit-hash>
بعد هذه الخطوات الثلاث، سيكون هناك تكرار واحد أو أكثر للعثور على أول commit سيئ، وفي كل تكرار، نحتاج إلى التحقق من تطبيقنا ومعرفة ما إذا كانت الأمور جيدة.
للتكرار السيئ ، سنستخدم الأمر التالي:
git bisect bad
للتكرار الجيد سنستخدم الأمر التالي:
git bisect good
بمجرد أن نعلن عن commit جيد، ستظهر رسالة بها تجزئة الcommit السيئة وتفاصيلها.
الخطوة الأولى هي بدء bisect mode.
git bisect start
الآن نقول في اي commit نحن على يقين تام من أن الأشياء تعمل بشكل صحيح:
git bisect good <commit-hash>
ثم نقول ما هو ال commit الذي لا تعمل فيه الأشياء بشكل صحيح:
git bisect bad <commit-hash>
بعد هذه الخطوات الثلاث، سيكون هناك تكرار واحد أو أكثر للعثور على أول commit سيئ، وفي كل تكرار، نحتاج إلى التحقق من تطبيقنا ومعرفة ما إذا كانت الأمور جيدة.
للتكرار السيئ ، سنستخدم الأمر التالي:
git bisect bad
للتكرار الجيد سنستخدم الأمر التالي:
git bisect good
بمجرد أن نعلن عن commit جيد، ستظهر رسالة بها تجزئة الcommit السيئة وتفاصيلها.
هي ال Tables بتاعت ال Database بتتخزن إزاي علي ال disk ؟
إزاي فهم طريقة التخزين ممكن يخليني أحسن من ال Query اللي بعملها من حيث ال Performance.
في البداية أنت عملت جدول إسمه Employee وحطيت فيه بعض الاعمدة زي ال Id و ال Name وال Adress مثلا وخليت
ال Id ده يكون هو ال Primary Key
وخزنت ف الجدول ده مثلا 22 موظف.
الجدول ده بقا هيتخزن في ال Memory عندك علي شكل حاجه إسمها Data pages زي ما هو موضح بالصورة كده
وكل Data page بتكون حجمها 8 Kb
طيب أي شكل Tree اللي ظاهر في الصورة دي ؟
ببساطه أنت لما عملت Id وخليته Primary key
فبيتم إنشاء حاجه إسمها Clustered Index
وال Clusterd index ده بيخلي الداتا بتاعتك مترتبه بناءاً علي ال Id
وكمان بتكون علي شكل Tree بالشكل اللي انت شايفه ده
وبتكون كل نود بتشاور علي الي بعدها
والداتا بتاعت الموظف كامله بتكون موجوده اخر حاجه خالص
بالتالي لو حبيت تبحث عن الموظف الي ال Id بتاعه 11 مثلا
فأنت هتبدا من ال Tree من فوق خالص وتعدي علي ال Nodes كده ما هو موضع ف الصورة لحد ما تنزل في ال Range اللي أنت عاوزه
وتروح للData page اللي أنت متأكد ان الرقم اللي أنت بتبحث عنه موجود بداخلها وده بفضل ال Tree
هتروح لل Data Page تبحث جواها عم رقم 11 اللي أنت عاوزه
لكن كمان أنت مش هتبحث بشكل Linear لا
أنت كده كده ال Date page مترتبه فتقدر تعمل binary search بالتالي هتوصل أسرع وبتدا تقرأ ال Record اللي بتبحث عنه وترجعه.
بالتالي ك Performance ده كويس جداً
طيب لو كنت عمت الجدول بدون Primary key مكنش هيحصل Clustered Index ده بالتالي الداتا مش هتكون مترتبه بالتالي مش هتتخزن بالشكل ده وهيكون فيه عيوب كتير أبرزها
ال Performance أنت بقيت محتاج تعدي علي كلو لحد ما توصل لل Record اللي أنت عاوزه وده بيطلق عليه Table Scan.
طيب لو أنت عملت Primary key علي الId
لكن أنت للأسف بتبحث بال Age فأنت كده محتاج ال Tree بتاعتك تكون منظمه بس المره دي مش بال Id بس
لا بالAge علشان عملية ال Search تكون أسرع
فأنت هنا بقا بايدك تروح تعمل باردو Index علي ال Age بحيث
يشتغل بنفس طريقة ال Id
لكن ال Table بيكون فيه Clustered Index واحد فقط
فأنت هتعمل نوع تاني وهو Non Clustered Index
وبيتشغل بنفس الطريقة باختلاف بسيط.
فلو أنت عندك Database وعاوز تحسن من Query Performance بتاعك ممكن تشوف أنت بتبحث باي بالظبط
هل id ولا Name ولا Age وتعمل عليهم Index
هتقولي طيب ما أعمل علي كل الاعمدة Index وخلاص
هقولك ان كل Index بتعمله بياخد من Memory بتاعك.
مش بس كده في مشكلة تانيه
وأنك هتلاحظ بطئ في عميلة ال Insert أو ال Update
لانك بيحتاج انك تعمل maintenance لل Index ده ف كل مره
https://stackoverflow.com/questions/12915623/index-all-columns
وممكن تقرأ أكتر في اللينك ده عن ليه مينفعش
نعمل index for all columns
ودي طريقة من الطرق اللي ممكن نحسن بيها ال Performance بتاعت Query
قولنا اي طرق تانيه ممكن نحسن بيها ال Performance بتاعت ال Queries ؟
إزاي فهم طريقة التخزين ممكن يخليني أحسن من ال Query اللي بعملها من حيث ال Performance.
في البداية أنت عملت جدول إسمه Employee وحطيت فيه بعض الاعمدة زي ال Id و ال Name وال Adress مثلا وخليت
ال Id ده يكون هو ال Primary Key
وخزنت ف الجدول ده مثلا 22 موظف.
الجدول ده بقا هيتخزن في ال Memory عندك علي شكل حاجه إسمها Data pages زي ما هو موضح بالصورة كده
وكل Data page بتكون حجمها 8 Kb
طيب أي شكل Tree اللي ظاهر في الصورة دي ؟
ببساطه أنت لما عملت Id وخليته Primary key
فبيتم إنشاء حاجه إسمها Clustered Index
وال Clusterd index ده بيخلي الداتا بتاعتك مترتبه بناءاً علي ال Id
وكمان بتكون علي شكل Tree بالشكل اللي انت شايفه ده
وبتكون كل نود بتشاور علي الي بعدها
والداتا بتاعت الموظف كامله بتكون موجوده اخر حاجه خالص
بالتالي لو حبيت تبحث عن الموظف الي ال Id بتاعه 11 مثلا
فأنت هتبدا من ال Tree من فوق خالص وتعدي علي ال Nodes كده ما هو موضع ف الصورة لحد ما تنزل في ال Range اللي أنت عاوزه
وتروح للData page اللي أنت متأكد ان الرقم اللي أنت بتبحث عنه موجود بداخلها وده بفضل ال Tree
هتروح لل Data Page تبحث جواها عم رقم 11 اللي أنت عاوزه
لكن كمان أنت مش هتبحث بشكل Linear لا
أنت كده كده ال Date page مترتبه فتقدر تعمل binary search بالتالي هتوصل أسرع وبتدا تقرأ ال Record اللي بتبحث عنه وترجعه.
بالتالي ك Performance ده كويس جداً
طيب لو كنت عمت الجدول بدون Primary key مكنش هيحصل Clustered Index ده بالتالي الداتا مش هتكون مترتبه بالتالي مش هتتخزن بالشكل ده وهيكون فيه عيوب كتير أبرزها
ال Performance أنت بقيت محتاج تعدي علي كلو لحد ما توصل لل Record اللي أنت عاوزه وده بيطلق عليه Table Scan.
طيب لو أنت عملت Primary key علي الId
لكن أنت للأسف بتبحث بال Age فأنت كده محتاج ال Tree بتاعتك تكون منظمه بس المره دي مش بال Id بس
لا بالAge علشان عملية ال Search تكون أسرع
فأنت هنا بقا بايدك تروح تعمل باردو Index علي ال Age بحيث
يشتغل بنفس طريقة ال Id
لكن ال Table بيكون فيه Clustered Index واحد فقط
فأنت هتعمل نوع تاني وهو Non Clustered Index
وبيتشغل بنفس الطريقة باختلاف بسيط.
فلو أنت عندك Database وعاوز تحسن من Query Performance بتاعك ممكن تشوف أنت بتبحث باي بالظبط
هل id ولا Name ولا Age وتعمل عليهم Index
هتقولي طيب ما أعمل علي كل الاعمدة Index وخلاص
هقولك ان كل Index بتعمله بياخد من Memory بتاعك.
مش بس كده في مشكلة تانيه
وأنك هتلاحظ بطئ في عميلة ال Insert أو ال Update
لانك بيحتاج انك تعمل maintenance لل Index ده ف كل مره
https://stackoverflow.com/questions/12915623/index-all-columns
وممكن تقرأ أكتر في اللينك ده عن ليه مينفعش
نعمل index for all columns
ودي طريقة من الطرق اللي ممكن نحسن بيها ال Performance بتاعت Query
قولنا اي طرق تانيه ممكن نحسن بيها ال Performance بتاعت ال Queries ؟
❤1
لو انت front-end ف البوست ده هيوفر عليك كتير
اهم المواقع اللي بتقدملك vector icons & stickers & SVG اللي مش هتسغني عنها
- https://storyset.com/
- https://lottiefiles.com/
- https://www.humaaans.com/
- https://www.manypixels.co/
- https://blush.design/
- https://lnkd.in/dt4FhB52
- https://www.vecteezy.com/
- https://www.flaticon.com/
اهم المواقع اللي بتقدملك vector icons & stickers & SVG اللي مش هتسغني عنها
- https://storyset.com/
- https://lottiefiles.com/
- https://www.humaaans.com/
- https://www.manypixels.co/
- https://blush.design/
- https://lnkd.in/dt4FhB52
- https://www.vecteezy.com/
- https://www.flaticon.com/
دورة حياة الـ HTTP Request من المتصفح إلى الخادم والعكس
عند إدخال رابط في المتصفح، تبدأ رحلة الطلب (Request) كالتالي:
تحويل الرابط إلى عنوان IP:
المتصفح يسأل خدمة DNS عن عنوان الـ IP الخاص بالرابط.
بعد الحصول على الـ IP، يتم تخزينه مؤقتًا (Cache) لفترة قصيرة.
فتح اتصال مع الخادم:
يتم استخدام الـ IP لإنشاء اتصال TCP مع الخادم.
إذا كان الاتصال HTTPS، يتم استخدام بروتوكول TLS لتشفير الاتصال.
إعداد الطلب:
يتم تحديد طريقة الطلب (مثل GET).
تضاف الرؤوس (Headers) التي تحتوي على معلومات مثل الكوكيز ونوع البيانات.
يتم إضافة أي بيانات في الجسم (Body) إذا لزم الأمر.
إرسال الطلب:
قد يمر الطلب عبر خدمات مثل Cloudflare للحماية، أو موازن تحميل لتوزيع الطلبات.
عند وصول الطلب إلى الخادم، يتم فلترته بجدار الحماية، ثم توجيهه عبر الوكيل العكسي (مثل Nginx) إلى الخدمة المطلوبة.
معالجة الطلب:
يقوم إطار العمل الخلفي (Backend Framework) بمعالجة الطلب وإعداد الاستجابة (Response).
إرجاع الاستجابة:
تعود الاستجابة عبر نفس المسار إلى المتصفح.
يقوم المتصفح بعرض المحتوى وتنفيذ أي JavaScript أو عمليات أخرى.
وبذلك تنتهي دورة حياة الطلب.
عند إدخال رابط في المتصفح، تبدأ رحلة الطلب (Request) كالتالي:
تحويل الرابط إلى عنوان IP:
المتصفح يسأل خدمة DNS عن عنوان الـ IP الخاص بالرابط.
بعد الحصول على الـ IP، يتم تخزينه مؤقتًا (Cache) لفترة قصيرة.
فتح اتصال مع الخادم:
يتم استخدام الـ IP لإنشاء اتصال TCP مع الخادم.
إذا كان الاتصال HTTPS، يتم استخدام بروتوكول TLS لتشفير الاتصال.
إعداد الطلب:
يتم تحديد طريقة الطلب (مثل GET).
تضاف الرؤوس (Headers) التي تحتوي على معلومات مثل الكوكيز ونوع البيانات.
يتم إضافة أي بيانات في الجسم (Body) إذا لزم الأمر.
إرسال الطلب:
قد يمر الطلب عبر خدمات مثل Cloudflare للحماية، أو موازن تحميل لتوزيع الطلبات.
عند وصول الطلب إلى الخادم، يتم فلترته بجدار الحماية، ثم توجيهه عبر الوكيل العكسي (مثل Nginx) إلى الخدمة المطلوبة.
معالجة الطلب:
يقوم إطار العمل الخلفي (Backend Framework) بمعالجة الطلب وإعداد الاستجابة (Response).
إرجاع الاستجابة:
تعود الاستجابة عبر نفس المسار إلى المتصفح.
يقوم المتصفح بعرض المحتوى وتنفيذ أي JavaScript أو عمليات أخرى.
وبذلك تنتهي دورة حياة الطلب.
❤1
اتعلمت tailwind بعد ال bootstrap وبيواجهك مشكلة ال Components الجاهزة وبتحتاج تعمل كل حاجة ب ايدك
الحل في flowbite
https://flowbite.com/docs/getting-started/introduction/
ده موقع جاهز بيقدملك Components جاهزة ويعتبر شبه bootstrap في كل اللي بتحتاجة وبيدعم معظم ال framework
كل اللي محتاجة تمشي علي ال documentation وهيعتبر كانك مستخدم bootstrap
الحل في flowbite
https://flowbite.com/docs/getting-started/introduction/
ده موقع جاهز بيقدملك Components جاهزة ويعتبر شبه bootstrap في كل اللي بتحتاجة وبيدعم معظم ال framework
كل اللي محتاجة تمشي علي ال documentation وهيعتبر كانك مستخدم bootstrap
GET، POST، PUT، DELETE... دي قائمة بأشهر "الأفعال" في HTTP في مخطط واحد. هتلاقي الطريقة لتحميل ملف PDF عالي الدقة في الآخر.
HTTP GET
الطلب ده بيجيب مورد من السيرفر. مفيش مشكلة لو طلبته كذا مرة، النتيجة بتبقى هي هي.
HTTP PUT
الطلب ده بيحدث أو ينشئ مورد. يعني لو طلبته كذا مرة، هيحدث نفس المورد ومش هيعمله مرتين.
HTTP POST
الطلب ده بيتعمل لإنشاء موارد جديدة. ممكن لو طلبته مرتين، يعمل نفس المورد مرتين.
HTTP DELETE
الطلب ده بيمسح مورد. حتى لو طلبته كذا مرة، هيمسح نفس المورد.
HTTP PATCH
الطلب ده بيعمل تعديلات جزئية على مورد معين.
HTTP HEAD
الطلب ده بيطلب استجابة شبه GET بس من غير جسم الاستجابة.
HTTP CONNECT
الطلب ده بيعمل قناة اتصال (نفق) للسيرفر اللي اتحدد بواسطة المورد المستهدف.
HTTP OPTIONS
الطلب ده بيشرح الخيارات المتاحة للتواصل مع المورد المستهدف.
HTTP TRACE
الطلب ده بيعمل اختبار رجوع للرسالة على طول المسار للمورد المستهدف.
HTTP GET
الطلب ده بيجيب مورد من السيرفر. مفيش مشكلة لو طلبته كذا مرة، النتيجة بتبقى هي هي.
HTTP PUT
الطلب ده بيحدث أو ينشئ مورد. يعني لو طلبته كذا مرة، هيحدث نفس المورد ومش هيعمله مرتين.
HTTP POST
الطلب ده بيتعمل لإنشاء موارد جديدة. ممكن لو طلبته مرتين، يعمل نفس المورد مرتين.
HTTP DELETE
الطلب ده بيمسح مورد. حتى لو طلبته كذا مرة، هيمسح نفس المورد.
HTTP PATCH
الطلب ده بيعمل تعديلات جزئية على مورد معين.
HTTP HEAD
الطلب ده بيطلب استجابة شبه GET بس من غير جسم الاستجابة.
HTTP CONNECT
الطلب ده بيعمل قناة اتصال (نفق) للسيرفر اللي اتحدد بواسطة المورد المستهدف.
HTTP OPTIONS
الطلب ده بيشرح الخيارات المتاحة للتواصل مع المورد المستهدف.
HTTP TRACE
الطلب ده بيعمل اختبار رجوع للرسالة على طول المسار للمورد المستهدف.