كيفية توسيع Elasticsearch لحل مشكلات قابلية التوسع لديك

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

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

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

في Swoo، تطبيقنا للبث المباشر والألعاب، كانت Elasticsearch عموده الفقري لجميع عمليات البحث، وكان يعمل بشكل جيد بمرور الوقت مع نمو عدد مستخدمينا. في اللحظة التي تجاوز فيها عدد المستخدمين المتوازيين الـ 150,000، بدأت صفحة البحث تفشل أحيانًا، وكان من الواضح تمامًا أن هناك تقييدًا ما في مجموعة Elasticsearch. هذا سرعان ما أصبح غير مقبول في بيئة اللعب الحي ودفعنا لاتخاذ سلسلة من التحسينات، التي أستقرت في النهاية تجربتنا في صفحة البحث والصفحة الرئيسية.

فهم تنظيمية Elasticsearch للقدرة على التوسع

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

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

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

لذا، في جوهر الأمر، كان تجمعنا Elasticsearch يحتوي على بضعة عقد بيانات لحالة Swoo وثلاثة عقد رئيسية مخصصة. كان كل عقد يعمل على معالج بـ 8 نوى مع 16 جيجابايت من الذاكرة العشوائية، تستهدف بشكل رئيسي فهرسة في الوقت الحقيقي والبحث الفوري عن أحداث الألعاب الجارية. نظرًا لأننا نعمل بتوافر عالٍ، نحتاج إلى تخصيص عرض النطاق الترددي الشبكي الفعلي بشكل كبير لضمان الحد الأدنى من التأخر بين العقد.

تخطيط استراتيجية التوسيع الخاصة بك

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

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

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

تقنيات توسيع النواة

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

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

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

بالطبع، إدارة الذاكرة هي عامل آخر مهم جدًا في توسيع Elasticsearch. بالتأكيد، يمكنك تقليل استهلاك الموارد وتحسين أداء استعلاماتك عن طريق تحسين حجم مكدس JVM، وتكوين ذاكرة البيانات الحقلية، وتمكين ذاكرة الاستعلام. يمكن للاستخدام السليم للذاكرة وإعدادات الذاكرة المؤقتة السليمة منع أخطاء نفاد الذاكرة وتقليل التكاليف الإضافية لجمع القمامة.

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

حلول التوسيع المتقدمة

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

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

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

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

التحليلات النظرية وتضحيات الأداء

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

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

الموجة الأولى من الأخطاء التي واجهناها في بيئتنا تتعلق بالضغط العالي على الذاكرة الافتراضية لـ JVM. بدأت خوادم Elasticsearch بتخصيص ذاكرة أقل في البداية – مما أسفر عن دورات تنظيف للذاكرة المتكررة تحت حمل الاستعلام العالي. حللنا هذا عن طريق ضبط JVM، بما في ذلك مواءمة حجم الذاكرة الأدنى والأقصى إلى 8 جيجابايت، مما منح Elasticsearch مساحة كافية لمعالجة الاستعلامات دون تحميل الذاكرة.

الأخطاء الشائعة والحلول

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

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

دليل تنفيذ العالم الحقيقي

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

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

خطط مستقبلية أو توسيعات تكنولوجيا المعلومات

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

الاستنتاج

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

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