يا هبر! اسمي مكسيم فاسيليف ، أعمل كمحلل ومدير مشروع في FINCH. اليوم أود أن أخبركم كيف تمكنا ، باستخدام ElasticSearch ، من معالجة 15 مليون طلب في 6 دقائق وتحسين الأحمال اليومية على موقع أحد عملائنا. لسوء الحظ ، سيتعين علينا الاستغناء عن الأسماء ، نظرًا لأن لدينا اتفاقية عدم الإفشاء ، نأمل ألا يعاني محتوى المقالة من هذا. دعنا نذهب.
كيف يعمل المشروع
في الخلفية الخاصة بنا ، نقوم بإنشاء خدمات تضمن أداء مواقع الويب والتطبيقات المحمولة لعملائنا. يمكن رؤية الهيكل العام في الرسم التخطيطي:
في عملية العمل ، نقوم بمعالجة عدد كبير من المعاملات: عمليات الشراء والمدفوعات والعمليات بأرصدة المستخدمين ، والتي نقوم بتخزين الكثير من السجلات الخاصة بها ، وكذلك استيراد وتصدير هذه البيانات إلى أنظمة خارجية.
هناك أيضًا عمليات عكسية عندما نتلقى البيانات من العميل وننقلها إلى المستخدم. بالإضافة إلى ذلك ، لا تزال هناك عمليات للعمل مع برامج المدفوعات والمكافآت.
خلفية موجزة
في البداية ، استخدمنا PostgreSQL كمخزن البيانات الوحيد. مزاياها القياسية لنظام إدارة قواعد البيانات (DBMS): وجود معاملات ، لغة متطورة لأخذ عينات البيانات ، مجموعة واسعة من الأدوات للتكامل ؛ جنبًا إلى جنب مع الأداء الجيد الذي يلبي احتياجاتنا لفترة طويلة.
قمنا بتخزين جميع البيانات تمامًا في Postgres: من المعاملات إلى الأخبار. لكن عدد المستخدمين نما ومعه عدد الطلبات.
للفهم ، العدد السنوي للجلسات في عام 2017 فقط على موقع سطح المكتب هو 131 مليون. في 2018 - 125 مليون. 2019 مرة أخرى 130 مليون.إضافة 100-200 مليون أخرى من نسخة الهاتف المحمول للموقع وتطبيق الهاتف ، وأنت سوف تحصل على عدد كبير من الطلبات.
مع نمو المشروع ، توقف Postgres عن التعامل مع الحمل ، ولم يكن لدينا وقت - ظهر عدد كبير من الاستعلامات المختلفة ، والتي لم نتمكن من إنشاء عدد كافٍ من الفهارس لها.
لقد فهمنا أن هناك حاجة إلى مخازن بيانات أخرى توفر احتياجاتنا وتزيل العبء عن PostgreSQL. تم اعتبار Elasticsearch و MongoDB كخيارين ممكنين. خسر الأخير في النقاط التالية:
- سرعة فهرسة بطيئة مع زيادة كمية البيانات في الفهارس. مع المرونة ، لا تعتمد السرعة على كمية البيانات.
- لا بحث عن النص الكامل
لذلك اخترنا Elastic لأنفسنا واستعدنا للانتقال.
الانتقال إلى المرونة
1. بدأنا الانتقال من خدمة البحث عن نقاط البيع. يمتلك عميلنا ما مجموعه حوالي 70 نقطة بيع ، وهذا يتطلب عدة أنواع من عمليات البحث على الموقع وفي التطبيق:
- البحث عن النص عن طريق اسم المدينة
- البحث الجغرافي داخل دائرة نصف قطرها معينة من نقطة ما. على سبيل المثال ، إذا أراد المستخدم معرفة نقاط البيع الأقرب إلى منزله.
- البحث بمربع معين - يرسم المستخدم مربعًا على الخريطة ، ويتم عرض جميع النقاط في هذا الشعاع له.
- البحث عن طريق عوامل التصفية الإضافية. تختلف نقاط البيع عن بعضها البعض في التشكيلة
إذا تحدثنا عن المنظمة ، فعندئذٍ في Postgres لدينا مصدر بيانات لكل من الخريطة والأخبار ، وفي Elastic Snapshots مأخوذة من البيانات الأصلية. الحقيقة هي أن Postgres لم تستطع في البداية التعامل مع البحث بكل المعايير. لم يكن هناك العديد من الفهارس فحسب ، بل يمكن أن تتداخل أيضًا ، لذلك فقد برنامج جدولة Postgres ولم يفهم أي فهرس يجب استخدامه.
2. التالي في السطر كان قسم الأخبار. تظهر المنشورات على الموقع كل يوم حتى لا يضيع المستخدم في تدفق المعلومات ، يجب فرز البيانات قبل الإصدار. هذا هو الغرض من البحث: يمكنك البحث في الموقع عن طريق مطابقة النص ، وفي نفس الوقت ربط عوامل تصفية إضافية ، نظرًا لأنها مصنوعة أيضًا من خلال Elastic.
3. ثم نقلنا معالجة المعاملات. يمكن للمستخدمين شراء منتج معين على الموقع والمشاركة في السحب على الجوائز. بعد عمليات الشراء هذه ، نقوم بمعالجة كمية كبيرة من البيانات ، خاصة في عطلات نهاية الأسبوع والأعياد. للمقارنة ، إذا كان عدد المشتريات في الأيام العادية يتراوح بين 1,5 و 2 مليون ، فيمكن أن يصل الرقم في أيام العطلات إلى 53 مليونًا.
في الوقت نفسه ، يجب معالجة البيانات في أقصر وقت ممكن - لا يحب المستخدمون انتظار النتيجة لعدة أيام. لا توجد طريقة لتحقيق مثل هذه المواعيد النهائية من خلال Postgres - لقد تلقينا غالبًا أقفالًا ، وأثناء معالجة جميع الطلبات ، لم يتمكن المستخدمون من التحقق مما إذا كانوا قد تلقوا جوائز أم لا. هذا ليس ممتعًا جدًا للأعمال ، لذلك قمنا بنقل المعالجة إلى Elasticsearch.
دورية
الآن يتم تكوين التحديثات على أساس الأحداث ، وفقًا للشروط التالية:
- نقاط البيع. بمجرد تلقينا البيانات من مصدر خارجي ، نبدأ التحديث على الفور.
- أخبار. بمجرد تحرير أي أخبار على الموقع ، يتم إرسالها تلقائيًا إلى Elastic.
هنا مرة أخرى تجدر الإشارة إلى مزايا Elastic. في Postgres ، عند إرسال طلب ، عليك الانتظار حتى يقوم بمعالجة جميع السجلات بصدق. يمكنك إرسال 10 سجل إلى Elastic والبدء في العمل على الفور ، دون انتظار توزيع السجلات عبر جميع الأجزاء. بالطبع ، قد لا ترى بعض Shard أو Replica البيانات على الفور ، ولكن كل شيء سيكون متاحًا قريبًا جدًا.
طرق التكامل
هناك طريقتان للتكامل مع Elastic:
- من خلال عميل أصلي عبر TCP. ينقرض برنامج التشغيل الأصلي تدريجيًا: لم يعد مدعومًا ، فلديه تركيب غير مريح للغاية. لذلك ، نحن لا نستخدمها عمليًا ونحاول التخلي عنها تمامًا.
- من خلال واجهة HTTP يمكنها استخدام كل من طلبات JSON وبناء جملة Lucene. آخر واحد هو محرك نص يستخدم Elastic. في هذا الإصدار ، نحصل على القدرة على الدفعة من خلال طلبات JSON عبر HTTP. هذا هو الخيار الذي نحاول استخدامه.
بفضل واجهة HTTP ، يمكننا استخدام المكتبات التي توفر تنفيذًا غير متزامن لعميل HTTP. يمكننا الاستفادة من Batch وواجهة برمجة التطبيقات غير المتزامنة ، مما يؤدي إلى أداء عالٍ ، مما ساعد كثيرًا في أيام الترويج الكبير (المزيد حول ذلك أدناه)
بعض الأرقام للمقارنة:
- حفظ مستخدمي مكافأة Postgres في 20 موضوعًا بدون تجميع: 460713 سجل في 42 ثانية
- عميل مرن + تفاعلي لـ 10 خيوط + دفعة لـ 1000 عنصر: 596749 سجل في 11 ثانية
- عميل مرن + متفاعل لـ 10 خيوط + دفعة لـ 1000 عنصر: 23801684 إدخالات في 4 دقائق
لقد كتبنا الآن مدير طلبات HTTP الذي يبني JSON على أنه دفعة / ليس دفعة ويرسلها عبر أي عميل HTTP ، بغض النظر عن المكتبة. يمكنك أيضًا اختيار إرسال الطلبات بشكل متزامن أو غير متزامن.
في بعض عمليات الدمج ، ما زلنا نستخدم عميل النقل الرسمي ، ولكن هذه مجرد مسألة إعادة بناء ديون تالية. في هذه الحالة ، يتم استخدام عميل مخصص تم إنشاؤه على أساس Spring WebClient للمعالجة.
ترقية كبيرة
مرة واحدة في العام ، يستضيف المشروع عرضًا ترويجيًا كبيرًا للمستخدمين - وهذا هو نفس Highload ، نظرًا لأننا نعمل في هذا الوقت مع عشرات الملايين من المستخدمين في نفس الوقت.
عادة ما تحدث ذروة الأحمال خلال الإجازات ، لكن هذا الترويج على مستوى مختلف تمامًا. في العام السابق ، في يوم العرض الترويجي ، قمنا ببيع 27،580،890 وحدة من البضائع. تمت معالجة البيانات لأكثر من نصف ساعة ، مما تسبب في إزعاج المستخدمين. حصل المستخدمون على جوائز للمشاركة ، لكن اتضح أن العملية بحاجة إلى التعجيل.
في بداية عام 2019 ، قررنا أننا بحاجة إلى ElasticSearch. لمدة عام كامل ، قمنا بتنظيم معالجة البيانات المستلمة في Elastic وإصدارها في api لتطبيق الهاتف المحمول والموقع الإلكتروني. نتيجة لذلك ، في العام التالي خلال الحملة ، قمنا بمعالجة 15 مدخل في 131 دقائق.
نظرًا لأن لدينا الكثير من الأشخاص الذين يرغبون في شراء السلع والمشاركة في سحب الجوائز في العروض الترويجية ، فهذا إجراء مؤقت. نرسل الآن معلومات محدثة إلى Elastic ، لكننا نخطط في المستقبل لنقل المعلومات المؤرشفة للأشهر الماضية إلى Postgres كمخزن دائم. من أجل عدم انسداد مؤشر المرونة ، والذي له أيضًا حدوده.
الاستنتاج / الاستنتاجات
في الوقت الحالي ، قمنا بنقل جميع الخدمات التي أردناها إلى Elastic وتوقفنا عن ذلك مؤقتًا في الوقت الحالي. نقوم الآن ببناء فهرس في Elastic فوق التخزين الثابت الرئيسي في Postgres ، والذي يتولى تحميل المستخدم.
في المستقبل ، نخطط لنقل الخدمات إذا فهمنا أن طلب البيانات يصبح شديد التنوع ويتم البحث عن عدد غير محدود من الأعمدة. لم تعد هذه مهمة Postgres.
إذا احتجنا إلى البحث عن نص كامل في الوظائف أو إذا كان لدينا الكثير من معايير البحث المختلفة ، فنحن نعلم بالفعل أن هذا يحتاج إلى الترجمة إلى Elastic.
⌘⌘⌘
شكرا للقراءة. إذا كانت شركتك تستخدم أيضًا ElasticSearch ولديها حالات التنفيذ الخاصة بها ، فأخبرنا بذلك. سيكون من المثير للاهتمام معرفة كيف حال الآخرين
المصدر: www.habr.com