07 مايو 2025·8 دقيقة
كيف تعمل تجزئة قواعد البيانات — ولماذا يصعب فهمها
التجزئة توسع قواعد البيانات بتقسيم البيانات عبر عقد، لكنها تضيف توجيهًا، إعادة موازنة، وأنماط فشل جديدة تجعل الأنظمة أصعب في الفهم.
التجزئة توسع قواعد البيانات بتقسيم البيانات عبر عقد، لكنها تضيف توجيهًا، إعادة موازنة، وأنماط فشل جديدة تجعل الأنظمة أصعب في الفهم.
التجزئة (تُعرف أيضًا باسم التقسيم الأفقي) تعني أخذ ما يبدو كـ قاعدة بيانات واحدة لتطبيقك وتقسيم بياناتها عبر آلات متعددة تُسمى شاردات. كل شارد يحتوي على جزء من الصفوف، لكنَّها معًا تمثل مجموعة البيانات الكاملة.
نموذج ذهني مفيد هو الفرق بين البنية المنطقية والمكان المادي.
من وجهة نظر التطبيق، تريد تشغيل استعلامات كما لو كانت على جدول واحد. لكن تحت الغطاء، يجب على النظام أن يقرر أي شارد/شاردات يتواصل معها.
التجزئة تختلف عن التكرار. التكرار ينشئ نسخًا من نفس البيانات على عقد متعددة، أساسًا للتوافر ورفع سعة القراءة. التجزئة تقسم البيانات بحيث تكون كل عقدة لديها سجلات مختلفة.
كما أنها تختلف عن التوسيع الرأسي، حيث تحتفظ بقاعدة بيانات واحدة ولكن تنقلها إلى آلة أكبر (مزيد من CPU/RAM/أقراص أسرع). التوسيع الرأسي أبسط أحيانًا لكن له حدود عملية وقد يصبح مكلفًا بسرعة.
التجزئة تزيد السعة، لكنها لا تجعل قاعدة البيانات "سهلة" أو تسريع كل استعلام تلقائيًا.
إذن من الأفضل فهم التجزئة كطريقة لتوسيع التخزين ومعدل المعاملات—وليست ترقية مجانية لكل سلوك قاعدة البيانات.
نادرًا ما تكون التجزئة الخيار الأول. عادة ما تلجأ الفرق إليها بعد أن يصل النظام الناجح إلى حدود فيزيائية—أو بعد أن يصبح الألم التشغيلي متكررًا جدًا ليُتجاهل. الدافع ليس "نريد تجزئة" بقدر "نحتاج طريقة للنمو دون أن تصبح قاعدة واحدة نقطة فشل أو تكلفة كبيرة."
قد تنفد سعة عقدة قاعدة بيانات واحدة بطرق مختلفة:
عندما تظهر هذه القضايا بانتظام، غالبًا المشكلة ليست استعلامًا وحيدًا سيئًا—بل أن آلة واحدة تتحمل مسؤولية كبيرة جدًا.
تجزئة قواعد البيانات توزع البيانات وحركة المرور عبر عقد متعددة بحيث تنمو السعة بإضافة آلات بدلًا من ترقية واحدة رأسيًا. إذا نُفذت جيدًا، يمكنها أيضًا عزل أحمال العمل (حتى لا تُفسد قفزة أحد العملاء زمن الاستجابة للآخرين) والتحكم في التكلفة بتجنب الاعتماد على صفحات مترافعة باهظة الثمن.
أنماط متكررة تشمل ازدياد ثابت في p95/p99 أثناء الذروة، تأخر نسخ أكبر، نسخ/استعادة يتجاوز نافذة القبول، وتغييرات مخطط "صغيرة" تصبح أحداثًا كبيرة.
قبل الالتزام، تستنفد الفرق عادة حلولًا أبسط: الفهرسة وتحسين الاستعلامات، التخزين المؤقت، نسخ القراءة، التقسيم داخل قاعدة بيانات واحدة، أرشفة البيانات القديمة، وترقيات العتاد. التجزئة قد تحل مشكلات السعة، لكنها تضيف تنسيقًا وتعقيدًا تشغيليًا وأنماط فشل جديدة—لذلك يجب أن يكون الحد مرتفعًا.
قاعدة بيانات مجزأة ليست شيئًا واحدًا—بل نظام صغير من أجزاء متعاونة. سبب شعور التجزئة بأنها "صعبة الفهم" هو أن الصلاحية والأداء يعتمدان على كيفية تفاعل هذه الأجزاء، وليس فقط على محرك قاعدة البيانات.
الشارد هو مجموعة فرعية من البيانات، عادة محفوظة على خادم أو مجموعة خوادم خاصة بها. كل شارد عادةً لديه:
من وجهة نظر التطبيق، غالبًا يحاول الإعداد المجزأ الظهور كقاعدة بيانات منطقية واحدة. لكن تحت الغطاء، استعلام كان سيكون "بحث فهرس واحد" في قاعدة بيانات أحادية قد يصبح "ابحث عن الشارد الصحيح، ثم نفّذ البحث".
الموجّه (يسمَّى أحيانًا منسق، موجه استعلام، أو وكيل) هو ضابط المرور. يجيب على السؤال العملي: باستناد إلى هذا الطلب، أي شارد يجب أن يتعامل معه؟
هناك نمطان شائعان:
الموجّهون يقللون التعقيد في التطبيق، لكنهم قد يصبحون أيضًا عنق زجاجة أو نقطة فشل جديدة إذا لم يُصمموا بعناية.
التجزئة تعتمد على الميتا-داتا—مصدر الحقيقة الذي يصف:
تعيش هذه المعلومات غالبًا في خدمة تهيئة أو قاعدة بيانات "مستوى التحكم" صغيرة. إذا كانت الميتا-داتا قديمة أو غير متناسقة، قد يرسِل الموجّهون الحركة إلى المكان الخطأ—حتى لو كانت كل الشاردات صحيحة.
أخيرًا، التجزئة تعتمد على عمليات خلفية تحافظ على قابلية النظام بمرور الوقت:
هذه الوظائف سهلة التجاهل في البداية، لكنها مصدر العديد من المفاجآت الإنتاجية—لأنها تغيّر شكل النظام أثناء الخدمة.
مفتاح الشارد هو الحقل الذي يحدد أي شارد سيخزن صفًا/وثيقةً. هذا الاختيار الواحد يحدد بهدوء الأداء والتكلفة وحتى أي ميزات ستبدو "سهلة" لاحقًا—لأنه يتحكم فيما إذا كانت الطلبات تُوجَّه إلى شارد واحد أم تحتاج إلى التوسع.
مفتاح جيد عادةً ما يحتوي على:
user_id بدلًا من الدولة).مثال شائع هو التجزئة بواسطة tenant_id في تطبيق متعدد المستأجرين: معظم قراءات/كتابات مستأجر تبقى على شارد واحد، والمستأجرون كثيرون بما يكفي لوزعة الحمل.
بعض المفاتيح تكاد تضمن الألم:
حتى لو بدا حقل قليل التعدد ملائمًا للتصفية، غالبًا ما يحوّل الاستعلامات الروتينية إلى استعلامات انتشار-جمع لأن الصفوف المطابقة متفرقة.
أفضل مفتاح شارد لتوزيع الحمل ليس دائمًا الأفضل لسهولة الاستعلامات.
user_id) فسوف تبطئ بعض الاستعلامات العالمية (التقارير الإدارية) أو تتطلب أنابيب منفصلة.region) فتخاطر بنقاط ساخنة وسعة غير متساوية.تصاميم الفرق عادةً ما تهيئ نفسها حول هذه المقايضة: تحسين مفتاح الشارد للعمليات الأكثر تكرارًا وحساسية للكمون—ومعالجة الباقي عبر الفهارس، التطبيع العكسي، النسخ، أو جداول تحليلات مخصصة.
لا توجد طريقة "أفضل" واحدة لتجزئة قاعدة البيانات. الاستراتيجية التي تختارها تشكل سهولة توجيه الاستعلامات، مدى تساوي توزيع البيانات، ونوعية أنماط الوصول التي ستتأثر.
في تجزئة النطاق، كل شارد يملك شريحة متصلة من فضاء المفتاح—مثل:
التوجيه بسيط: انظر المفتاح واختر الشارد.
لكن المشكلة هي النقاط الساخنة. إذا كان المستخدمون الجدد دائمًا يحصلون على معرّفات متزايدة، يصبح الشارد "الأخير" عنق زجاجة للكتابة. تجزئة النطاق حساسة أيضًا للنمو غير المتكافئ. الجانب الإيجابي: استعلامات النطاق يمكن أن تكون فعالة لأن البيانات مجمعة ماديًا.
تجزئة الهاش تمرر مفتاح الشارد عبر دالة هاش وتستخدم النتيجة لاختيار شارد. هذا عادةً ما يوزع البيانات بشكل أكثر تساويًا، مما يساعد على تجنُّب مشكلة "كل شيء يذهب للشارد الأحدث".
المقابل: استعلامات النطاق تصبح مؤلمة. استعلام مثل "العملاء ذوو المعرفات بين X و Y" لم يعد يطابق مجموعة صغيرة من الشاردات؛ قد يلمس العديد منها.
تفصيل عملي كثيرًا ما يستهان به هو الهَش المتناسق: بدلًا من المطابقة المباشرة لعدد الشاردات (التي تعيد توزيع كل المفاتيح عند إضافة شارد)، تستخدم أنظمة كثيرة حلقة هاش مع "عُقَد افتراضية" بحيث تحرّك الإضافة قدرًا محدودًا من المفاتيح.
تجزئة الدليل تخزن خريطة صريحة (جدول/خدمة بحث) من مفتاح → موقع الشارد. هذه أكثر مرونة: يمكنك وضع مستأجرين محددين على شاردات مخصصة، ونقل عميل دون نقل الجميع، ودعم أحجام شارد غير متساوية.
العيب هو اعتماد إضافي. إذا كان الدليل بطيئًا أو قديمًا أو غير متاح، يتأثر التوجيه—حتى لو كانت الشاردات نفسها صحية.
الأنظمة الحقيقية غالبًا تمزج النهجين. مفتاح شارد مركب (مثل tenant_id + user_id) يعزل المستأجرين ويُوزّع الحمل داخل المستأجر. التقسيم الفرعي مشابه: وجه أولًا حسب المستأجر، ثم هاش داخل مجموعة الشاردات المخصصة لذلك المستأجر لتجنب سيطرة مستأجر كبير على شارد واحد.
قاعدة بيانات مجزأة لديها مساران استعلاميان مختلفان جدًا. فهم أي مسار أنت فيه يفسر معظم المفاجآت في الأداء—ولماذا تبدو التجزئة غير متوقعة.
النتيجة المثالية هي توجيه استعلام لشارد واحد فقط. إذا كان الطلب يتضمن مفتاح الشارد (أو شيء يمكن للموجّه خرائطته للشارد)، يمكن إرساله مباشرة إلى المكان الصحيح.
لهذا السبب تركز الفرق على جعل قراءات الشائع «واعية بمفتاح الشارد». شارد واحد يعني عددًا أقل من الرحلات الشبكية، تنفيذًا أبسط، أقفالًا أقل، وتنسيقًا أقل. الكمون يكون غالبًا عمل قاعدة البيانات نفسها، لا جدال العنقود حول من ينفذ العمل.
عندما لا يمكن توجيه الاستعلام بدقة (مثلاً يُفلتر بحقل ليس مفتاح الشارد)، قد يبث النظام الاستعلام إلى كل الشاردات أو إلى الكثير منها. كل شارد ينفذ الاستعلام محليًا، ثم يدمج الموجّه النتائج—مرتبًا، مزيلًا التكرار، مطبّقًا حدودًا، ومجمّعًا الأجزاء الجزئية.
هذا التوسع يضخم ذيل الكمون: حتى لو استجابت 9 شاردات بسرعة، شارد واحد بطيء قد يحتجز الطلب بأكمله. كما يضاعف التحميل: طلب مستخدم واحد يصبح N طلبات شارد.
الانضمامات عبر الشاردات مكلفة لأن بيانات كانت لتلتقي "داخل" قاعدة بيانات واحدة يجب الآن أن تنتقل بين الشاردات (أو إلى منسق). حتى التجميعات البسيطة (COUNT, SUM, GROUP BY) قد تتطلب خطة من مرحلتين: حساب نتائج جزئية على كل شارد ثم دمجها.
معظم الأنظمة تفترض فهارس محلية: كل شارد يفهرس بياناته فقط. هذه الفهارس رخيصة الصيانة، لكنها لا تساعد التوجيه—لذا قد يستمر الاستعلام بالانتشار.
الفهارس العالمية يمكن أن تمكّن التوجيه المستهدف عبر حقول ليست مفتاح الشارد، لكنها تضيف عبئًا على الكتابة، وتنسيقًا إضافيًا، ومشاكل موازنة واتساق خاصة بها.
الكتابات هي النقطة التي تتوقف فيها التجزئة عن كونها "مجرد توسعة" وتبدأ بتغيير كيفية تصميم الميزات. كتابة تمس شاردًا واحدًا يمكن أن تكون سريعة وبسيطة. كتابة تمس عدة شاردات يمكن أن تكون بطيئة، عرضة للفشل، ومن الصعب جعلها صحيحة.
إذا كان كل طلب يمكن توجيهه لشارد واحد (عادة عبر مفتاح الشارد)، يمكن لقاعدة البيانات استخدام آلية المعاملات العادية. تحصل على الذرية والعزل داخل ذلك الشارد، ومعظم المشاكل التشغلية تبدو مألوفة—مشاكل عقدة مفردة مكررة N مرة.
لحظة تحتاج فيها لتحديث بيانات على شاردين أو أكثر في إجراء منطقي واحد (مثل تحويل أموال، نقل طلب بين عملاء، تحديث مجمّع مخزن في مكان آخر)، تدخل في نطاق المعاملات الموزعة.
المعاملات الموزعة صعبة لأنها تتطلب تنسيقًا بين آلات يمكن أن تكون بطيئة، مقطوعة، أو يعاد تشغيلها في أي وقت. بروتوكولات مثل two-phase commit تضيف ذهابًا وإيابًا إضافيًا، قد تحجب التنفيذ أثناء الانتظار، وتجعل حالات الفشل غامضة: هل طبقت الشاردات التغيير أم لا؟ إذا أعاد العميل المحاولة، هل سيتم التطبيق مرتين؟
بعض التكتيكات الشائعة تقلل عدد المرات التي تحتاج فيها معاملات عبر الشاردات:
في الأنظمة المجزأة، إعادة المحاولة ليست اختيارية—بل حتمية. اجعل الكتابات قابلة للتكرار بلا أثر باستخدام معرفات عملية ثابتة (مثل idempotency key) وجعل قاعدة البيانات تخزن علامات "تم التطبيق بالفعل". هكذا إذا حدث مهلة وأعاد العميل المحاولة، تصبح المحاولة الثانية بلا تأثير بدلًا من إنشاء تطبيق مزدوج أو أمر مكرر أو عداد غير متسق.
التجزئة تقسم بياناتك عبر آلات، لكنها لا تلغي الحاجة للنسخ الاحتياطي. التكرار هو ما يبقي الشارد متاحًا عند سقوط عقدة—وهو أيضًا ما يجعل الإجابة عن "ما هو الصحيح الآن؟" أصعب.
معظم الأنظمة تكرر ضمن كل شارد: زعيم يقبل الكتابات، ونسخ تنسخ التغييرات. إذا فشل الزعيم، يطرح النظام نائبًا. يمكن للنسخ أيضًا خدمة القراءات لتقليل الحمل.
المقايضة هي التوقيت. قد يتأخر نسخة القراءة ميليًا أو ثوانٍ. هذه الفجوة طبيعية لكنها مهمة عندما يتوقع المستخدم رؤية التحديث فورًا.
في الإعدادات المجزأة، غالبًا ما تحصل على اتساق قوي داخل الشارد وضمانات أضعف عبر الشاردات، خاصة عند العمليات متعددة الشاردات.
مع التجزئة، «مصدر واحد للحقيقة» يعني عادةً: لكل قطعة من البيانات هناك مكان واحد موثوق للكتابة (عادة زعيم الشارد). لكن على مستوى عالمي لا توجد ماكينة واحدة يمكنها أن تؤكد فورًا أحدث حالة لكل شيء. لديك حقائق محلية يجب مزامنتها عبر التكرار.
القيود تصبح معقدة عندما تكون البيانات التي يجب فحصها على شاردات مختلفة:
هذه الاختيارات ليست تفاصيل تنفيذية فقط—إنها تُعرِّف ماذا يعني "صحيح" للمنتج.
إعادة الموازنة تحافظ على قابلية استخدام قاعدة مجزأة مع تغير الواقع. البيانات تنمو بشكل غير متساوٍ، مفتاح شارد كان متوازنًا يتحوّل إلى انحراف، تضيف عقد لسعة، أو تحتاج إلى إيقاف عتاد. أيٌ من ذلك قد يحول شاردًا إلى عنق زجاجة—حتى لو كان التصميم الأصلي مثاليًا.
على عكس قاعدة بيانات أحادية، التجزئة تُخزن "موقع" البيانات داخل منطق التوجيه. عندما تنقل البيانات، لا تنسخ البايتات فحسب—أنت تغيّر المكان الذي يجب أن تذهب إليه الاستعلامات. لذا إعادة الموازنة جزء منها عن الميتا-داتا والعملاء بقدر ما هي عن التخزين.
تسعى الفرق لمعظم الأحيان إلى سير عمل على الخط لتجنب نافذة "إيقاف العالم":
تغيير خريطة الشاردات حدث قد يكسر العملاء إن كانوا يخزنون قرارات التوجيه مؤقتًا. الأنظمة الجيدة تعامل ميتا-داتا التوجيه كإعداد: عَدِّل النسخ، قم بالتحديث المتكرر، وكن صريحًا حول ماذا يحدث عندما يصادف العميل مفتاحًا تم نقله (إعادة توجيه، إعادة محاولة، أو عبر الوكيل).
إعادة الموازنة غالبًا تسبب انخفاضًا مؤقتًا في الأداء (كتابات إضافية، تبديل الكاش، حمل النسخ الخلفية). الحركات الجزئية شائعة—بعض النطاقات تُهاجر قبل الأخرى—فمن الضروري وجود مراقبة واضحة وخطة تراجع (مثلاً إعادة تفعيل الخريطة القديمة وتصريف الكتابات المزدوجة) قبل بدء القطع.
التجزئة تفترض أن العمل سيتوزع. المفاجأة أن العنقود قد يبدو "متوازنًا" على الورق (نفس عدد الصفوف لكل شارد) بينما يتصرف بشكل مختلف في الإنتاج.
نقطة ساخنة تحدث عندما يحصل جزء صغير من فضاء المفاتيح على معظم الحركة—حساب مشهور، منتج شائع، مستأجر يقوم بعملية مكثفة، أو مفتاح زمني حيث "اليوم" يتلقى كل الكتابات. إذا كانت هذه المفاتيح مخصصة لشارد واحد، يصبح ذلك الشارد عنق زجاجة حتى لو بقي الآخرون خامدين.
"الانحراف" ليس شيئًا واحدًا:
قد لا يتطابقا دائمًا. شارد ببيانات أقل قد يكون الأكثر حرارة إذا امتلك المفاتيح المطلوبة بكثرة.
ليس مطلوبًا تتبع متقدم لرصد الانحراف. ابدأ بلوحات per-shard:
إذا ارتفعت كمون شارد واحد مع QPS بينما بقيت أخرى ثابتة، فغالبًا لديك نقطة ساخنة.
الإصلاحات عادة ما تتبادل البساطة مقابل التوازن:
التجزئة لا تزيد فقط عدد الخوادم—بل تضيف طرقًا أكثر لحدوث الأخطاء، ومزيدًا من الأماكن للبحث عند وقوعها. كثير من الحوادث ليست "قاعدة البيانات متوقفة" بل "شارد واحد متوقف" أو "النظام لا يتفق على موقع البيانات".
أنماط متكررة:
في قاعدة بيانات أحادية، تتابع سجلًا واحدًا وتراجع مجموعة مقاييس. في نظام مجزأ تحتاج ملاحظات تتبع الطلب عبر الشاردات.
استخدم معرّفات ترابط في كل طلب وانقلها من طبقة الـ API عبر الموجّهات إلى كل شارد. اقترن ذلك بتتبّع موزع حتى يظهر استعلام الانتشار-الجمْع أي شارد كان بطيئًا أو فشل. يجب أن تُقسَّم المقاييس لكل شارد (الكمون، عمق الطابور، معدل الخطأ)، وإلا يخفي المتوسط العام شاردًا ساخنًا.
فشل التجزئة يظهر كثيرًا كعيوب صحة:
"استعادة قاعدة البيانات" تصبح "استعادة أجزاء عديدة بالترتيب الصحيح". قد تحتاج لاستعادة الميتا-داتا أولًا، ثم كل شارد، ثم التحقق من حدود الشارد والتوجيه لتطابق نقطة الاستعادة. خطط التعافي يجب أن تتضمن تدريبات تثبت أنه يمكنك إعادة تركيب العنقود المتناسق—وليس مجرد استرداد آلات منفردة.
غالبًا ما تُعامل التجزئة كمفتاح "التوسيع"، لكنها أيضًا زيادة دائمة في تعقيد النظام. إذا كان بإمكانك تلبية أهداف الأداء والموثوقية دون تقسيم البيانات عبر العقد، ستحصل عادةً على هندسة أبسط، تصحيح أخطاء أسهل، وحواف تشغيلية أقل.
قبل الالتزام بالتجزئة، جرّب حلولًا تحافظ على منطقية قاعدة واحدة:
طريقة عملية لتقليل المخاطر هي بناء نموذج أولي للأنابيب (التوجيه، مفاتيح عدم التكرار، إجراءات الهجرة، والمراقبة) قبل ربط الإنتاج بالتجزئة.
مثال: مع Koder.ai يمكنك بسرعة إنشاء خدمة صغيرة وواقعية من محادثة—غالبًا واجهة إدارة React مع backend بلغة Go وقاعدة PostgreSQL—ولتجربة واجهات API واعية بمفتاح الشارد، مفاتيح عدم التكرار، وسلوكيات القطع في صندوق آمن. بما أن Koder.ai يدعم وضع التخطيط، لقطات/تراجع، وتصدير الشيفرة، يمكنك تدوير قرارات التصميم المتعلقة بالتجزئة إلى مكدسك الرئيسي عندما تكون واثقًا.
التجزئة مناسبة عندما يتجاوز حجم البيانات أو معدل الكتابة حدود عقدة واحدة و يمكن توجيه معظم الاستعلامات الحرجة بواسطة مفتاح شارد (قليل من الانضمامات/المعاملات عبر الشاردات).
إنها غير مناسبة عندما يحتاج المنتج إلى الكثير من الاستعلامات التكيفية، معاملات متعددة الكيانات بشكل متكرر، قيود تفرد عالمية، أو عندما لا يستطيع الفريق تحمل عبء التشغيل (إعادة الموازنة، إعادة التجزئة، الاستجابة للحوادث).
اسأل نفسك:
حتى لو أجلت التجزئة، صمِّم مسار هجرة: اختر معرّفات لا تمنع مفتاح شارد مستقبليًا، تجنّب افتراضات العقدة الواحدة في الكود، ودرب نفسك كيف ستنقل البيانات بأدنى توقف ممكن. أفضل وقت للتخطيط لإعادة التجزئة هو قبل أن تحتاجها.
التجزئة (التقسيم الأفقي) تقسم مجموعة بيانات منطقية واحدة على عدة آلات («شاردات») بحيث يخزن كل شارد صفوفًا مختلفة.
أما التكرار (Replication)، فبدلاً من ذلك يحتفظ بنسخ من نفس البيانات على عدة عقد—بشكل أساسي لتحسين التوافر وتوسيع قراءة البيانات.
التوسيع الرأسي يعني ترقية خادم قاعدة بيانات واحد (مزيد من CPU/ذاكرة/أقراص أسرع). إنه أبسط من الناحية التشغيلية، لكنه يصل في النهاية إلى حدود صعبة أو يصبح مكلفًا جدًا.
التجزئة توسع بالاتساع (scale out) عبر إضافة آلات، لكنها تضيف توجيهًا، وإعادة موازنة، وتعقيدات صحة البيانات عبر الشاردات.
تقوم الفرق بالتجزئة عندما يصبح عقدة واحدة عنق زجاجة متكررًا، مثل:
التجزئة توزع البيانات والعبء بحيث تزداد السعة بإضافة عقد.
نظام مجزأ نموذجي يتضمن:
الأداء والصحة يعتمد على بقاء هذه الأجزاء متناسقة.
مفتاح الشارد هو الحقل (أو مجموعة الحقول) التي تُستخدم لتحديد مكان تخزين الصف. إنه يحدد إلى حد كبير ما إذا كانت الطلبات تصل إلى شارد واحد (سريع) أم إلى عدة شاردات (بطيء).
مفاتيح جيدة عادةً ما تكون ذات تعدد قيم كبير، توزيع متساوٍ، وتتماشى مع أنماط الوصول الشائعة (مثل tenant_id أو user_id).
مفاتيح شاردة سيئة شائعة:
هذه تؤدي إلى نقاط ساخنة وتحول الاستعلامات الروتينية إلى استعلامات انتشار-جمع (scatter-gather).
ثلاث استراتيجيات شائعة:
إذا تضمن الاستعلام مفتاح الشارد (أو ما يمكن خرائطته إليه)، يرسل الموجّه الطلب لشارد واحد—المسار السريع.
إذا لم يمكن توجيه الاستعلام بدقة، قد يُبثّ إلى العديد أو كل الشاردات؛ كل شارد ينفذ الاستعلام محليًا ثم يدمج المنسق النتائج—هذا التوسع (fan-out) يضخم زمن الذيل: شارد بطيء واحد قد يؤخر الاستجابة كلها.
كتابات شارد واحد تستخدم آلية المعاملات العادية لذلك الشارد—سريع وبسيط.
الكتابات عبر شاردات تتطلب تنسيقًا موزعًا (بروتوكولات شبيهة بـ two-phase commit)، مما يزيد زمن الاستجابة ويجعل حالات الفشل غامضة: هل طبق الشارد B التغيير قبل وفاة المنسق؟ هل سيكرر العميل العملية ويؤدي إلى تطبيق مزدوج؟
تخفيفات عملية شائعة: توطين البيانات، جعل العملية مملوكة لشارد واحد، التكرار المتعمد (denormalization)، واستخدام مفاتيح عدم التكرار (idempotency keys) لجعل عمليات إعادة المحاولة آمنة.
داخل كل شارد توجد عادة آلية تكرار: رئيسي يقبل الكتابات ونسخ تستنسخ التغييرات. عند فشل الرئيس، يُرفَع نائب.
المشكلة أن القراءات من النسخ قد تكون متأخرة ميلي أو ثوانٍ؛ لذلك تحصل غالبًا على اتساق قوي داخل الشارد وضمانات أضعف عبر الشاردات. فرض قيود عالمية (تفرد أسماء المستخدمين، مفاتيح أجنبية عبر شاردات، عدادات عالمية) يتطلب عملًا مركزيًا أو حلولًا تطبيقية بخيارات تنازلية.
إعادة التوازن صعبة لأنك تغيّر «مكان» البيانات، وليس مجرد نسخها. لذلك الهجرة تؤثر على التوجيه والعميل وخريطة الشاردات.
نمط هجرة على الخط الشائع: نسخ → تداخل/كتابة مزدوجة → تغير الخريطة (cutover) → تنظيف. يحتاج هذا إلى إصدار لخريطة الشاردات، سلوك واضح عند وصول العميل لمفتاح مُحول (إعادة توجيه، إعادة محاولة، أو خطأ)، وخطة تراجُع.
عمليات إعادة التوازن تسبب تحميلًا إضافيًا (كتابات مزدوجة، تبديل الكاش)، لذا يجب مراقبتها جيدًا ووجود خطة للتراجع.
النقاط الساخنة تحدث عندما يحصل جزء صغير من فضاء المفاتيح على معظم الطلبات—حساب مشهور، منتج شائع، tenant يقوم بتحميل كبير، أو مفتاح زمني حيث «اليوم» يجمع كل الكتابات. إذا خُصص ذلك لمجموعة شاردات قليلة، ستصبح عنق زجاجة.
الكشف بسرعة عبر لوحات مؤشرات per-shard: p95 لكل شارد، QPS لكل شارد، التخزين المستخدم لكل شارد. المعالجات: اختيار مفتاح يوزع الحِمل، تطبيق bucketing/salting للمفاتيح الساخنة، التخزين المؤقت، تحديد حدود/حصص، أو تقسيم الشارد الساخن.
أنماط الفشل تتعدد: شارد غير متاح، موجّه يرسل للحقل الخطأ بعد تغيير تهيئة، ميتا-داتا قديمة أو متنافرة أثناء النقل، أو مشاكل شبكية جزئية تؤدي إلى مهلات وزيادة إعادة المحاولات.
للتصحيح، تحتاج إلى تتبع يربط الطلب عبر الشاردات: معرفات ترابط (correlation IDs)، تتبّع موزع (distributed tracing)، ومقاييس مفصَّلة per-shard. استعادة النسخ الاحتياطية تصبح استعادة أجزاء متعددة بالترتيب الصحيح—غالبًا الميتا-داتا أولًا ثم الشاردات.
حوادث صحة البيانات تظهر كاستنساخات بعد إعادة المحاولة، صفوف مفقودة بعد هجرة، أو كتابات انقسام-دماغ إذا قبلت نظرات ميتا متعددة الكتابات لنطاق واحد.
قبل التجزئة، جرّب حلولًا تحافظ على منطقية قاعدة بيانات واحدة:
يمكن تجريب بنية تساندية للتجزئة (التوجيه، أمان إعادة المحاولة، إجراءات القطع) في بيئة اختبار قبل الالتزام الفعلي. التجزئة مناسبة عندما تتجاوز القيود عقدة واحدة و يمكن توجيه معظم الاستعلامات عبر مفتاح شارد بحيث تقل حاجة للانضمامات/المعاملات عبر الشاردات.