Оптимизиране на натоварването на Highload проект с ElasticSearch

Хей Хабр! Казвам се Максим Василиев, работя като анализатор и ръководител на проекти във FINCH. Днес бих искал да ви разкажа как с помощта на ElasticSearch успяхме да обработим 15 милиона заявки за 6 минути и да оптимизираме ежедневните натоварвания на сайта на един от нашите клиенти. За съжаление ще трябва да се справим без имена, тъй като имаме NDA, надяваме се, че съдържанието на статията няма да пострада от това. Да тръгваме.

Как работи проектът

В нашия бекенд създаваме услуги, които гарантират ефективността на уебсайтовете и мобилното приложение на нашите клиенти. Общата структура може да се види на диаграмата:

В процеса на работа обработваме голям брой транзакции: покупки, плащания, операции с потребителски баланси, за които съхраняваме много регистрационни файлове, както и импортираме и експортираме тези данни към външни системи.

Има и обратни процеси, когато получаваме данни от клиента и ги предаваме на потребителя. Освен това все още има процеси за работа с плащания и бонус програми.

Кратка предистория

Първоначално използвахме PostgreSQL като единствено хранилище на данни. Неговите стандартни предимства за СУБД: наличието на транзакции, развит език за вземане на проби от данни, широк набор от инструменти за интеграция; съчетано с добро представяне задоволи нуждите ни за доста дълго време.

Ние съхранявахме абсолютно всички данни в Postgres: от транзакции до новини. Но броят на потребителите нараства, а с него и броят на заявките.

За разбиране годишният брой сесии през 2017 г. само на десктоп сайта е 131 млн. През 2018 г. - 125 млн. 2019 г. пак 130 млн. Добавете още 100-200 млн. от мобилната версия на сайта и мобилното приложение и вие ще получи огромен брой заявки.

С разрастването на проекта Postgres спря да се справя с натоварването, нямахме време - появиха се голям брой различни заявки, за които не можахме да създадем достатъчен брой индекси.

Разбрахме, че има нужда от други хранилища на данни, които да осигурят нашите нужди и да свалят натоварването от PostgreSQL. Elasticsearch и MongoDB бяха разгледани като възможни опции. Последният загуби по следните точки:

1. Бавна скорост на индексиране, тъй като количеството данни в индексите нараства. С Elastic скоростта не зависи от количеството данни.
2. Без пълнотекстово търсене

Така че избрахме Elastic за себе си и се подготвихме за прехода.

Преход към еластичен

1. Започнахме прехода от услугата за търсене на точки на продажба. Клиентът ни има общо около 70 000 точки на продажба, като това изисква няколко вида търсения в сайта и в приложението:

• Текстово търсене по име на град
• Географско търсене в даден радиус от някаква точка. Например, ако потребителят иска да види кои търговски обекти са най-близо до дома му.
• Търсене по зададен квадрат - потребителят чертае квадрат на картата и му се показват всички точки в този радиус.
• Търсене чрез допълнителни филтри. Точките за продажба се различават един от друг в асортимента

Ако говорим за организация, то в Postgres имаме източник на данни както за картата, така и за новините, а в Elastic Snapshots се вземат от оригиналните данни. Факт е, че първоначално Postgres не можа да се справи с търсенето по всички критерии. Не само, че имаше много индекси, те също можеха да се припокриват, така че планировчикът на Postgres се изгуби и не разбра кой индекс да използва.

2. Следващият по ред беше новинарският раздел. Публикациите се появяват на сайта всеки ден, така че потребителят да не се изгуби в потока от информация, данните трябва да бъдат сортирани преди издаване. За това е търсенето: можете да търсите в сайта по текстово съвпадение и в същото време да свържете допълнителни филтри, тъй като те също се правят чрез Elastic.

3. След това преместихме обработката на транзакцията. Потребителите могат да закупят определен продукт от сайта и да участват в теглене на награди. След такива покупки обработваме голямо количество данни, особено през почивните дни и празниците. За сравнение, ако в обикновените дни броят на покупките е някъде между 1,5-2 милиона, то през празниците цифрата може да достигне 53 милиона.

В същото време данните трябва да бъдат обработени във възможно най-кратки срокове - потребителите не обичат да чакат резултата няколко дни. Няма как да постигнем такива срокове чрез Postgres - често получавахме заключвания и докато обработвахме всички заявки, потребителите не можеха да проверят дали са получили награди или не. Това не е много приятно за бизнеса, затова преместихме обработката в Elasticsearch.

периодичност

Сега актуализациите се конфигурират въз основа на събития, съгласно следните условия:

1. Точки за продажба. Веднага щом получим данни от външен източник, веднага започваме актуализацията.
2. Новини. Веднага щом някоя новина бъде редактирана на сайта, тя автоматично се изпраща на Elastic.

Тук отново си струва да споменем предимствата на Elastic. В Postgres, когато изпращате заявка, трябва да изчакате, докато честно обработи всички записи. Можете да изпратите 10 XNUMX записа на Elastic и да започнете работа веднага, без да чакате записите да бъдат разпределени във всички Shards. Разбира се, някои Shard или Replica може да не видят данните веднага, но всичко ще бъде достъпно много скоро.

Интеграционни методи

Има 2 начина за интегриране с Elastic:

1. Чрез собствен клиент през TCP. Родният драйвер постепенно изчезва: вече не се поддържа, има много неудобен синтаксис. Затова практически не го използваме и се опитваме напълно да го изоставим.
2. Чрез HTTP интерфейс, който може да използва както JSON заявки, така и синтаксис Lucene. Последният е текстов двигател, който използва Elastic. В тази версия получаваме възможността да пакетираме чрез JSON заявки през HTTP. Това е опцията, която се опитваме да използваме.

Благодарение на HTTP интерфейса можем да използваме библиотеки, които осигуряват асинхронна реализация на HTTP клиента. Можем да се възползваме от Batch и асинхронния API, което води до висока производителност, което помогна много в дните на голямата промоция (повече за това по-долу)

Някои числа за сравнение:

• Запазване на Postgres bounty потребители в 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 783 влизания за 6 минути.

Тъй като имаме много хора, които искат да закупят стоки и да участват в тегленето на награди в промоции, това е временна мярка. Сега изпращаме актуална информация на Elastic, но в бъдеще планираме да прехвърлим архивирана информация за последните месеци в Postgres като постоянно хранилище. За да не се задръсти индексът на еластичността, който също има своите ограничения.

Заключение / заключения

В момента сме прехвърлили всички услуги, които искахме, към Elastic и засега сме спрели на това. Сега изграждаме индекс в Elastic върху основното постоянно хранилище в Postgres, което поема потребителското натоварване.

В бъдеще планираме да прехвърлим услуги, ако разберем, че заявката за данни става твърде разнообразна и се търси в неограничен брой колони. Това вече не е задача за Postgres.

Ако имаме нужда от търсене в пълен текст във функционалност или ако имаме много различни критерии за търсене, тогава вече знаем, че това трябва да бъде преведено в Elastic.

⌘⌘⌘

Благодаря за четенето. Ако вашата компания също използва ElasticSearch и има свои собствени случаи на внедряване, тогава ни кажете. Ще бъде интересно да знам как са другите 🙂

Източник: www.habr.com