Elasticsearch في الإنتاج - نشر أفضل الممارسات

Elasticsearch هو محرك البحث الأمثل للغاية لتحليل البيانات الحديثة.

Elasticsearch هو محرك بحث وتحليلات مدهش في الوقت الحقيقي. أنها بنيت على أباتشي لوسين. إنه موزع ، مريح ، سهل الاستخدام ومتوفر للغاية. تشمل حالات استخدام Elasticsearch تشغيل البحث ومراقبة المعاملات واكتشاف الأخطاء واكتشاف المحتوى وتحليلات السجل والبحث الضبابي وتجميع بيانات الأحداث وتصور البيانات. لقد أثبتت Elasticsearch وباقي حزمة Flex Stack أنها متعددة الاستخدامات للغاية ، وكما ترون حالات الاستخدام أعلاه ، فهناك طرق متعددة لدمج Elasticsearch في ما يقدمه منتجك اليوم وإضافة رؤية إضافية إليه.

نستخدمها بكثرة للبحث والتحليلات في Botmetric ، ونفهرس حوالي مليار مستند يوميًا ونستخدم مجموعات معقدة جدًا لتصور البيانات في الوقت الفعلي.

ومع ذلك ، فإن تمهيد تطبيق مقابل تشغيله في الإنتاج والمحافظة مختلف تمامًا. يغطي هذا aricle العديد من هذه العوامل من تجارب الحياة الحقيقية وهي العناصر الأساسية الشائعة التي يجب عليك أخذها في الاعتبار لتشغيل Elasticsearch في الإنتاج.

ذاكرة:

تتم كتابة Elasticsearch و Lucene بلغة Java ، مما يعني أنه يجب عليك البحث عن إحصائيات heapspace و JVM. لمزيد من كومة الذاكرة المؤقتة المتوفرة لـ Elasticsearch ، زادت الذاكرة التي يمكن استخدامها للتصفية وغيرها من ذاكرة التخزين المؤقت لزيادة أداء الاستعلام. ولكن لاحظ أن الكثير من كومة الذاكرة المؤقتة يمكن أن تعرضك لإيقاف مؤقت طويل لجمع القمامة. لا تقم بتعيين Xmx على الجزء العلوي الذي تستخدمه JVM لمؤشرات الكائنات المضغوطة (عفواً مضغوطًا) ؛ قطع الدقيق يختلف ولكن بالقرب من 32 جيجابايت.

مشكلة شائعة هي تكوين كومة كبيرة جدًا. لديك جهاز بسعة 64 جيجا بايت - وبواسطة golly ، فأنت تريد أن تمنح Elasticsearch جميع ذاكرة الـ 64 جيجا بايت. اكثر افضل! كومة من المهم بالتأكيد ل Elasticsearch. يتم استخدامه من قبل العديد من هياكل البيانات في الذاكرة لتوفير عملية سريعة. ولكن مع ذلك ، هناك مستخدم رئيسي آخر للذاكرة غير مطبق: ذاكرة التخزين المؤقت لملف نظام التشغيل.

تم تصميم Lucene للاستفادة من نظام التشغيل الأساسي للتخزين المؤقت بنيات البيانات في الذاكرة. يتم تخزين شرائح لوسين في ملفات فردية. لأن الأجزاء غير قابلة للتغيير ، فإن هذه الملفات لا تتغير أبدًا. هذا يجعلها سهلة الاستخدام للغاية في ذاكرة التخزين المؤقت ، وسيقوم نظام التشغيل الأساسي بسرور إبقاء الشرائح الساخنة مقيمة في الذاكرة للوصول بشكل أسرع. تتضمن هذه المقاطع كلاً من الفهرس المقلوب (للبحث في النص الكامل) وقيم المستند (للمجموعات). يعتمد أداء Lucene على هذا التفاعل مع نظام التشغيل. ولكن إذا أعطيت كل الذاكرة المتاحة إلى كومة Elasticsearch ، فلن يتبقى أي شيء لذاكرة التخزين المؤقت لملف نظام التشغيل. هذا يمكن أن تؤثر تأثيرا خطيرا على الأداء. التوصية القياسية هي إعطاء 50٪ من الذاكرة المتوفرة إلى كومة الذاكرة المؤقتة Elasticsearch ، مع ترك 50٪ الأخرى مجانية. لن يتم استخدامها ؛ سوف يستهلك Lucene بسعادة كل ما تبقى من ذاكرة التخزين المؤقت للملفات. يمكن تكوين كومة Elasticsearch التالية الطرق ،

تصدير ES_HEAP_SIZE = 10g

أو

ES_JAVA_OPTS = "- Xms10g -Xmx10g" ./bin/elasticsearch

وحدة المعالجة المركزية:

Elasticsearch يدعم المجموعات والاستعلامات التي تمت تصفيتها. إن تشغيل الاستعلامات المعقدة المفلترة والفهرسة المكثفة والإسقاط والاستعلامات مقابل المؤشرات يحتاج إلى وحدة المعالجة المركزية الثقيلة ، لذلك يعد التقاط الاستعلامات الصحيحة أمرًا بالغ الأهمية. يجب أن يفهم المرء مواصفات وحدة المعالجة المركزية وكيف يتصرفون مع جافا عندما تعمل الاستعلامات على JVM

يعمل كل تجمع على عدد من الخيوط ، والتي يمكن تهيئتها ، ويحتوي على قائمة انتظار. لا ينصح بتغيير هذا إلا إذا كان لديك شرط محدد للغاية حيث يقوم Elasticsearch بتخصيص النوى بشكل ديناميكي.

أنواع تجمع الخيط:

Elasticsearch لديها 3 أنواع من حمامات الموضوع.

  1. المخزنة مؤقتًا: تجمع مؤشرات الترابط المخزنة مؤقتًا هو تجمع مؤشرات ترابط غير محدود من شأنه أن يولد سلسلة رسائل إذا كانت هناك طلبات معلقة. يتم استخدام تجمع مؤشرات الترابط هذا لمنع الطلبات المقدمة إلى هذا التجمع من حظرها أو رفضها. سيتم إنهاء مؤشرات الترابط غير المستخدمة في تجمع مؤشرات الترابط هذا بعد انتهاء صلاحية البقاء على قيد الحياة (الإعدادات الافتراضية إلى خمس دقائق). تجمع مؤشر الترابط المخزنة مؤقتاً محجوز تجمع مؤشر ترابط عام.
  2. ثابت: تجمع مؤشرات الترابط الثابتة حجم ثابت من مؤشرات الترابط لمعالجة الطلبات مع قائمة انتظار (محددة اختياريًا) للطلبات المعلقة التي ليس لديها مؤشرات ترابط لخدمة لهم. تتحكم معلمة الحجم في عدد مؤشرات الترابط ، وتفترض عدد مرات النوى 5.
  3. القياس: تجمع مؤشرات الترابط التحجيم عدد ديناميكي من مؤشرات الترابط. يتناسب هذا الرقم مع عبء العمل ويتراوح بين 1 وقيمة معلمة الحجم.

يقسم Elasticsearch استخدام وحدة المعالجة المركزية إلى تجمعات خيط من أنواع مختلفة:

  • عام: للعمليات القياسية مثل الاكتشاف ونوع تجمع مؤشرات الترابط مؤقتًا.
  • الفهرس: لعمليات الفهرس / الحذف. نوع تجمع الخيط ثابت.
  • البحث: لعمليات العد / البحث. نوع تجمع الخيط ثابت.
  • الحصول على: للحصول على العمليات. نوع تجمع الخيط ثابت.
  • bulk: لعمليات مجمعة مثل فهرسة كبيرة الحجم. نوع تجمع الخيط ثابت. يعتمد أفضل تكوين للمستندات المجمعة على تكوين الكتلة ، ويمكن تحديد ذلك من خلال تجربة قيم متعددة.
  • ترشح: للتسرب. نوع تجمع الخيط ثابت.
  • تحديث: لعمليات التحديث. نوع تجمع مؤشر الترابط هو التحجيم.

يمكن تغيير تجمع مؤشرات ترابط معينة عن طريق تعيين المعلمات الخاصة بالنوع.

اقرأ المزيد https://www.elastic.co/guide/en/elasticsearch/reference/2.2/modules-threadpool.html#types

حجم القشرة:

القشرة هي الوحدة التي يوزع فيها Elasticsearch البيانات داخل المجموعة. السرعة التي يمكن أن يتحرك بها Elasticsearch عند إعادة توازن البيانات ، على سبيل المثال بعد الفشل ، سيعتمد على حجم وعدد القطع بالإضافة إلى أداء الشبكة والقرص.

في Elasticsearch ، يتم تنفيذ كل استعلام في سلسلة واحدة لكل شارد. ومع ذلك ، يمكن معالجة القطع المتعددة بالتوازي ، كما يمكن معالجة الاستعلامات والتجمعات المتعددة مقابل نفس القطعة.

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

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

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

تكرار

Elasticsearch يدعم النسخ المتماثل ، يتم نسخ البيانات بين العقد البيانات بحيث فقدان العقدة لن يؤدي إلى فقدان البيانات. حسب عامل النسخ المتماثل الافتراضي هو 1 ، ولكن حسب متطلبات المنتج الخاص بك يمكن زيادتها. لمزيد من النسخ المتماثلة ، سيكون أكثر مقاومة للكوارث البيانات الخاصة بك. ميزة أخرى وجود المزيد من النسخ المتماثلة هي أن كل عقدة تحتوي على نسخة طبق الأصل من القطع ، مما يحسن أداء الاستعلام حيث يتم استخدام النسخ المتماثلة أيضًا للاستعلام.

صيغة النسخ المتماثل المستخدمة بواسطة Elasticsearch من أجل التناسق هي ،

(أساسي + number_of_replicas) / 2 + 1

تحسين التخصيص

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

يمكن تحقيق ذلك من خلال تشغيل cronjob الذي ينقل المؤشرات إلى عقد مختلفة على فترات منتظمة.

العقدة الساخنة هي نوع من عقدة البيانات يؤدي جميع الفهرسة داخل الكتلة. كما أنها تحتوي على أحدث المؤشرات لأن هذه المؤشرات عادة ما يتم الاستعلام عنها بشكل متكرر. نظرًا لأن الفهرسة عبارة عن عملية مكثفة لوحدة المعالجة المركزية والمعالجات IO ، يجب أن تكون هذه الخوادم قوية ومدعومة بتخزين SSD متصل. نوصي بتشغيل 3 من العقد الساخنة على الأقل لتوفرها بشكل كبير. بناءً على كمية البيانات الحديثة التي ترغب في جمعها والاستعلام عنها ، فقد تحتاج إلى زيادة هذا الرقم لتحقيق أهداف أدائك.

العقدة الدافئة هي نوع من عقدة البيانات المصممة للتعامل مع كمية كبيرة من مؤشرات القراءة فقط والتي من غير المحتمل أن يتم الاستعلام عنها بشكل متكرر. نظرًا لأن هذه المؤشرات للقراءة فقط ، تميل العقدة الدافئة إلى استخدام الأقراص الكبيرة المرفقة (عادةً أقراص الدوران) بدلاً من محركات أقراص الحالة الصلبة. كما هو الحال مع العقدة الساخنة ، نوصي بحد أدنى 3 عقدة دافئ لتوفير عالية. وكما كان الحال من قبل ، مع التحذير ، قد تتطلب كميات أكبر من البيانات عقدًا إضافية لتلبية متطلبات الأداء. لاحظ أيضًا أن تكوينات وحدة المعالجة المركزية والذاكرة ستحتاج غالبًا إلى نسخ مطابقة للعقد الساخنة. لا يمكن تحديد ذلك إلا عن طريق اختبار استعلامات مشابهة لما قد تواجهه في حالة الإنتاج.

لمزيد من التفاصيل حول العقدة الساخنة والدفئة ، يرجى الرجوع هنا

من الإستراتيجيات الأخرى التي يمكنك تكييفها ، أرشفة المؤشرات إلى s3 واستعادتها عندما تحتاج إلى بيانات من هذه المؤشرات. يمكنك قراءة المزيد عنها من هنا.

طوبولوجيا العقدة:

يمكن تقسيم العقد Elasticsearch إلى ثلاث فئات رئيسية العقدة ، عقدة البيانات ، عقدة العميل.

  1. العقدة الرئيسية: يمكن أن تكون العقدة الرئيسية صغيرة إذا لم تكن العقدة البيانات أيضًا لأنها لا تخزن أي مؤشرات / قطع. تتمثل مسؤوليتها في تخزين حالة الكتلة التفصيلية ومساعدة البيانات والعقد الأخرى في البحث عن البيانات الوصفية للمؤشرات / القطع. يجب أن يحتوي Elasticsearch على عدة نقاط رئيسية لتجنب مشكلة انقسام المخ.
  2. عقدة البيانات: عقدة البيانات هي المسؤولة عن تخزين / الاستعلام عن بيانات الفهرس الفعلية.
  3. عقدة العميل: يتم استخدام عقدة العميل كوكيل للفهرسة والبحث. ينصح بشدة إذا تم استخدام المجموعات بشكل كبير. هذه عبارة عن عقد FlexSearch خاص غير مؤهل للبيانات أو رئيسي. عقد العميل على علم بنظام المجموعة وبالتالي يمكن أن تعمل كميزات تحميل ذكية. يمكنك إرسال استفساراتك إلى عقد العميل التي يمكنها بعد ذلك القيام بالمهمة الباهظة المتمثلة في جمع الاستجابات لنتائج الاستعلام من كل من عقد البيانات.

أضف هذه الإعدادات إلى ملف elasticsearch.yml للعقد المعنية.

العقدة الرئيسية: node.master: true node.data:false
عقدة البيانات: node.master: false node.data:true
عقدة العميل: node.master: false node.data:false

نصائح استكشاف الأخطاء وإصلاحها:

يعتمد أداء Elasticsearch بشكل كبير على الجهاز المثبت عليه. تعد وحدة المعالجة المركزية (CPU) واستخدام الذاكرة والقرص I / O من مقاييس نظام التشغيل الأساسية لكل عقدة Elasticsearch. يوصى بمراجعة مقاييس Java Virtual Machine (JVM) عند زيادة استخدام وحدة المعالجة المركزية. في المثال التالي ، كان سبب ارتفاع نشاط تجميع البيانات المهملة أعلى.

  1. ضغط الكومة: يعمل ضغط الذاكرة المرتفع ضد أداء الكتلة بطريقتين: مع ارتفاع ضغط الذاكرة إلى 75٪ وما فوق ، تظل ذاكرة أقل متوفرة ، ويحتاج نظام المجموعة الآن أيضًا إلى إنفاق بعض موارد وحدة المعالجة المركزية لاستعادة الذاكرة من خلال تجميع البيانات المهملة. لا تتوفر دورات CPU هذه لمعالجة طلبات المستخدم أثناء تشغيل تجميع البيانات المهملة. نتيجة لذلك ، تزداد أوقات الاستجابة لطلبات المستخدم نظرًا لأن موارد النظام تصبح أكثر فأكثر. إذا استمر ضغط الذاكرة في الارتفاع ووصل إلى ما يقرب من 100٪ ، فسيتم استخدام شكل أكثر جرأة بكثير من جمع القمامة ، مما سيؤثر بدوره على أوقات استجابة الكتلة بشكل كبير. يوضح مؤشر أوقات استجابة الفهرس أن ارتفاع ضغط الذاكرة يؤدي إلى تأثير كبير في الأداء.
  2. نمو في ذاكرة JVM بخلاف كومة الذاكرة المؤقتة ، وتآكل الذاكرة المخصصة للذاكرة المؤقتة للصفحة ، وربما التسبب في حصد OOM على مستوى kernel.
  3. تجنب مشكلة انقسام الدماغ. انقسام الدماغ هو سيناريو حيث انشقاق الكتلة. على سبيل المثال ، لديك 6 عقدة كتلة. قطع العقدتين من الكتلة ، لكنها لا تزال قادرة على رؤية بعضها البعض. هذه العقد 2 ثم إنشاء كتلة أخرى. سوف ينتخبون حتى سيد جديد فيما بينهم. لدينا الآن مجموعتان بنفس الاسم ، واحدة مع 4 عقد والآخر مع عقدتين. كل لديه عقدة رئيسية أيضا. هذا ما يسمى مشكلة انقسام الدماغ مع مجموعات ES. ولتجنب ذلك ، عيّن معلمة ES discovery.zen.minimum_master_nodes إلى نصف عدد العقد + 1.
  4. نظرًا لأن Elasticsearch يستخدم أجهزة التخزين بكثافة ، فإن مراقبة القرص I / O يضمن تلبية هذه الحاجة الأساسية. هناك العديد من الأسباب لخفض الإدخال / الإخراج للقرص ، والذي يعتبر مقياسًا رئيسيًا للتنبؤ بأنواع كثيرة من المشكلات. إنه مقياس جيد للتحقق من فعالية الفهرسة وأداء الاستعلام. يشير تحليل عمليات القراءة والكتابة مباشرة إلى ما يحتاجه النظام في حالة الاستخدام المحددة. تعد إعدادات نظام التشغيل للإدخال / الإخراج للقرص أساسًا لكل عمليات التحسين الأخرى ، حيث يمكن لضبط إدخال / إخراج القرص تجنب المشكلات المحتملة. إذا كان القرص I / O لا يزال غير كافٍ ، فيجب تقييم التدابير المضادة مثل تحسين عدد القطع وحجمها أو دمج الخانق أو استبدال الأقراص البطيئة أو الانتقال إلى محركات الأقراص الصلبة أو إضافة المزيد من العقد وفقًا للظروف التي تسببت في إدخال / إخراج اختناقات.
  5. بالنسبة للتطبيقات التي تعتمد على البحث ، ترتبط تجربة المستخدم ارتباطًا كبيرًا بوقت استجابة طلبات البحث. هناك العديد من الأشياء التي يمكن أن تؤثر على أداء الاستعلام ، مثل الاستعلامات التي تم إنشاؤها ، ومجموعة Elasticsearch التي تم تكوينها بشكل غير صحيح ، ومشاكل JVM وجمع البيانات المهملة ، والقرص IO ، وما إلى ذلك. استتار الاستعلام هو المقياس الذي يؤثر بشكل مباشر على المستخدمين ، لذا تأكد من وضع بعض التنبيهات عليه.
  6. يتم تخزين معظم المرشحات في Elasticsearch بشكل افتراضي. وهذا يعني أنه خلال التنفيذ الأول لاستعلام تمت تصفيته ، سيجد Elasticsearch وثائق مطابقة للمرشح وبناء بنية تسمى "bitset" باستخدام تلك المعلومات. تحتوي البيانات المخزنة في مجموعة البت على معرف مستند وما إذا كان مستند معين يطابق عامل التصفية. عمليات إعادة التنفيذ اللاحقة للاستعلامات التي لها نفس المرشح ستعيد استخدام المعلومات المخزنة في مجموعة البت ، مما يجعل تنفيذ الاستعلام أسرع من خلال حفظ عمليات الإدخال / الإخراج ودورات وحدة المعالجة المركزية. يوصى باستخدام المرشح في الاستعلام. لمزيد من التفاصيل الرجوع هنا.
  7. يرتبط تحديث الوقت ووقت الدمج ارتباطًا وثيقًا بأداء الفهرسة ، بالإضافة إلى أنهما يؤثران على الأداء الكلي للكتلة. يزيد وقت التحديث مع عدد عمليات الملفات لفهرس Lucene (shard).
  8. سيساعد تمكين التسجيل البطيء للاستعلام في تحديد الاستعلامات البطيئة وما الذي يمكن القيام به لتحسينها ، وخاصةً لاستعلامات البدل.
  9. زيادة حجم ulimit للسماح ماكس الملفات.
  10. قد يتأثر أداء البحث المرن عندما يقرر نظام التشغيل تبديل ذاكرة التطبيق غير المستخدمة. قم بتعطيل التبديل عن طريق تعيين إعدادات مستوى نظام التشغيل أو تعيين ما يلي في ElasticSearch config bootstrap.mlockall: true
  11. تعطيل حذف جميع المؤشرات عن طريق الاستعلام البدل. للتأكد من عدم قيام شخص ما بإصدار عملية DELETE في جميع الفهارس (* أو _all) ، قم بتعيين action.destructive_requires_name إلى true.

قبل الانتهاء ، ستجد هنا قائمة عناوين url المفيدة لمشاهدة المقاييس.

  • / _cluster / health - جميلة: بالنسبة لمؤشر صحة الكتلة.
  • / _status؟ جميلة: للحصول على جميع المعلومات حول جميع المؤشرات.
  • / _nodes؟ جميلة: للحصول على جميع المعلومات حول العقد.
  • / _cat / master؟ جميلة: للحصول على عقدة رئيسية.
  • / _stats؟ جميلة: لتخصيص القشرة ، إحصائيات المؤشرات.
  • / _nodes / stats - جميلة: بالنسبة لإحصائيات العقدة الفردية ، يتضمن ذلك احصائيات jvm و http و io للعقدة.

يتم دعم تجميع مقاييس Elasticsearch بواسطة معظم أدوات مراقبة النظام مثل Datadog و TICK. يوصى باستخدام هذه الأدوات وإنشاء أداة قمع موصى بها بشدة للمراقبة المستمرة لـ Elasticsearch.

استنتاج:

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