خطوات الاستخدام
الخطوة 1: تحديد حجم البيانات الإجمالي (Data Size). قم بإدخال إجمالي حجم البيانات التي سيتم تخزينها في فهرس Elasticsearch بالجيجابايت (GB). هذا المبلغ يشمل جميع المستندات والبيانات الوصفية التي سيتم فهرستها. يتم حساب هذا الرقم بناءً على تقديرات حجم البيانات الفعلية بعد التكرار والضغط، لذا يُفضل تضمين عامل أمان بنسبة 20% إضافية لتجنب النفاد المفاجئ للمساحة.
الخطوة 2: تحديد أقصى حجم لكل جزء (Max Shard Size). أدخل الحد الأقصى المسموح به لحجم كل جزء أساسي (primary shard) بالجيجابايت. القيمة الافتراضية في Elasticsearch هي 50 جيجابايت، ولكن يمكن تعديلها بناءً على أداء الأجهزة ونمط الاستخدام. الحجم الأمثل يتراوح بين 20-50 جيجابايت للحفاظ على توازن الأداء وتوزيع الأحمال. القيم الأصغر تزيد من عدد الشاردز وتقلل من حجم كل جزء، مما يحسن سرعة الاستعلام على حساب زيادة التحميل على العقد.
الخطوة 3: حساب عدد الشاردز الأساسي المطلوب. يتم حساب العدد المطلوب بقسمة إجمالي حجم البيانات على أقصى حجم للشارد، ثم تقريب النتيجة إلى أعلى عدد صحيح باستخدام عملية ceiling: `required_shards = ceil(dataGB / max_shard_size_gb)`. على سبيل المثال، إذا كانت البيانات 100 جيجابايت وأقصى حجم للشارد 30 جيجابايت، فإن عدد الشاردز المطلوب هو ceil(100/30) = 4 شاردز. يضمن ذلك توزيع البيانات دون تجاوز الحد الأعلى لحجم أي شارد.
الخطوة 4: اعتبارات إضافية. يجب الانتباه إلى أن هذا الحساب يحدد عدد الشاردز الأساسية (primary shards) فقط. في حالة استخدام نسخ احتياطية (replica shards)، ستحتاج إلى مضاعفة هذا العدد حسب عدد النسخ المطلوبة. كما يُنصح بمراعاة النمو المستقبلي للبيانات؛ فإذا كان من المتوقع زيادة البيانات بنسبة 50% خلال ستة أشهر، يجب تعديل حجم البيانات المدخلة وفقًا لذلك. أيضًا، يراعى أن كثرة الشاردز (أكثر من 1000) قد تؤدي إلى مشاكل في الأداء بسبب الضغط على عقدة التنسيق (coordinating node).
أمثلة محلولة
تطبيقات عملية على أجزاء Elasticsearch بخطوات الحل كاملة.
الحل
لنفترض أن شركة تريد فهرسة 500 جيجابايت من سجلات المعاملات في Elasticsearch. قرر فريق التشغيل أن أقصى حجم مثالي لكل شارد هو 40 جيجابايت بناءً على مواصفات الأجهزة. تطبيق المعادلة: required_shards = ceil(500 / 40) = 13 شاردز أساسي. لكن لضمان أداء أفضل للاستعلامات، قد يقرر الفريق استخدام 15 شاردز بدلاً من 13 لتحسين توزيع البيانات وتقليل حجم كل شارد إلى 33.3 جيجابايت. يجب أيضًا مراعاة أن الفريق سيضبط عدد النسخ الاحتياطية إلى 1 لضمان التوفر، مما يضاعف إجمالي الشاردز إلى 26 شارد (13 أساسي + 13 نسخة). يمكن حساب هامش النمو السنوي بنسبة 20% ليصبح الحجم التقديري 600 جيجابايت في المستقبل، وبالتالي سيحتاج إلى ceil(600/40)=15 شاردز أساسي.
الحل
افترض أن أحد التطبيقات يقوم بتوليد 50 جيجابايت من السجلات يوميًا على نظام أساسي للوقت (مثل Elasticsearch مع indices يومية). إذا تم إنشاء فهرس يومي، فإن حجم البيانات اليومية هو 50 جيجابايت. لتحديد عدد الشاردز الأساسي لكل فهرس يومي، نستخدم الحد الأقصى لحجم الشارد 50 جيجابايت (القيمة الافتراضية). إذن: required_shards = ceil(50/50) = 1 شارد. لكن هذا التصميم قد يسبب مشاكل أداء عند الاستعلام عبر فهارس متعددة. بدلاً من ذلك، نفضل استخدام فهارس أسبوعية بحجم 350 جيجابايت ليكون ceil(350/50)=7 شاردز. يضمن هذا توزيعًا أفضل للبيانات. يجب أيضًا مراعاة أن دمج شاردز متعددة في فهرس واحد (rollover) يتطلب مراقبة مستمرة لتجنب تجاوز حد الحجم.
أمثلة محسوبة
قيم مُدخَلة ونتيجة محسوبة فعليًا بواسطة أجزاء Elasticsearch.
مرجع — 500GB بحد 40GB للشارد
- حجم البيانات (جيجابايت)
- 500
- الحد الأقصى لحجم الجزء (جيجابايت)
- 40
مرجع — فهارس أسبوعية
- حجم البيانات (جيجابايت)
- 350
- الحد الأقصى لحجم الجزء (جيجابايت)
- 50
مرجع — حجم بعد النمو السنوي
- حجم البيانات (جيجابايت)
- 600
- الحد الأقصى لحجم الجزء (جيجابايت)
- 40
قيم مُدخَلة مرتفعة
- حجم البيانات (جيجابايت)
- 85
- الحد الأقصى لحجم الجزء (جيجابايت)
- 85