خدمة Amazon OpenSearch قدمت مؤخرًا عائلة مثيلات OpenSearch Optimized (OR1)، والتي توفر ما يصل إلى 30% من تحسين أداء السعر مقارنة بمثيلات الذاكرة المحسنة الحالية في المعايير الداخلية، وتستخدم خدمة تخزين أمازون البسيطة (Amazon S3) لتوفير 11 9 ثانية من المتانة. مع عائلة المثيلات الجديدة هذه، تستخدم خدمة OpenSearch ابتكار OpenSearch وتقنيات AWS لإعادة تصور كيفية فهرسة البيانات وتخزينها في السحابة.

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

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

تصميم لإنتاجية عالية مع 11 9 ثانية من المتانة

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

توفر عائلة OpenSearch Optimized Instance متانة إضافية مع تقليل التكاليف أيضًا عن طريق تخزين نسخة من البيانات على Amazon S3. باستخدام مثيلات OR1، يمكنك تكوين نسخ متماثلة متعددة لتوفير قراءة عالية مع الحفاظ على إنتاجية الفهرسة.
يوضح الرسم البياني التالي تدفق الفهرسة الذي يتضمن تحديث بيانات التعريف في OR1

أثناء عمليات الفهرسة، تتم فهرسة المستندات الفردية في برنامج Lucene ويتم إلحاقها أيضًا بسجل الكتابة المسبقة المعروف أيضًا باسم Translog. قبل إرسال إقرار إلى العميل مرة أخرى، يتم الاحتفاظ بجميع عمليات النقل إلى مخزن البيانات البعيد المدعوم بواسطة Amazon S3. إذا تم تكوين أي نسخ متماثلة، فستقوم النسخة الأساسية بإجراء عمليات فحص للكشف عن إمكانية وجود عدة كاتبين (تدفق التحكم) على كافة النسخ المتماثلة لأسباب تتعلق بالصحة.
يوضح الرسم البياني التالي إنشاء المقطع وتدفق النسخ المتماثل في مثيلات OR1

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

يوضح الرسم البياني التالي تدفق الاسترداد في مثيلات OR1

لا تستمر مثيلات OR1 في البيانات فحسب، بل في بيانات تعريف المجموعة مثل تعيينات الفهرس والقوالب والإعدادات في Amazon S3. وهذا يضمن أنه في حالة فقدان النصاب القانوني لمدير المجموعة، وهو وضع فشل شائع في إعدادات مدير المجموعة غير المخصصة، يمكن لـ OpenSearch استرداد آخر بيانات التعريف المعترف بها بشكل موثوق.

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

ولا يعدل التصميم الجديد طريقة عمل عمليات البحث. تتم معالجة الاستعلامات بشكل طبيعي إما عن طريق الجزء الأساسي أو المتماثل لكل جزء في الفهرس. قد ترى تأخيرات أطول (في نطاق 10 ثوانٍ) قبل أن تصبح جميع النسخ متسقة مع نقطة زمنية معينة لأن النسخ المتماثل للبيانات يستخدم Amazon S3.

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

كيف تؤدي إعادة تعريف استراتيجية النسخ المتماثل إلى تعزيز إنتاجية الفهرسة

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

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

لماذا تعتبر المتانة العالية فكرة جيدة، ولكن من الصعب القيام بها بشكل جيد

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

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

تكتشف عائلة المثيلات الجديدة تلقائيًا فقدان الجزء الأساسي أثناء استرداد البيانات، وتقوم بإجراء فحوصات مكثفة على إمكانية الوصول إلى الشبكة قبل إعادة ترطيب البيانات من Amazon S3 وإعادة المجموعة إلى حالة صحية.

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

إعادة تصور كيفية تدفق البيانات

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

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

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

نبذة عامة

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

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

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

حول المؤلف

بختيار خان هو مهندس رئيسي يعمل في Amazon OpenSearch Service. يهتم ببناء الأنظمة الموزعة والمستقلة. وهو مشرف ومساهم نشط في OpenSearch.

غوراف بافنا هو مهندس برمجيات أول يعمل على OpenSearch في Amazon Web Services. إنه مفتون بحل المشكلات في الأنظمة الموزعة. وهو مشرف ومساهم نشط في OpenSearch.

ساشين كالي هو أحد كبار مهندسي تطوير البرمجيات في AWS ويعمل على OpenSearch.

روهين بهارجافا هو مدير منتج كبير مع فريق Amazon OpenSearch Service. شغفه في AWS هو مساعدة العملاء في العثور على المزيج الصحيح من خدمات AWS لتحقيق النجاح في أهداف أعمالهم.

رانجيث راماتشاندرا هو مدير هندسة أول يعمل في Amazon OpenSearch Service. إنه متحمس للأنظمة الموزعة القابلة للتطوير بدرجة عالية ، والأداء العالي والأنظمة المرنة.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
• أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
• أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
• أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
• المصدر https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-under-the-hood-opensearch-optimized-instancesor1/