VOL:20 How Uber Serves Over 40 Million Reads Per Second
أهلًا وسهلا بكم في العدد العشرين من النشرة الأسبوعية لاقرأ-تِك 🎉
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد العشرين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية, من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة, ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
How Uber Serves Over 40 Million Reads Per Second
Deep Dive Into Mailing Servers and SMTP #How it works, from an Email to Email Overview
Best Practices for Writing Clean Commits in Git
Meta New LLM Llama 3 Release
Husky Improves Your Commits and More
How Uber Serves Over 40 Millions Reads Per Second
شركة Uber بتستعمل Docstore وهو عبارة عن قاعدة البيانات الموزعة بتاعتهم واللي مبنية على MySQL و Docstore بتخزن عشرات الـ PetaBytes من البيانات وبتخدم عشرات الملايين من ال Requests في الثانية.
ودي واحدة من أكبر محركات قواعد البيانات عند Uber واللي بتستخدمها كتير من الـ Microservices في كل القطاعات التجارية أو اللي بنسميها Business Verticals عندهم.
والكلام ده من ساعة ما بدأت في 2020، عدد المستخدمين وحالات الاستخدام بتاعت Docstore في ازدياد، وكمان حجم الطلبات والبيانات في زيادة.
المطالب المتزايدة من القطاعات التجارية واحتياجاتهم بتضطر تقدم Microservices معقدة جدًا. وبالتالي، التطبيقات بتطلب زمن استجابة قليل Latency، وأداء عالي High Performance، وقابلية توسع من قاعدة البيانات Scalability، وفي نفس الوقت الكلام ده بيولد Workloads وأحمال عالية.
التحديات
معظم الـ Microservices في Uber بتستخدم قواعد بيانات مدعومة بتخزين على الـ Disk عشان تحافظ على البيانات والـ Durability بتاعتها. ومع ذلك، كل قاعدة بيانات بتواجه تحديات في خدمة التطبيقات اللي بتحتاج زمن استجابة قليل وقدرة توسع عالية.
ده وصل لدرجة الأزمة لما في حالة من الحالات طلبت معدل قراءة أعلى بكتير من أي مستخدم حالي. وكان ممكن Docstore تلبى احتياجاتهم لأنها مدعومة بـ NVMe SSDs، ,اللي بدورها بتوفر زمن استجابة قليل ومعدل نقل عالي. بس استخدام Docstore في الحالة دي كان هيبقى مكلف جدًا وكان هيطلب كتير من التوسع Scalability والتحديات التشغيلية اللي هي الـ Operational Challenges.
فقبل ما ندخل في التحديات، خلينا نفهم الـ High-Level Architecture لـ Docstore.
Docstore Architecture
هنلاقي أن Docstore متقسمة بشكل رئيسي لثلاث أجزاء أو طبقات Layers:
1- الـ Stateless Query Engine Layer
2- الـ Stateful Storage Engine Layer
3- الـ Control Plane
وللتذكير Stateless من اسمها يعني مش مسئولة عن الاحتفاظ بأي State نهائيًا أو معلومات ، بينما الـ Stateful فهي بتحتفظ بالـ State أو بعض المعلومات عشان تستفيد منها في أداء شغلها.
واحنا هنركز كلامنا فقط على الجزئين الأول والثاني من الـ 3 طبقات دول.
الـ Stateless Query Engine مسئول بشكل أساسي عن الـ Query Planning والـ Routing والـ Sharding والـ Schema Management وكمان الـ Node Health Monitoring والـ Request Parsing والـ Validation والـ AuthN/AuthZ.
والـ AuthN اللي هي اختصار لـ Authentication والـ AuthZ اختصار للـ Authorization.
بينما الـ Stateful Storage Engine مسئول بشكل أساسي عن تحقيق الـ Consensus من خلال Raft وده طبعًا بيتم استعماله بشكل أساسي في النظم الموزعة لضمان تحقيق الـ Replication بكفاءة واتساق البيانات أو ما يعرف بالـ Consistency.
والـ Storage Engine كذلك مسئول عن الـ Replication والـ Transactions والـ Concurrency Control والـ Load Management.
وزي ماحنا شايفين في الصورة احنا عندنا أكتر من Partition كل جزء بيكون عبارة عن بعض الـ MySQL Nodes مدعومة بـ NVMe SSDs واللي قادرة على انها تتحمل الأحمال الثقيلة في القراءة والكتابة Heavy Read and Write Workloads.
البيانات متقسمة على أكتر من جزء وكل جزء بيكون فيه Leader واحد , و 2 Follower وطبعا من خلال استعمال Raft لتحقيق الـ Consensus.
التحديات لما الخدمات بتطلب قراءات بزمن استجابة قليل وبمعدل عالي:
سرعة استرجاع البيانات من الـ Disk ليها حد: في حد لتحسين الـ Data Models والـ Queries عشان نحسن زمن الاستجابة والأداء. ولكن بعد كده، هنوصل لحيطة سد وده لان تحسين الأداء أكتر من كده مش هيبقى ممكن.
التوسع الرأسي Vertical Scaling: تخصيص موارد أكتر أو استخدام أجهزة أفضل هيكون برضو ليها حدود واللي وقتها هيكون محرك قاعدة البيانات بنفسه هو الـ Bottleneck.
التوسع الأفقي Horizontal Scaling: تقسيم البيانات على مزيد من الأجزاء ممكن يساعد بشكل ما أو بآخر ولكن برضو هيكون محدود وهيبقى عملية معقدة وطويلة. وده لاننا لازم نضمن استمرارية الـ Durability والـ Resilience للبيانات من غير أي Downtime يحصل. وكمان الحل ده مش بيحل المشكلة بالكامل وهيعرضنا لمشاكل تانية زي الـ Hot Keys/Shards/Partitions.
اختلال التوازن بين الـ Requests: كتير من الأحيان معدل طلبات القراءة بيكون أعلى بكتير من الكتابة. في الحالات دي، الـ MySQL Nodes الأساسية بتكافح عشان تواكب الحمل الثقيل اللي متعرضة ليه وده بيأثر على زمن الاستجابة Latency.
التكلفة: التوسع الرأسي والأفقي لتحسين زمن الاستجابة مكلف على المدى الطويل. والتكاليف دي بتتضاعف 6 مرات عشان تتعامل مع كل من الـ 3 Nodes في الـ Regions المختلفة. وكمان، التوسع مش بيحل المشكلة بالكامل.
عشان نحل المشكلة دي، الـ Microservices بتستخدم الـ Caching. وفي Uber بيستعملوا Redis™ كـ Distributed Caching ، ومن أشهر الـ Design Patterns اللي بيتم تطبيقها في الـ Microservices هي الكتابة لقاعدة البيانات والـ Cache في نفس الوقت وتقديم طلبات القراءة Read Request Serving من الـ Cache لتحسين زمن الاستجابة Latency. بس برضو النموذج ده ليه بعض التحديات:
كل فريق لازم يخصص ويـ Maintain الـ Cache Redis الخاص بيه للـ Services بتاعته.
الـ Cache Invalidation Logic متنفذ بشكل لا مركزي في كل الـ Microservices لان كل فريق هيكون مسئول عنه.
في حالة حدوث مشكلة في الـ Region وحصل Failover، الـ Services لازم يا اما تحتفظ بنسخ الـ Cache عشان تكون مستعدة لأي عمليات قراءة تحصل أو تتحمل زمن استجابة أعلى Higher Latencies لغاية مالـ Cache يكون مستعد في الـ Regions التانية اللي هيحصلها الـ Failover.
الفرق الفردية بتبذل مجهود كبير في تنفيذ الـ Caching Solutions الخاصة بيهم مع قاعدة البيانات. ولكن أصبح من الضروري إننا نلاقي حل أفضل وأكثر كفاءة عشان يـ Handle الطلبات بزمن استجابة قليل، ويكون سهل الاستخدام ويزيد كمان من إنتاجية المطورين.
CacheFront
فـ Uber قررت تبني Integrated Caching Solution وهو CacheFront لـ Docstore، وحطوا شوية أهداف لتحقيق ده:
تقليل الحاجة للتوسع الرأسي أو الأفقي لدعم طلبات القراءة بزمن استجابة قليل.
تقليل تخصيص الموارد أو الـ Resources للـ Database Engine Layer؛ الـ Caching ممكن يتبني من أجهزة رخيصة نسبيًا، وبالتالي كفاءة التكاليف الكلية تتحسن كتير.
تحسين زمن الاستجابة P50 وP99، وتثبيت استقرار زمن الاستجابة خلال الـ Spikes اللي بتحصل في الفترات القصيرة من الضغط.
استبدال معظم الـ Caching Solutions المخصصة اللي كانت بنيتها أو هتبنيها الفرق الفردية لتلبية احتياجاتها، خاصة في الحالات اللي الـ Caching مش هو النشاط الأساسي أو الكفاءة الأساسية للفريق.
تحقيق الـ Transparency من خلال إعادة استخدام الـ Docstore Client الحالي من غير أي كود إضافي عشان يستفيدوا من الـ Caching.
زيادة إنتاجية المطورين وتمكينهم من إطلاق ميزات جديدة أو استبدال تقنية الـ Caching الأساسية بشكل شفاف للعملاء.
فصل الـ Caching Solution عن نظام تقسيم Docstore الـ Partitioning عشان نتجنب المشاكل اللي بتنتج من الـ Hot Shards/Keys/Partitions.
امكانية تحقيق التوسع الأفقي للـ Caching Layer بشكل مستقل عن الـ Storage Engine.
نقل مسؤولية صيانة Redis من الفرق المختلفة لفريق Docstore.
تصميم CacheFront
Docstore Query Patterns
الـ Docstore بيدعم طرق مختلفة للـ Query إما من خلال الـ Primary Key أو الـ Partition Key مع إمكانية عمل Filtering للبيانات.
فريق مهندسين Uber قرروا يبنوا الحل بتاعهم بشكل تدريجي، بدءًا من أنماط الاستعلام الأكثر شيوعًا.
اتضح إن أكتر من 50% من الـ Queries اللي بتيجي لـ Docstore هي طلبات ReadRows، وبما إن ده كمان كان أسهل حالة استخدام فكان ده المكان الطبيعي للبدء بدمج الـ Cache.
High Level Architecture
بما إن الـ Query Engine في Docstore مسؤولة عن انها تـ Serve الـ Reads / Writes، فهي أفضل مكان مناسب لدمج الـ Caching Layer.
الشراكات - Sponsorship
جالنا الفترة اللي فاتت أسئلة من بعض الشركات انهم حابين يبقى في شراكات بينا وبينهم ، فباذن الله الفترة الجاية هنعلن عن سبل الرعاية لاقرأ-تِك من خلال المنصة والنشرة الأسبوعية كذلك وهنعلن عن المميزات اللي ممكن الشركات تحصل عليها من عمل Sponsor للنشرة الأسبوعية أو من خلال المنصة 🚀
لا تدع شيء يفوتك!
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Deep Dive Into Mailing Servers and SMTP #How it works, from an Email to Email Overview
حياتنا اليومية تكاد لا تخلوا من الـ Emails , سواء كان في الشغل أو برا الشغل ، طب اي حكاية الـ Mail Server وازاي لسه لغاية دلوقتي ما بنعرفش نحذف الـ Emails بعد اما بنبعتها ؟!
ده اللي هنعرفه من خلال المقال ده ، فهنتعرف علي الـ SMTP وازاي بيشتغل ووقتها هنفهم ليه مش بنقدر نحذف الـ Emails اللي بنبعتها.
Sending Emails Workflow
لما بنيجي نبعت أي Email لحد ، الـ Email بيلف ف رحلة لذيذة متوضحة ف الرسمه اللي تحت دي:
الـ MUA هو الـ Client App اللي انت بتبعت منه أو بتشوف عليه الـ Email ومش لازم يكون موجود ف الـ Flow علشان نقدر نبعت Email ، ولكن نقدر نعتبره هو الواجهة اللي بنتعامل من خلالها زي Outlook أو الـ Gmail على سبيل المثال.
فعادي جدًا ممكن نتكلم مع الـ Mail Server باستعمال الـ SDKs وده على سبيل المثال عشان نقدر نبعت Transactional Emails او Marketing Emails.
Best Practices for Writing Clean Commits in Git
مفيش يوم بيعدي تقريبًا الا وفيه Commits محتاجين نعملها على الـ Version Control في مشاريع مختلفة , وده خصوصا لو احنا شغالين في شركة أو مع مطورين تانيين في أي مشروع.
وعشان نستفيد من الـ Version Control أقصى استفادة ممكنة وانه يكون بيحقق الغرض المطلوب منه ويسهل علينا حياتنا محتاجين نعرف ازاي نكتب Commits بشكل فعال عشان نحقق ده.
في المقال ده هنعرف مع بعض ايه اللي خصائص الـ Commits الكويسة وايه هي الـ Best Practices اللي موجودة لكتابة الـ Commits لانها بالتأكيد هتفرق في الـ Career بتاعك.
ايه هو الـ Commit ؟
قبل ما نبدأ ونتكلم عن الـ Best Practices لكتابة الـ Commit محتاجين نعمل Refreshing سريع كده ونعرف اصلا ايه ده ؟
الـ Commit بيعبر عن حالة التغييرات بتاعتك في وقت محدد , فلو جينا نعمل Commit مثلا في Codebase معين .. الـ Commit هو بيوصف الحالة اللي فيها الـ Codebase ده في الوقت ده , ولحد ما يحصل Commit تاني , فالـ Commit التاني ده هيوصف الحالة اللي اصبح عليها الـ Codebase في الوقت اللي هيحصل فيه وهكذا.
والـ Commits طبعًا ممكن تشتمل على حاجات كتير زي Metadata وليكن الرسالة اللي مفروض الـ Commit يظهرها واسم صاحب الـ Commit والوقت , وكل ده بيتم استعماله عشان نعرف نحدد التغييرات اللي حصلت في النظام كانت ايه وحصلت امتة بشكل مؤرخ.
Best Practices for Writing Commits
تكون مُوصفة - Descriptive
الـ Commit Message اللي بنكتبها محتاجين انها تكون مُوصفة يعني بتشرح التغيير اللي حصل وحصل ليه , ومفترض انها تكون بتقدم لأي حد يقرأها مختصر للي بيعمله التغيير عشان يفهموا التغيير ده بيعمل ايه من غير ما يضطروا يشوفوا حاجة زيادة.
لو جينا نبص على مثال لكتابة Commit مبتحققش الكلام ده , هنلاقي ان اغلبنا اتعرض لده وكلنا كنا بنكتب Commits مش موصفة وما الى ذلك .. وأغلبنا كان بيعمل كده خصوصا في مشاريعه الشخصية.
ولكن المفترض لما تيجي تشتغل مع فريق ومع ناس تانية الـ Commit كون موصف بالشكل ده
Meta New LLM Llama 3 Release
لا يزال سباق ال AI يحتدم (ولسه مقعدناش في بيوتنا ولله الحمد) وأجدد خطوة جت الاسبوع دا من Meta باعلانها عن النسخة الأحدث من Llama 3.1. ودا هو ال Large language model الخاص بيهم والمشهور مسبقا في الاوساط الخاصة بال AI كونه Open source, الجدير بالذكر إن ميتا بتدعي ان النسخة اللي تم الاعلان عنها هذا الاسبوع في نفس قوة chatgpt 4o وهي بردو open source علي عكس نظيراتها من Microsoft و Open AI واللي لو طلع الموديل فعلاً بالكفاءة اللي بتتكلم عنها ميتا فهيتضرروا جامد لأنه الكل هيروح للخيار المجاني.
ميتا وفرت الموديل في 3 أحجام باختلاف عدد ال parameters اللي بيستخدمها الموديل
النسخة الاكبر بتحتوي علي 450 مليار متغير و نسخة تستخدم 70 مليار و الأصغر تحتوي علي 8 مليار متغير فقط
واضح من أعداد المتغيرات في الموديلز دي ان مفيش جهاز شخصي يقدر يشغلهم ولذلك ميتا بتقول انك تقدر تستخدمهم علي اي Cloud provider
اطلاق الموديل دا بيثير الجدال تاني حول إتاحة AI بالقوة دي ك open source Technology وإمكانيات إساءة استخدامه بدون ضوابط ، هنحب نسمع أرائكم في الموضوع دا
Husky Improves Your Commits and More
Husky هو أداة بتشتغل مع Git Hooks والـ Git Hooks دي زي سكربتات صغيرة بتشتغل تلقائيًا في أحداث معينة في دورة حياة Git، زي لما تعمل commit أو push. الفكرة في Husky إنه بيسهّل علينا استخدام الـ Git Hooks بدون ما نضطر نكتب سكربتات معقدة أو نعمل إعدادات يدوية كتير.
ليه ممكن تحتاج Husky؟
تخيل مثلاً إنك في فريق كبير وكل واحد بيعمل commits مختلفة. ممكن تلاقي نفسك مضطر تراجع الكود كتير عشان تتأكد إنه مطابق للـ Code Style Guidelines بتاعتك. هنا ييجي دور Husky؛ ممكن تضيفه في مشروعك وتعمل إعدادات تخليه يشغل أدوات زي ESLint أو Prettier قبل ما حد يعمل commit. بكده، أي حد يحاول يعمل commit لكود مش ملتزم بالقواعد، Husky هيوقفه ويخليه يصلح الكود الأول.
إزاي تستخدم Husky؟
عشان تضيف Husky لمشروعك، كل اللي عليك تعمله إنك تضيفه في الـ devDependencies في ملف package.json بتاعك:
npm install husky --save-devبعد كده، ممكن تضيف الـ Hooks اللي عاوز تشغلها. مثلاً، لو عاوز تشغل ESLint قبل ما تعمل commit، ممكن تضيف حاجات في الـ package.json
مميزات تانية لـ Husky
الـ Flexibility والمرونة اللي بيقدمها: فتقدر تشغل أي سكربت أو أداة قبل أي حدث في Git، زي pre-push أو commit-msg.
دعم لأنظمة التشغيل المختلفة: مش هتلاقي مشكلة لو بتشتغل على Windows، macOS، أو Linux.
الـ Configuration سهلة: مش محتاج إعدادات معقدة؛ كل حاجة بتتعمل من خلال
package.json.
الخلاصة
Husky أداة قوية وبسيطة بتحسن عملية الـ Code Review وتخلي فريقك يشتغل بشكل منظم أكتر. فلو لسه مافكرتش تستخدمها، جربها في مشروعك الجاي وشوف الفرق بنفسك!
مشاركة من أحمد عطية في مجتمع اقرأ-تِك 😂
تقدروا دلوقتي تشتركوا في اقرأ-تِك بخصم الـ 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 😍
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
