VOL43: Redis Beyond In-Memory Database
أهلًا وسهلا بكم في العدد الثالث والأربعين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثالث والأربعين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Top 6 Caching Strategies
Tool of The Week : Redis Beyond In-Memory Database
Business First, Code Next! Part 1
HTTP Short Polling vs Long Polling vs SSE In a Nutshell
Scrum Adventures with Batman
Top 6 Caching Strategies
الـ caching يعتبر من التقنيات الأساسية اللي بتحسن أداء التطبيقات والأنظمة من خلال تخزين البيانات اللي بنحتاجها كتير في مكان قريب زي الـ Memory للوصول السريع ليها بدل ما نعمل عمليات مكلفة على الـ database أو الـ API.
فبالتالي هو بيساعد جدًا في التحسين من الـ Performance ولكن مش كل أنواع الـ Caching مناسبة لكل موقف ، وده لإنه بيعتمد بنسبة كبيرة على الـ Data Access Patterns، وكل تكنيك ليه الـ Trade-offs اللي لازم نكون مُلمين بيها عشان كدة مهم نفهم الأنواع المختلفة والسيناريوهات الأنسب لكل نوع.
Cache Hit Vs Cache Miss
قبل ما نتكلم عن الـ Caching Strategies فلازم نكون عارفين إن الـ Application لما بيلاقي الـ Data موجودة في الـ Cache فده معناه Cache Hit ولو ملقهاش فبيكون اسمه Cache Miss.
Cache Reading Strategies
الـCaching Strategies أثناء الـReading:
الـ Cache Aside
الـ Read Through
الـ Refresh Ahead
Cache Aside (Lazy Loading)
الـ Cache Aside بيشتغل بناءً على الطلب. وده اللي أغلبنا تقريبًا اتعامل معاه بشكل كبير في أي Caching Layer كان التطبيق بتاعنا محتاجها ، يعني ايه الكلام ده ؟
يعني لو التطبيق محتاج بيانات، بيحاول يجيبها من الـ cache الأول، ولو مش موجودة وبيحصل Cache Miss، بيروح للـ database أو الـ source الأساسي للبيانات، وبعد ما يجيبها يحطها في الـ cache للاستفادة بعدين وعشان كده سميناه Lazy Loading لإني بحمل البيانات أو بعملها Loading وقت الحاجة ليها عشان استفاد منها بعدين.
Read-Through Cache
في النوع ده، أي طلب للبيانات بيعدي على الـ Cache الأول بشكل تلقائي. لو البيانات موجودة في الـ Cache، بيرجعها فوراً، ولو مش موجودة، بيروح للـ Database ويجيب البيانات ويحطها في الـ Cache. بس كده الـ Cache Aside هو هواه الـ Read Through ؟
في الحقيقة لأ ، في الـ Cache Aside التطبيق هو اللي بيتحكم في الـ Cache يعني هو اللي بيدير احتياج البيانات وبيحطها في الـ Cache بعد ما يجيبها من الـ Database ولكن في الـ Read-Through الموضوع مختلف.
فالـ Read-Through الـ Cache هو اللي بيدير الموضوع ، فلو البيانات كانت موجودة هيرجعها علطول ولكن لو مش موجودة فهو بنفسه اللي هيروح يجيبها من الـ Database أو المصدر الأساسي للبيانات ، ويرجعها للتطبيق من غير ما التطبيق يتدخل في الموضوع.
Refresh-Ahead Cache
ده نوع متقدم من الـ Caching بيحاول يسبق الأحداث. يعني النظام بيحاول يجيب البيانات اللي احتمال التطبيق يحتاجها قبل ما يطلبها، عشان تبقى جاهزة في الـ Cache لما يطلبها المستخدم.
بيكون عندنا زي Refresh Factor كده وبناء عليه النظام بيبدأ يجيب البيانات اللي متوقع التطبيق يحتاجها بشكل استباقي ، فالفكرة هي إن البيانات المخزنة في الـ cache تفضل محدثة وجاهزة للاستخدام من غير ما يحصل cache miss.
Cache Writing Strategies
الـCaching Strategies أثناء الـWriting:
الـ Write Around
الـ Write Through
الـ Write Back
Redis Beyond In-Memory Database
النهارده هنتكلم عن Redis (اختصارًا لـ Remote Dictionary Server) وهي قاعدة بيانات مفتوحة المصدر تعمل في ال Memory , بنستخدمها بشكل أساسي ك Cache أو Quick-Response Database في التطبيقات التي تحتاج زمن إستجابة منخفض والسرعة فيها مهمة.
وعشان كدا Redis بتخزن البيانات بداخل الـ RAM بدلاً من ال HDD أو ال SSD واللي فرق السرعة في تخزين واسترجاع البيانات بينهم كبير جدًا.
كمان ليها استخدامات ثانية كثيرة نعرفها لأنها أداة مرنة بتخزن جميع أنواع البيانات ك Key-Value Pair وتتيح لك هياكل البيانات الأساسية واللي تقدر تستخدمها في تطبيقات متنوعة.
المميزات
أداء عالي: لأنها بتوفر زمن استجابة منخفض جدًا (ميلي ثانية) بسبب تخزين البيانات في الذاكرة.
دعم هياكل بيانات متنوعة: تدعم أنواع مثل ( Strings, Hash, bitmap, list, set) وده بيخليها مرنة للاستخدام في أنواع مختلفة من التطبيقات
قابلة للتوسع Scalable: حيث يمكن توزيعها علي عدة Nodes أو استخدام الـ Replication لضمان توفر البيانات.
التخزين الدائم: بالرغم من كونها قاعدة بيانات في الذاكرة، إلا أنها توفر خيارات تخزين مثل "snapshots" أو "Append Only File (AOF)" لحفظ البيانات بشكل دائم.
مجتمع ودعم قوي: مدعومة بمجموعة واسعة من الأدوات والمكتبات
الاستخدامات
الـ Caching: تستخدم Redis بشكل رئيسي Cache لتخزين البيانات مؤقتًا في الذاكرة. هذا يساعد في تسريع أداء التطبيقات التي تعتمد على قواعد البيانات التقليدية.
الـ Real-Time Analytics: تخزن Redis البيانات اللازمة لتحليلات الوقت الحقيقي مثل تتبع المستخدمين النشطين على موقع ما.
الـ Session Management: تُستخدم لتخزين وإدارة بيانات الجلسات (sessions) لتطبيقات الويب، مثل بيانات المستخدم أثناء تسجيل الدخول.
الـ Message Queues: يمكن استخدامها كنظام إدارة قوائم الانتظار لتنظيم المهام أو الرسائل بين المكونات المختلفة للتطبيق.
الـ Pub/Sub:تدعم Redis نموذج النشر/الاشتراك (Publish/Subscribe) لتوفير الاتصال بين الأنظمة والتطبيقات في الزمن الفعلي.
مثال عملي علي استخدامها كـ Cache
مثال:
لنفترض أن لديك موقعًا إلكترونيًا يُظهر قائمة بأحدث المقالات من قاعدة بيانات MySQL.
كيف يعمل؟
عندما يطلب المستخدم القائمة لأول مرة، يتم جلبها من MySQL وتخزينها في Redis.
الطلبات اللاحقة تحصل على البيانات من Redis بدلًا من MySQL.
Business First, Code Next! Part 1
كمطور، شغلك مش مجرد إنك تكتب كود وتنفذ الـ Feature المطلوبة. نجاحك الحقيقي بيجي لما تفهم الصورة الكبيرة ورا كل Feature: ليه اتطلبت؟ مين هيستخدمها؟ وإزاي هتأثر على المنتج ككل؟ لما تعرف الإجابات دي، هتلاقي نفسك بتاخد قرارات أذكى وتساهم بشكل مباشر في نجاح المنتج.
خلينا نتكلم عن الفكرة دي من زوايا مختلفة مع أمثلة حقيقية.
الهدف مش مجرد أضافة "Feature"، الهدف هو حل مشكلة.
كتير كمطورين بيشوف الـ Feature كحاجة مطلوب تنفيذها وخلاص. لكن الحقيقة، كل Feature وراها مشكلة بتواجه المستخدم أو فرصة لتحسين تجربته. لما تفكر في الـ Feature على إنها حل لمشكلة مش مجرد حاجة هتنضاف، هتلاقي نفسك بتاخد قرارات تقنية أذكى، وتقدر تقدم حلول مبتكرة تساهم في تحسين المنتج.
إزاي تفكر بالشكل ده؟
ابدأ بالسؤال: ليه الميزة دي مطلوبة؟ إيه المشكلة اللي بتعالجها؟
افهم التأثير: لما تبني الميزة، إيه التغيير اللي هيحصل على تجربة المستخدم أو المنتج؟
فكر في الحلول: هل الحل المطلوب هو أفضل طريقة لحل المشكلة؟ ولا ممكن تقدم طريقة أبسط وأكتر فاعلية؟
مثال واقعي:
Spotify Discover Weekly Feature
المشكلة: المستخدمين كانوا عايزين يلاقوا أغاني جديدة تناسب ذوقهم، بس عملية البحث اليدوي كانت مملة وتستغرق وقت طويل.الحل: فريق Spotify قرر يبني ميزة Discover Weekly بدل ما تكون مجرد قائمة عشوائية من الأغاني، اعتمدوا على خوارزمية بتحلل سلوك المستخدمين:
الأغاني اللي بيكررها.
القوائم اللي بيعملها.
التفضيلات الموسيقية العامة.
النتيجة: المستخدمين بدأوا يعتمدوا على الميزة أسبوعيًا، وزادت معدلات التفاعل بشكل ملحوظ. Spotify ما اكتفتش إنها تقدم ميزة جديدة، لكنها حلت مشكلة البحث عن الأغاني بطريقة مبتكرة.
الصورة الكبيرة بتخليك توازن بين الأولويات التقنية والعملية
كمطور، كتير بتلاقي نفسك في حيرة بين تقديم حل تقني مثالي أو اختيار طريق أسرع للوصول للهدف. هنا بيجي دور "الصورة الكبيرة" في تحديد أولوياتك. لما تفهم الهدف الحقيقي للـFeature وتأثيرها على المستخدم والمنتج، هتعرف توازن بين الحلول التقنية الأفضل والوقت المطلوب لظهورها في المنتج.
الحل المثالي ممكن ياخد وقت طويل جدًا يتعارض مع مواعيد التسليم.
الحل السريع ممكن ما يكونش بالجودة المطلوبة لو الهدف طويل المدى.
الصورة الكبيرة بتديك القدرة على فهم الأولويات:
هل الأهم إن الميزة تطلع بسرعة؟
ولا إن الجودة العالية هي الأساس عشان تحل مشكلة كبيرة للمستخدم؟
مثال واقعي 1
Netflix Autoplay Feature
خصم يصل إلى 40% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
HTTP Short Polling vs Long Polling vs SSE In a Nutshell
انهاردة هنتكلم عن 3 من التقنيات المهمة جدًا واللي مهم جدًا نكون عارفين الفرق بينهم اثناء تصميم Realtime Web Applications والـ 3 تقنيات دول هم الـ Long Polling , Short Polling , Server-Sent Events.
الـ Web Applications في الأساس مبنية على فكرة بسيطة الا وهي الـ Client - Server Model واللي بدوره الـ Client بيبعت Request للـ Server والـ Server يعمل Processing للـ Request ويرجع الـ Response للـ Client.
ومع تطور تطبيقات الـ Web واللي بدورها أصبحنا في احتياج أكتر للتطبيقات اللي متطلبة تحديثات دورية بتحصل بشكل فعلي يعني Realtime Applications , كان لازم نحاول نفكر بشكل مختلف في طريقة تسمحلنا نهيئ من خلالها الـ Client - Server Model اللي متعودين عليه .
فخلونا نشوف مع بعض الـ 3 تقنيات اللي جم عشان يحلوا المشكلة دي , ونتناقش في مميزات وعيوب كل تقنية منهم ونشوف امتة نستعملها.
الـ HTTP Short Polling
الـ HTTP Short Polling فكرته ببساطة عاملة زي اكنك بتكلم واحد صاحبك كل شوية تسأله عن موضوع معين مستني تعرف منه ايه اللي حصل فيه , فكل شوية تكلمه تقوله : هاا ؟ فيه اخبار جديدة ؟ ولا لسه ؟ وانت وحظك يا هيكون فيه اخبار جديدة يا مفيش .. وترجع تكلمه بعد شوية وتكرر نفس الموضوع ..
فالـ Client بيبعت Request للـ Server كل ثانية أو ثانيتين على سبيل المثال بشكل دوري وزي ما شوفنا ممكن الـ Server يرد عليه بـ Response فاضي عادي جدًا لو مفيش أي اخبار جديدة.
طيب عيوب الموضوع ده ايه ؟
عيوب الـ HTTP Short Polling
HTTP Overhead : وده لان زي ما شايفين الـ Client بشكل دوري بيفضل يبعت HTTP Requests للـ Server كل شوية , واللي بدوره بيستهلك Resources عشان بيفتح Connection وبيتضمن Headers معينة
مش مناسب للتطبيقات اللي محتاجة تكون فعلا Realtime وده لانه ميعتبرش Real-time اوي لان ممكن التغييرات تحصل في الفترة الزمنية اللي بعد مالـ Client يكلم فيها الـ Request ويرد عليه بانه مفيش أي جديد
مميزات الـ HTTP Short Polling
بسيط وسهل التنفيذ في التطبيقات ومش محتاج أي تعقيدات
مش هيتطلب أن يكون فيه Server بامكانيات معينة ومتطور عشان يحقق ده ومش هيتطلب تعديلات من وقت للتاني
استعمالات الـ HTTP Short Polling
التطبيقات اللي مش محتاج تكون فيها البيانات Realtime بشكل فعلي زي الأخبار والتحديثات الدورية , اللي ممكن يكون فيها نسبة تأخير
الـ HTTP Long Polling
خلونا نرجع لمثال صاحبك اللي بتكلمه عشان تسأله عن موضوع معين , ومستني تعرف ايه اللي حصل فيه , فخلونا نقول ان النتيجة ظهرت , وانت بتكلم صاحبك عاوز تعرف كل شوية هو عمل ايه , شوفنا مع بعض ان في الـ Short Polling كل شوية هتكلمه , وهتساله عن النتيجة .. ولكن ممكن لما تكلمه يكون النتيجة لسه مظهرتش فهو يرد عليك ان لسه مظهرتش ..
وعشان نعالج المشكلة دي في الـ Long Polling كل اللي هنعمله انك بدل ما كل شوية تكلمه وتساله عمل ايه .. هتكلمه مرة واحدة وليكن مكالمة مدتها ٥ دقايق , وتفضل سايب الخط مفتوح وتقوله اول مالنتيجة تظهر طمني , فانت كده بعت كلمته مرة واحدة بس , وهو لما باه عنده اخبار جديدة , بعتلك وقالك الاخبار دي علطول ..
فالـ Client بيبعت Request للـ Server , وهنا باه الفرق ان الـ Request ده هيفضل مفتوح بين الـ Client / Server لحد مالـ Server يبعت تحديثات للـ Client أو ان يحصل Timeout وبالتالي الـ Connection يتقفل.
Scrum Adventures with Batman
سنتناول في هذا المقال منهجية Scrum بأسلوب ممتع ومبتكر، حيث تتعلم من فريق باتمان كيفية التعاون، حل المشكلات، وتقسيم المشاريع إلى خطوات بسيطة يمكن تحقيقها بسهولة.
Meet the Scrum Team
باتمان: Scurm Master للفريق. يساعد الجميع على البقاء مركزين وحل المشكلات.
روبن: Product Owner. يقرر ما هو الأهم بالنسبة للفريق للقيام به أولاً.
بات جيرل وألفريد: Developers. يعملان معًا لبناء أدوات رائعة وحل المشكلات.
What is Scrum
منهجية Scrum هي الطريقة التي يعمل بها باتمان وفريقه معا لحل المشكلات الكبيرة. بحيث يقسمون مهمتهم إلى خطوات صغيرة وسهلة ويعملون على قطعة واحدة في كل مرة.
Example on What is Scrum Mean
مثال: بدلا من بناء Bat Mobile (عربية باتمان) بالكامل في وقت واحد ، فإنهم يقومون بما يلي:
1. بناء العجلات.
2. أضف أدوات الخفافيش.
3. رسمها باللون الأسود!
الإصدار الأول - ورقة وقلم 🚀
في الإصدار ده جمعنا أكتر من 50 موضوع في مختلف مجالات هندسة البرمجيات بأكتر من 170 صفحة + تصاميم بجودة عالية وكل ده بالعربي وبشكل مميز ومتقسم لفصول سهل تنتقلوا من فصل وموضع للتاني بدون مشاكل 💎
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
ولو عندكوا أي مشكلة في الدفع ، تقدروا تتواصلوا معانا وهنكون مبسوطين باننا نوفر بدايل زي InstaPay و VodafoneCash 🎁
ولو عاوزين تعاينوا جودة الـ E-Book قبل ما تشتروه ، تقدروا تحملوا النسخة المجانية واللي بتضم حوالي 30 موضوع فيما لايزيد عن 100 صفحة من هنا 😉
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
ما شاء الله