قاعدة بياناتنا المونوليثية كانت قنبلة موقوتة: كيف أنقذنا ‘التقسيم’ (Sharding) من جحيم عنق الزجاجة؟

أذكرها وكأنها البارحة، كانت ليلة خميس، والكل يستعد لنهاية الأسبوع. أنا كنت في البيت، أحاول أنسى هم الشغل وأشرب فنجان شاي بالمرمية على البرندة. فجأة، التلفون “بزّ” كأنه نحلة زنّانة.. تنبيهات من نظام المراقبة، رسائل “سلاك” من الفريق، الدنيا قايمة قاعدة. موقعنا “نبض” – وهو منصة اجتماعية كنا نبنيها بدم قلبنا – كان يحتضر.

وصلت المكتب، لقيت الشباب وجوههم صفرا. “شو القصة يا جماعة؟” سألت وأنا بفتح اللابتوب. الجواب كان متوقع ومخيف بنفس الوقت: “أبو عمر، الداتابيز.. الداتابيز مش مستجيبة. كل شي بطيء، والـ CPU usage 100% طول الوقت”.

الله وكيلكم، شعور العجز في هذيك اللحظة كان قاتل. قاعدة بياناتنا الـ PostgreSQL الوحيدة، اللي كانت فخرنا وقوتنا، تحولت فجأة إلى وحش مونوليثي (Monolithic) وخصم عنيد. كانت زي سيارة حاطين فيها موتور طيارة، كبرت وصارت أضخم وأثقل من اللازم، لحد ما بطلت قادرة تمشي. كل محاولاتنا لتحسين الاستعلامات (Query Optimization) وزيادة الموارد (Vertical Scaling) كانت زي اللي بحط لصقة جروح على كسر كبير. كانت مجرد مسكنات مؤقتة، والقنبلة الموقوتة كانت بتعد تنازليًا.. وفي هذيك الليلة، انفجرت.

في خضم الفوضى، وقفت قدام الوايت بورد وكتبت كلمة واحدة: Sharding. نظر إليّ الفريق بنظرة فيها أمل وتساؤل. كانت هذه بداية رحلة طويلة وصعبة، لكنها أنقذت مشروعنا من جحيم عنق الزجاجة. تعالوا أحكي لكم القصة بالتفصيل التقني.

ما هو الـ ‘التقسيم’ (Sharding) وليش أصلاً بنحتاجه؟

قبل ما نغوص في التفاصيل، خلينا نبسّط المفهوم. تخيل عندك مكتبة ضخمة فيها كل كتب العالم (هاي هي قاعدة بياناتك المونوليثية). مع الوقت، صارت المكتبة مزدحمة جدًا، والناس بتستنى ساعات عشان تلاقي كتاب، وأمين المكتبة المسكين (سيرفر قاعدة البيانات) مش ملاحق على الطلبات.

هنا بيجي حلين:

1. التوسع العامودي (Vertical Scaling): بتجيب أمين مكتبة خارق، وبتبني طوابق جديدة للمكتبة. يعني بتكبّر نفس السيرفر (بتزيد الـ CPU والـ RAM). هذا حل كويس، بس له حدود، وبيصير مكلف جدًا، وفي النهاية راح توصل للحد الأقصى.
2. التوسع الأفقي (Horizontal Scaling): بدل ما تكبّر نفس المكتبة، بتقرر تفتح فروع صغيرة للمكتبة في كل حي. كل فرع (بنسميه Shard أو قطعة) مسؤول عن جزء من الكتب (مثلًا، فرع لكتب العلوم، وفرع لكتب الأدب). هذا هو جوهر الـ Sharding.

الـ Sharding هو نوع من التوسع الأفقي على مستوى البيانات. بدل ما نحط كل بياناتنا في قاعدة بيانات واحدة ضخمة، بنوزعها على قواعد بيانات متعددة وصغيرة (Shards). كل Shard هو قاعدة بيانات مستقلة بذاتها، لها مواردها الخاصة. وبهيك، بدل ما الضغط كله يكون على سيرفر واحد، بيتوزع على كل السيرفرات هاي.

متى تعرف إنك محتاج Sharding؟

هذا سؤال مهم جدًا. الـ Sharding مش لعبة، وهو حل معقد له تكلفته. لا تفكر فيه إلا لما تكون استنفدت كل الحلول الأبسط:

• تحسين الاستعلامات (Query Optimization): هل كل استعلاماتك سريعة وتستخدم Indexes صح؟
• التخزين المؤقت (Caching): هل تستخدم Redis أو Memcached لتقليل الضغط على قاعدة البيانات؟
• النسخ المتماثلة للقراءة (Read Replicas): هل عندك نسخ من قاعدة البيانات مخصصة لعمليات القراءة فقط لتخفيف الحمل؟

إذا عملت كل هاد، وما زلت تعاني من بطء في عمليات الكتابة (Write Operations)، وحجم بياناتك صار ضخم لدرجة إنه النسخ الاحتياطي والصيانة صاروا كابوس.. إذن، أهلًا بك في عالم الـ Sharding.

أنواع التقسيم: كيف نختار الطريقة الصح؟

لما قررنا نمشي بطريق الـ Sharding، أول سؤال كان: “كيف بدنا نقسم البيانات؟”. اختيار استراتيجية التقسيم هو أهم قرار راح تاخده، لأنه صعب جدًا تغييره بعدين. فيه ثلاث طرق مشهورة:

1. التقسيم القائم على النطاق (Range-Based Sharding)

الفكرة بسيطة: بتقسم البيانات بناءً على نطاق معين. مثلًا، لو بتقسم بيانات المستخدمين حسب أول حرف من اسمهم:

• Shard 1: المستخدمون اللي بتبدأ أسماؤهم من A إلى F.
• Shard 2: المستخدمون اللي بتبدأ أسماؤهم من G إلى M.
• Shard 3: المستخدمون اللي بتبدأ أسماؤهم من N إلى Z.

ميزته: سهل الفهم والتطبيق. الاستعلامات اللي بتطلب نطاق معين (مثل “أعطيني كل المستخدمين بين A و C”) بتكون سريعة جدًا لأنها بتروح لـ Shard واحد بس.

عيوبه: مشكلة الـ Hotspots. تخيل لو أغلب مستخدمينك الجداد أسماؤهم بتبدأ بحرف ‘M’ لسبب ما. راح يصير كل الضغط على Shard 2، بينما باقي الـ Shards فاضية. هيك بنكون ما حلينا المشكلة، بس نقلناها لمكان ثاني.

2. التقسيم القائم على التجزئة (Hash-Based Sharding)

هاي الطريقة اللي اخترناها في مشروع “نبض”. الفكرة إنك بتاخد “مفتاح التقسيم” (Shard Key) – وهو حقل فريد لكل سجل، مثل `user_id` – وبتطبق عليه دالة تجزئة (Hash Function). ناتج الدالة هاي هو اللي بحدد السجل هاد لأي Shard يروح.

المعادلة البسيطة هي: shard_id = hash(shard_key) % number_of_shards

مثال بالكود (Pseudo-code):

function find_shard_for_user(user_id, num_shards):
  // استخدم دالة hash بسيطة للتوضيح
  hashed_value = simple_string_hash(user_id) 
  
  // معامل الباقي بضمن انه الناتج بين 0 و (num_shards - 1)
  shard_index = hashed_value % num_shards
  
  return shard_index

// مثال: عندنا 4 شاردات
// user_123 -> hash -> 87654 -> % 4 -> 2  (يروح لـ Shard 2)
// user_456 -> hash -> 98765 -> % 4 -> 1  (يروح لـ Shard 1)

ميزته: بيوزع البيانات بشكل عشوائي ومتساوي جدًا على كل الـ Shards. هاد بيمنع مشكلة الـ Hotspots بشكل كبير، لأن المستخدمين الجداد راح يتوزعوا بالتساوي.

عيوبه: الاستعلامات اللي بتعتمد على نطاق بتصير كابوس. لو بدك تجيب “كل المستخدمين اللي سجلوا بين تاريخ كذا وكذا”، لازم تسأل كل الـ Shards وتجمع النتائج، وهذا بطيء.

3. التقسيم القائم على الدليل (Directory-Based Sharding)

هنا بيكون عندك “خريطة” أو “دليل” مركزي. هاي الخريطة عبارة عن جدول بسيط بخزّن لكل مفتاح تقسيم (Shard Key) وين الـ Shard المناسب له. لما يجي طلب جديد، التطبيق بيسأل الدليل أولًا “وين أخزن/أقرأ بيانات user_123؟”، والدليل بجاوبه “في Shard رقم 4”.

ميزته: مرونة خرافية. بتقدر تنقل البيانات بين الـ Shards بسهولة، بس بتحدّث الدليل. بدك تضيف Shard جديد؟ سهل جدًا.

عيوبه: الدليل نفسه ممكن يصير عنق زجاجة (Bottleneck) أو نقطة فشل وحيدة (Single Point of Failure). إذا وقع سيرفر الدليل، كل النظام بيوقع.

رحلتنا في تطبيق الـ Sharding: خطوات عملية ونصائح من الميدان

بعد ما درسنا الخيارات، قررنا نستخدم الـ Hash-Based Sharding. هاي كانت خطواتنا العملية والدروس اللي تعلمناها:

الخطوة الأولى: اختيار مفتاح التقسيم (Shard Key) بحكمة!

هذا أهم قرار على الإطلاق. نصيحة أبو عمر: اقضوا 80% من وقت التخطيط في اختيار الـ Shard Key. إذا اخترته غلط، الله يعينك.

مواصفات الـ Shard Key الجيد:

• عالي الكاردينالية (High Cardinality): يعني فيه قيم فريدة كثيرة جدًا (مثل `user_id` أو `post_id`). لا تستخدم حقل مثل `country`، لأنه له عدد محدود من القيم وممكن يسبب Hotspots.
• غير قابل للتغيير (Immutable): لا تختار حقل ممكن يتغير، مثل `email`. لو تغير، بدك تنقل كل بيانات المستخدم من Shard لآخر، وهذا كابوس.
• يجمع البيانات المترابطة: أهم نقطة! حاول تختار مفتاح يضمن إنه كل البيانات اللي غالبًا بتحتاجها مع بعض تكون في نفس الـ Shard. في حالتنا، اخترنا `user_id`. هيك، كل بيانات المستخدم (بروفايله، منشوراته، تعليقاته) بتكون في نفس ال-Shard. هاد بخلّي 95% من استعلاماتنا تروح لـ Shard واحد بس.

الخطوة الثانية: استراتيجية الترحيل (Migration Strategy) بدون توقف

ما بنقدر نحكي للمستخدمين “يا جماعة، الموقع راح يوقف أسبوع عشان بنعمل صيانة”. كان لازم نعمل الترحيل والنظام شغال. اتبعنا هالخطة:

1. الإعداد: جهزنا البنية التحتية الجديدة (4 سيرفرات PostgreSQL جديدة لتكون الـ Shards تبعتنا).
2. الكتابة المزدوجة (Dual Write): عدّلنا الكود تبعنا بحيث إنه أي عملية كتابة جديدة (مستخدم جديد، منشور جديد) تنكتب في قاعدة البيانات القديمة المونوليثية و في الـ Shard الجديد الصحيح. هاي مرحلة خطيرة وبتحتاج مراقبة شديدة.
3. الترحيل الخلفي (Backfill): كتبنا سكربتات تشتغل في الخلفية، وظيفتها تقرأ البيانات القديمة من المونوليث، تحدد الـ Shard الصحيح إلها، وتنسخها هناك. هاي العملية أخذت أيام.
4. التحقق والمطابقة: بعد ما خلص الـ Backfill، كتبنا سكربتات ثانية عشان تتأكد إنه البيانات في المونوليث والـ Shards متطابقة 100%.
5. تحويل القراءة: بدأنا نحول عمليات القراءة تدريجيًا. في البداية 1% من المستخدمين بيقرأوا من الـ Shards، بعدين 10%، 50%، لحد ما صار 100% من القراءة بتيجي من الـ Shards.
6. الخطوة الأخيرة: بعد ما تأكدنا إنه كل شي تمام لمدة أسبوع، أوقفنا الكتابة على المونوليث. وهذيك اللحظة، لما حذفنا كود الكتابة المزدوجة، كانت لحظة احتفال. أخيرًا، تخلصنا من الوحش.

الخطوة الثالثة: التعامل مع الاستعلامات عبر الشاردات (Cross-Shard Queries)

هاي أكبر تحدي في عالم الـ Sharding. بما إنه اخترنا `user_id` كمفتاح، أي استعلام بيطلب بيانات مستخدم معين بيكون سهل وسريع. لكن ماذا عن استعلام مثل “أعطيني أكثر 10 منشورات حصلت على إعجابات اليوم”؟

هذا الاستعلام لازم يروح لكل الـ Shards، كل Shard يجيب أكثر 10 عنده، وبعدين طبقة التطبيق (Application Layer) تجمع كل النتائج هاي (مثلًا 40 منشور من 4 Shards) وترتبهم مرة ثانية عشان تطلع بالـ 10 الأوائل على مستوى النظام كله. هذا الأسلوب اسمه Scatter-Gather، وهو مكلف وبطيء.

نصيحة من خبرة: صمم نظامك من الأول عشان يتجنب الاستعلامات عبر الشاردات قدر الإمكان. إذا لقيت حالك محتاجها كثير، فهذا مؤشر إنه الـ Shard Key تبعك يمكن غلط، أو إنك محتاج حلول مساعدة مثل استخدام قاعدة بيانات منفصلة للتحليلات (Data Warehouse).

تحديات ومحاذير.. مش كل إشي وردي

رحلة الـ Sharding كانت ناجحة، لكنها ما كانت سهلة. لازم تكونوا صريحين مع أنفسكم بخصوص التعقيدات اللي بتجيبها معها:

• التعقيد التشغيلي (Operational Complexity): بدل ما تدير قاعدة بيانات واحدة، صرت تدير 5 أو 10 أو 100. النسخ الاحتياطي، المراقبة، تحديثات السكيما.. كل شي صار أصعب.
• صعوبة المعاملات (Transactions): المعاملات (ACID Transactions) اللي بتمتد عبر أكثر من Shard شبه مستحيلة أو معقدة جدًا. بدك تبدأ تفكر بأنماط مثل Sagas.
• إعادة التقسيم (Re-sharding): ماذا لو الـ 4 Shards تبعونا صار عليهم ضغط؟ كيف بنضيف Shard خامس؟ هاي عملية معقدة جدًا وبتحتاج تخطيط دقيق (Consistent Hashing هو أحد الحلول لهالمشكلة).
• تطوير أصعب: المبرمج الجديد اللي بنضم للفريق ما عاد يقدر يكتب استعلام SQL بسيط. لازم يفهم منطق الـ Sharding ويعرف وين لازم يروح كل استعلام.

الخلاصة: متى تمد إيدك على الـ Sharding؟ 🏁

الـ Sharding أداة قوية جدًا، لكنها مثل المطرقة الثقيلة، لا تستخدمها إلا لما تكون محتاجها فعلًا، وإلا راح تكسر أصابعك. قبل ما تقفز لهذا الحل، اسأل نفسك بصدق:

1. هل حسّنت كل استعلاماتي واستخدمت Indexes بشكل مثالي؟
2. هل استنفدت حلول التخزين المؤقت (Caching) لتخفيف ضغط القراءة؟
3. هل استخدمت Read Replicas لتوزيع حمل القراءة؟
4. هل فكرت في التوسع العامودي (شراء سيرفر أقوى) وهل وصلت حده؟

إذا كان جوابك “نعم” على كل ما سبق، وما زالت قاعدة بياناتك هي عنق الزجاجة، خصوصًا في عمليات الكتابة، إذن فقد حان الوقت لترويض الوحش وتبدأ رحلتك مع الـ Sharding.

كانت رحلة متعبة، لكنها علمتنا الكثير. حولنا قنبلة موقوتة إلى أسطول من القوارب السريعة والمنظمة. تذكروا دائمًا، الهندسة الحقيقية ليست في بناء أكثر الأنظمة تعقيدًا، بل في اختيار الحل المناسب للمشكلة المناسبة في الوقت المناسب.

ما تخاف من المشاكل الكبيرة، لأنها بتجيب معها حلول كبيرة وفرص للتعلم. شدوا حيلكم يا شباب! 💪