DevGuide

مصطلحات مهمة في عالم الـ System Design 💯 (١٢) . . في البوست اللي فات تكلمنا عن Scalability و Throughput و ACID. النهارده هنرجع للـ Caching، لكن هنركز على نقطة مهمة: لما البيانات تتغير، إزاي نضمن إن التغيير يوصل للـ Cache والـ Database بالطريقة المناسبة؟ هل نكتب الداتا في الاتنين مباشرة؟ ولا نكتب في الـ Cache الأول ونحدّث الـ Database بعدين؟ الإجابة بتعتمد على الـ Caching Pattern اللي بنستخدمه... ——— 📌 Write-Through Cache في الـ Write-Through Cache، لما يحصل Write أو Update، التطبيق بيكتب البيانات في الـ Cache والـ Database في نفس العملية. بمعنى: Application → Cache → Database الـ Cache بيستقبل التغيير، وبعدها يكتبه مباشرة في الـ Database. الميزة هنا إن الـ Cache والـ Database بيكونوا متزامنين بشكل أفضل، لأن كل Write لازم يعدّي على الاتنين. وده بيقلل احتمالية إن الـ Cache يحتوي على بيانات قديمة بعد عملية Update. لكن فيه مقابل. كل Write بيحتاج وقت إضافي، لأننا مش بنحدّث مكان واحد فقط. كمان ممكن نكتب بيانات في الـ Cache حتى لو مش هيتم قراءتها مرة تانية. تخيل إن عندك Product Price بيتغير، والـ Application بيكتب السعر الجديد في الـCache والـDatabase فورًا. كده أي Read بعد التحديث يقدر يجيب السعر الجديد من الـ Cache. لكن لو عايزين سرعة أكبر في عمليات الكتابة، ومش مهم البيانات توصل للـDatabase في نفس اللحظة؟ هنا نستخدم Pattern مختلف. ——— 📌 Write-Behind Cache في الـ Write-Behind Cache، التطبيق بيكتب البيانات في الـCache أولًا، وبعدها الـCache يحدّث الـDatabase بشكل asynchronous. بمعنى: Application → Cache → Database Later الـApplication يقدر يكمل شغله بسرعة، من غير ما يستنى عملية الكتابة في الـDatabase تخلص. تخيل تطبيق بيستقبل عدد ضخم من تحديثات الـProduct Views. بدل ما كل View تعمل Write مباشر على الـDatabase، نقدر نكتب الـUpdates في الـCache، وبعدها نجمعها ونبعتها للـDatabase على دفعات. ده ممكن يحسّن أداء الكتابة ويقلل الضغط على الـDatabase. لكن هنا فيه Risk مهم: لو البيانات موجودة في الـCache ولسه ما اتكتبتش في الـDatabase، وحصل Cache Failure أو System Crash، ممكن نفقد التحديثات اللي متعملهاش Persist لسه. عشان كده الـ Write-Behind Cache مناسب لبعض السيناريوهات اللي تقدر تستحمل تأخير الكتابة أو فقدان جزء من البيانات، لكنه مش مناسب تلقائيًا لكل العمليات الحساسة، زي التحويلات البنكية. طيب، خلينا نفترض إن عندنا Cache كبير موزع على كذا Server. إزاي نقرر كل Key هيتخزن على أنهي Server؟ لو استخدمنا توزيع بسيط، زي: hash(key) % number_of_servers فكل حاجة هتشتغل كويس لحد ما نضيف Server جديد. ساعتها معظم الـKeys ممكن تتنقل لمكان مختلف، ونضطر نعيد توزيع كمية ضخمة من البيانات. وهنا نحتاج الـ Consistent Hashing. ——— 📌 Consistent Hashing الـConsistent Hashing طريقة لتوزيع الـKeys على مجموعة من الـServers أو الـNodes، بحيث لما Node جديدة تدخل أو Node موجودة تخرج، أقل قدر ممكن من البيانات يحتاج يتنقل. الفكرة إننا بنمثل الـNodes والـKeys على شكل دائرة اسمها Hash Ring. كل Node بتتحط في مكان على الدائرة باستخدام Hash Function، وكل Key بيتحط هو كمان في مكان معين. بعدها الـKey بيتخزن على أول Node نلاقيها وإحنا ماشيين في اتجاه معين على الـRing. لو ضفنا Node جديدة، مش كل الـKeys هتتوزع من الأول. غالبًا جزء صغير فقط من الـKeys هينتقل للـNode الجديدة. ولو Node وقعت، الـKeys اللي كانت عليها تقدر تنتقل للـNode التالية حسب قواعد التوزيع. وده مهم جدًا في الأنظمة الموزعة، خصوصًا مع: - Distributed Caches - Distributed Databases - Load Distribution - أنظمة فيها Nodes بتزيد وتقل باستمرار الميزة الأساسية إننا نقدر نعمل Scaling للـCluster من غير ما نعيد توزيع كل البيانات في كل مرة. لكن التنفيذ العملي محتاج ناخد بالنا من مشكلة اسمها Hotspots، لأن توزيع الـKeys مش دايمًا بيكون متساوي. عشان كده بنستخدم أحيانًا Virtual Nodes لتحسين توزيع البيانات والـLoad. ——— 💡 الخلاصة • الـ Write-Through Cache: الـWrite بيتكتب في الـCache والـDatabase مباشرة. • الـ Write-Behind Cache: الـWrite بيتخزن في الـCache الأول، وبعدها يتكتب في الـDatabase بشكل asynchronous. • الـ Consistent Hashing: توزيع الـKeys على Nodes مع تقليل البيانات اللي بتحتاج تتحرك لما الـCluster يتغير. لكن فيه سؤال مهم: هل تقسيم البيانات على Nodes مختلفة هو الحل الوحيد؟ ولا فيه طرق تانية لتقسيم البيانات حسب شكلها وطريقة استخدامها؟ ——— #system_design