مصطلحات مهمة في عالم الـ System Design 💯 (٧)
.
.
في البوست اللي فات عرفنا يعني إيه Replication و Sharding و Vertical Partitioning، وعرفنا إزاي نتعامل مع كميات ضخمة من البيانات.
لكن حتى بعد كل ده، فيه سؤال مهم...
هل كل Request لازم يروح للـ Database؟
تخيل إن الصفحة الرئيسية في موقعك بيدخلها مليون مستخدم في اليوم، وكلهم تقريبًا بيطلبوا نفس البيانات.
هل منطقي إننا في كل مرة نروح نسأل الـ Database عن البيانات دي من أول وجديد؟
أكيد لا...
لأن حتى أسرع Database لها حدود، وكل قراءة زيادة معناها ضغط أكبر، واستهلاك أعلى للموارد.
———
📌 Caching
الـ Cache عبارة عن مكان بنخزن فيه البيانات اللي بنستخدمها بشكل متكرر، بحيث لما حد يطلبها مرة تانية، نرجعها بسرعة بدل ما نروح لقاعدة البيانات.
لو فيه عندك بيانات ثابتة معظم الوقت، ومبيحصلش عليها تغييرات كتير، فمش منطقي إن كل Request يروح للـ Database.
أول Request لو البيانات مش موجودة في الـ Cache وده اسمه (Cache Miss)، يجيبها من الـ Database ويحفظها في الـ Cache، وبعدها الطلبات التالية تعمل Cache Hit.
وده واحد من أهم الأسباب اللي بتخلي التطبيقات تكون سريعة الاستجابة، وفي نفس الوقت بيقلل الضغط على قاعدة البيانات.
لكن استخدام الـ Cache مش بيحل كل المشاكل.
———
📌 Denormalization
فاكر لما تكلمنا عن SQL Databases؟
وقتها قلنا إننا بنقسم البيانات على جداول مختلفة، علشان نقلل تكرار البيانات ونحافظ عليها منظمة.
وده فعلًا أفضل تصميم في حالات كتير.
لكن مع زيادة عدد المستخدمين، ممكن تلاقي إنك كل مرة تعرض صفحة واحدة، محتاج تعمل Join بين 4 أو 5 جداول.
وده بيكلف قاعدة البيانات وقت ومجهود مع كل Request.
هنا بعض الأنظمة بتاخد قرار مختلف.
بدل ما تمنع تكرار البيانات، تسمح بتكرار جزء منها، مقابل إن القراءة تبقى أسرع.
يعني مثلًا، بدل ما كل مرة تجيب اسم المستخدم من جدول Users، ممكن تخزن اسمه داخل جدول Orders نفسه.
أيوه... البيانات بقت مكررة.
لكن في المقابل، بقيت تقدر تجيب بيانات الأوردر في Query واحدة، من غير Joins كتير.
وده اسمه Denormalization.
لكن ليه تمن.
لأن لو اسم المستخدم تغير، هتحتاج تحدثه في أكتر من مكان.
ومن هنا تبدأ تكتشف إن الـ System Design معظمه عبارة عن Trade-offs.
كل قرار بيحل مشكلة، لكنه في المقابل بيخلق تحديات جديدة.
———
📌 CAP Theorem
بعد ما بدأنا نستخدم أكتر من Database، وعملنا Replication و Sharding، كده إحنا دخلنا عالم الـ Distributed Systems.
وفي العالم ده، فيه سؤال مهم جدًا...
هل ينفع كل السيرفرات تشوف نفس البيانات، والنظام يفضل متاح للمستخدمين، حتى لو حصلت مشكلة في الشبكة؟
للأسف... لا.
وده بالظبط اللي بتشرحه CAP Theorem.
النظرية دي بتقول إن في الأنظمة الموزعة، لو حصل Network Partition، مش هتقدر تحقق كل المميزات في نفس الوقت.
في الحالة دي، لازم تختار بين Consistency و Availability، لأن Partition Tolerance أصبحت مفروضة عليك.
فهل الأهم إن كل المستخدمين يشوفوا نفس البيانات، حتى لو بعض الطلبات هتتأخر؟
ولا الأهم إن النظام يفضل شغال ويرد على المستخدمين، حتى لو بعض البيانات تكون لسه متحدثتش في كل السيرفرات؟
علشان كده هتلاقي إن مفيش Database أو Distributed System ينفع لكل السيناريوهات.
كل واحد معمول علشان يوازن بين احتياجات مختلفة.
———
💡 الخلاصة
النهارده عرفنا 3 مفاهيم مهمين جدًا في تحسين أداء الأنظمة:
• الـ Caching: تخزين البيانات المستخدمة باستمرار في مكان أسرع، لتقليل الضغط على قاعدة البيانات.
• الـ Denormalization: تكرار جزء من البيانات لتقليل الـ Joins وتسريع عمليات القراءة.
• الـ CAP Theorem: عند حدوث Network Partition، لازم تختار بين Consistency و Availability.
———
دلوقتي بقينا نعرف إزاي نخلي الوصول للبيانات أسرع.
لكن... التطبيقات مش بتتعامل مع بيانات بس.
إيه اللي بيحصل مع الصور، والفيديوهات، والملفات؟ وهل منطقي نخزنها كلها داخل قاعدة البيانات؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Blob Storage و CDN وكمان هنتكلم عن الـ WebSockets
6July 31, 2026 1.1K 12
