هنوز هیچ نظری وجود ندارد. اولین نفری باشید که نظر خود را به اشتراک میگذارید!
آخرین پستها
Yhya Nesb
۸ اردیبهشت ۱۴۰۵، ۲۰:۲۰
📷 Photo
😄
532
3
0
Yhya Nesb
۸ اردیبهشت ۱۴۰۵، ۲۰:۲۰
📷 Photo
الشعب ناطر تنرفع بشكل فعلي من الشركات 🤣 وخاصة التقنية بعض المواقع يلي ناطرينها تفتح 🔥 ب IP سوري 🙂: https://www.paypal.com/us/home https://cloud.google.com/ https://hub.docker.com/ https://www.coursera.org/ https://chatgpt.com/ https://ipinfo.io/ https://c…
678
0
Yhya Nesb
۸ اردیبهشت ۱۴۰۵، ۲۰:۲۰
📷 Photo
الإقبال على مشاريع ال Open Source يزداد يوم بعد يوم 🔥
قبل يومين الكل سمع بالمشكلة يلي صارت ب AWS وتوقف خدمات كثيرة مثل postman 🫠
هي المشكلة خلت بعض المبرمجين 👨💻 يتوجهو لتطبيق yaak كبديل ل postman بشكل مؤقت
وبيومها دخل بقائمة الترند الخاصة ب github
لكن المفاجئة هي استمراره ليومين على التوالي 🤯 وبكل يوم ال stars عم تزيد أكثر على المستودع الخاص فيه 🏆 - دليل على نجاح المشروع -
والأن ما صار الوقت لتعطي مشاريع ال open source فرصة 😉
663
3
Yhya Nesb
۸ اردیبهشت ۱۴۰۵، ۲۰:۲۰
📷 Photo
عام كامل مر بعد أن تحررت سوريا من الرجس الطائفي القذر
ليس يوماً عاديا في هذا اليوم كسرت قيود سجن صيدنايا
ارتفعت كلمة الاسلام بعد أن حاول الأسدين والعديد مع الدول معهم كتمها
هذا اليوم لم يكن ليكون لولا فضل الله علينا وتضحيات اخوتنا المجاهدين جزاهم الله خيرا وتقبل الله شهدائنا
احصائية اللغات البرمجية المستخدمة في بناء مواقع الويب من جهة السيرفر back-end ➖➖➖➖➖ للمزيد من المنشورات ♻️: تصفح قائمة المنشورات #back_end #php #python #asp_net #aspnet #dotnet #java #javascript
528
8
Yhya Nesb
۸ اردیبهشت ۱۴۰۵، ۲۰:۲۰
📷 Photo
قرار الغاء حظر خدمات Github عن الشعب السوري
https://github.com/orgs/community/discussions/159132#discussioncomment-14315880 🥲 للإلغاء بشكل فعلي
يرجى التحلي بالصبر 🫠 وعدم محاولة تجاوز الحظر من خلال خدمات ال VPN
في النهاية كل الشكر والتقدير لكل المساهمين في تسريع عملية الغاء الحظر ❤️
558
2
Yhya Nesb
۸ اردیبهشت ۱۴۰۵، ۲۰:۲۰
📷 Photo
قرار الغاء حظر خدمات Github عن الشعب السوري قد يحتاج إلى اسابيع وقد يصل إلى أشهر 🥲 للإلغاء بشكل فعلي يرجى التحلي بالصبر 🫠 وعدم محاولة تجاوز الحظر من خلال خدمات ال VPN في النهاية كل الشكر والتقدير لكل المساهمين في تسريع عملية الغاء الحظر ❤️
569
1
Yhya Nesb
۸ اردیبهشت ۱۴۰۵، ۲۰:۲۰
مشكلة قواعد البيانات N+1 Query (جزء 2)
كيف يمكن حل هذه المشكلة 🤔؟
- بشكل أساسي ويمكن استخدامه بأي برمجية تدمج النتائج لتجلب باستعلام واحد من خلال: inner join وإخواته، union، وحتى من خلال الـ subqueries؛ طب صار عنا مشكلة ثانية كود الاستعلام (SQL) جداً كبير ! كل مرة بدي كرره واكتبه 🫠، صحيح بس ال https://www.w3schools.com/sql/sql_view.asp شو عم يعمل 😁 - بس ملاحظة زكاتك 😅 ما تقول أنا هيك قلتلك تروح تدحش مليون استدعاء باستدعاء واحد 😅، يعني عادي ولو كان في 10 استعلامات بشرط ال 10 منفصلين بشكل تام، وإذا كان في حد (limit) للعرض لو رفعته ما بيزداد الرقم؛ يعني عم تعرض 10 مستخدمين إذا سويتهم 50 مستخدم بضل عدد الاستعلامات 10 -
- من خلال Laravel فيك تستخدم توابع لهل مهمة مثل with (عملية "eager load" للإستعلام بتشتغل من خلال جلب العلاقة المرفقة باستعلام منفصل وبتخزنهم بالـ memory يعني بدل ما يكون عنا n+1 استعلام بيكون عنا 1+r؛ شو قصدك ب r؟ يعني عدد العلاقات وغالباً بتكون عم تستدعي علاقة لل 10 كحد أقصى، وفي طرق بشكل تلقائي يتعرف إذا في علاقات يحمل العلاقات ك "eager load" طلعت بإصدار 12.8 بس هذا ما يعني تكب المشكلة ! ممكن تشتغل على اصدار قبل 12.8 يلي دعمت هل فكرة)
- بالخوارزميات 🌚، ممكن يكون عندك علاقات هرمية تجلب كامل البيانات المشتركة وتظبطهم ب hash table خفيف نضيف لترجعهم كبنية هرمية، مثال:
لنفترض عنا جدول تصنيفات، في تصنيفات فرعية إلى مالا نهاية (في نهاية حسب ال data type 🙃) وافترض عندك هي التصنيفات: 10 رئيسي، 20 بقلبهم، 30 بقلبهم، 40 بقلبهم
بالطريقة التقليدية والسهلة حتكون كالتالي:
نجلب التصنيفات الرئيسي (1) -> يلي بقلبهم (10) -> يلي بقلبهم (20) -> يلي بقلبهم (30) -> يلي بقلبهم (خلصوا 😂، بس بالحقيقة بدك ترجع تتأكد ان مافي شي بقلبهم !، يعني 40)
في هل الحالة انت بحاجة 246 الف و 211 استعلام ! يعني إذا الاستعلام بياخذ 0.1 ملي ثانية بدنا 24 ثانية ننتظر بس تفتح القائمة العلوية يلي فيها هل قائمة 😐 ولسا ما عرضنا شي بالموقع 😅، بينما بالخوارزميات وقت لا يقاس ! (بشرط الخوارزمية المستخدمة فعالة)
كيف ممكن القط هل مشكلة 🤔؟
- من خلال تأخر الإستجابة بشكل كبير بس تبلش قاعدة البيانات تنملأ ببيانات بتنحط كأحد الاحتمالات المسببة للبطء
- أدوات ال debug مثل laravel-debugbar يلي بتظهرلك معلومات تفصيلية للاستجابة (عدد الاستعلامات - الاستعلامات يلي صارت - سرعة تنفيذ كل استعلام - الاستعلامات المكررة)
- عمل debug بشكل يدوي للكود
Yhya Nesb
۸ اردیبهشت ۱۴۰۵، ۲۰:۲۰
📷 Photo
ب Laravel جلب قيمة واحدة من خلال تابع value أفضل من first لأسباب مهمة
طبعاً للوهلة الأولى لح تقول نفس الشي الاثنين بروجعو ايميل 🫠 ليش الفزلكة 😒
ببساطة:
بتابع first (مثل الصورة) عم تجلب كامل الصف، يعني لح تجلب أعمدة مانك بحاجتها 🌚 تؤدي لإستهلاك memory على الفاضي واستعلام أبطء
select * from `users`
🙃 ممكن تحلها بأنك تضيف العامود المطلوب ك argument للتابع حتى يجلب العامود المطلوب فقط كبديل لتابع value لكن صار الكود أطول 😅؛ نتيجة SQL
select `email` from `users`
ملاحظة: الفروقات مالح تحسها كبيرة إذا مافي استعلامات كثيرة 🫠
#laravel #php #sql
470
3
Yhya Nesb
۲۶ فروردین ۱۴۰۵، ۱۴:۴۰
كمبرمج Back-end لازم تكون سمعت بمشكلة قواعد البيانات N+1 Query وخاصة لو عم تشتغل بإطار العمل Laravel (لا تخاف منشور مختلف عن المنشور يلي كل فترة بينتشر على Linkedin 🤣)
أول شي شو نتائج هل مشكلة 🤔؟
يعني لو واجهتني شو بتكلفني 🌚؟ إذا مفكر بس استجابة أبطء 🐢 فانت أصلاً ما بتعرف المشكلة الحقيقية 😅؛ فالتكلفة هي:
- إستعلامات كثيرة على نظام قواعد البيانات 🤯، اي شو يعني؟ عادي عندي 🙂 !
عادي على Local يا صديقي 😅 بس وقت تنشر مشروعك على بيئة production ممكن يتوقف موقعك بسببها ! في بعض الإستضافات تقدملك عدد محدود من الإستعلامات بالساعة (ممكن المشروع صغير وميزانيته قليلة، مشان ما تحل المشكلة ليش لتضيف تكلفة ترقية الإستضافة ! أو الانتقل لسيرفر وتصير الميزانية اكبر بكثير !) وبس تصل للحد الأقصى بالساعة بدك تنتظر حوالي الساعة ليشتغل الموقع 😐 إذا موقع فيه دفع الكتروني وعميل شافه توقف فجاءة لا تتوقع يفكر يشوف شوفي منتجات عندك 😶
- زيادة الحمل على سيرفر قواعد البيانات، استهلاك موارد على الفاضي 😶 وخاصة لل CPU و Storage Device
- مشكلة البطء أيضاً 😅 وإذا موقعك خلال ثانيتين ما كان معروض للعميل فلح يتحول من عميل محتمل لمجرد زائر لم يصل لهدفه - تخيل أن 38% من زبائن متاجر shopify تغادر الموقع في حال لم يعرض خلال 5 ثواني ! ( https://www.shopify.com/blog/website-load-time-statistics) - ، وانت كمبرمج موجود لتحل مشكلة وحل المشكلة لازم تحاول بكل الامكانيات ان ما ترتكب مشكلة ثانية - بكل الامكانيات؟ اي نعم؛ ممكن أنت محدد ب memory معينة تضطر تعمل chunk للبيانات؛ وعدد الإستعلامات بدل N+1 يصير 1+N/200 مثلاً -
طب شو هي المشكلة بالضبط 😅؟
اولاً إذا ما بتعرف شو يعني N+1 أو O(n) فوضعك حرج 😅، بعالم الخوارزميات يلي لازم تكون متعلمه قبل ما تصير back-end 👨💻 بيتم قياس سرعة تنفيذ الخوارزمية من خلال ال Space وال Time بشيء اسمه Big O Notation، بحيث يكون معتمد عند الكل (أنك تقيس بالثانية شقد تستغرق الخوارزمية مثلاً بتكون عم تضيع وقتك 😅، لان الخوارزمية نفسها نفسها بيختلف زمن تنفيذها بحسب الهاردوير يلي شغالة عليه) ووحدات القياس هي: - من الأفضل -
O(1) - O(LogN) - O(N) - O(NLogN) - O(N^2) - O(2^N) - O(N!)
- أشهرهم، في غيرهم مثل جذر ال N - والمقصود ب N عدد التكرار الغير معروف (يعني ممكن يكون عندك حلقة تكرار لل 100 وممكن لل مليون 🫠)
أما المشكلة يلي هي N+1 فتعني استدعاء استعلام واحد يؤدي لجلب N استعلام بحسب العلاقات او الإستعلامات المرتبطة
تمام، ممكن مثال واضح للمشكلة؟ 🙂
اي لعيونك 😁 ومثالين كمان:
مثال 1: - مثال الشعب 😂 -
عنا جدول الكتب، وجدول التصنيفات والعلاقة بينهم One To One (كل قسم له كتاب وحيد) بدك تعرض هل كتب وبنفس الوقت تعرض تصنيف كل كتاب لح تجلبهم من خلال:
جلب كامل الكتب (1) -> لكل كتاب لح تجلب التصنيف الخاص به باستعلام منفصل (n)
لعرض 1000 كتاب، ستحتاج ل 1001 استعلام؛ الاستعلام يستغرق 0.1 ملي ثانية ستحتاج ل 0.1 ثانية لمعالجة جدول بسيط فقط ! (وقت قليل 🙂، مو مشكلة تابع معي المثال الثاني)
- المشكلة تواجهك بأي نوع من العلاقات ! ليست عبء على علاقة One To One -
مثال 2: - مثال حقيقي 😉 -
عنا جدول للمنتجات، جدول لمزودين المنتجات، جدول للأقسام، وجدول الاوردرات، جدول صلاحيات المستخدم ، وجدول إعدادات عامة أحد الحقول يحوي على مفتاح معين لسعر الصرف وقيمة السعر؛ تريد عرض اسم المنتج، كميته، مرات البيع، سعره الاساسي والسعر المحلي، الأقسام التابع لها؛ لح تجلبهم من خلال:
جلب المستخدم الحالي (1) + جلب كامل المنتجات (1) -> جلب المزودين (n) + جلب الأقسام (n) + جلب الكمية المباعة (n) + جلب قيمة سعر الصرف بكل مرة (n) + جلب صلاحية المستخدم الحالي (n)
لعرض 1000 منتج ستحتاج لـ (5002) الاستعلام يستغرق 0.1 ملي ثانية، ستحتاج 0.5 ثانية ! ونفرتض عم تستخدم برمجية بتاخد وقت بالمعالجة (كلوحة تحكم filamentphp التي تستغرق 0.2-0.4 ثانية للمعالجة) أنت هون لح تحتاج لقرابة الثانية فقط معالجة داخل السيرفر ! يعني لسا في زمن تحميل الصفحة بالمتصفح ومعالجتها 🫠
ملاحظة: الاستعلام يستغرق 0.1 ملي ثانية هو مجرد مثال
هذا كان الجزء الأول من المشكلة الشهيرة 😉 اسف كنت بدي ارسله كامل بس 4096 حرف مابكفو 🥲
