Оптимизация на натоварването в 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 и се подготвихме за миграцията.

Миграция към Elastic

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

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

Що се отнася до организацията, в Postgres имаме източник на данни както за картите, така и за новините, а в Elastic се правят Snapshot’и на оригиналните данни. Факт е, че първоначално Postgres не смогваше да се справи с търсенето по всички критерии. Освен това имаше много индекси, които можеха да се пресичат, затова планировчикът на Postgres се загубваше и не знаеше кой индекс да използва.

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

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

При това, данните трябва да се обработят за минимално време — потребителите не обичат да чакат резултати няколко дни. През Postgres не може да се постигне такъв срок — често получавахме блокировки и докато обработвахме всички заявки, потребителите не можеха да проверят дали са спечелили награди или не. Това не е много приятно за бизнеса, затова преместихме обработката в Elasticsearch.

Честота

В момента обновления са настроени на събития при следните условия:

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

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

Начини на интеграция

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

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

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

Някои цифри за сравнение:

• Запазване на потребители, получили награди в Postgres в 20 потока без агрегиране: 460713 записа за 42 секунди
• Elastic + реактивен клиент на 10 потока + batch на 1000 елемента: 596749 записа за 11 секунди
• Elastic + реактивен клиент на 10 потока + batch на 1000 елемента: 23801684 записа за 4 минути

В момента сме написали HTTP мениджър на заявки, който изгражда JSON, като Batch/не Batch и изпраща през всеки HTTP клиент независимо от библиотеката. Също така можем да избираме синхронно или асинхронно изпращане на заявки.

В някои интеграции все още използваме официалния транспортен клиент, но това е просто въпрос на предстояща рефакторинг. За обработка се използва собствен клиент, построен на база Spring WebClient.

Голяма акция

Веднъж годишно на проекта се провежда голямо събитие за потребителите — точно това е Highload, тъй като по това време работим с десетки милиони потребители едновременно.

Обикновено пиковете на натоварването се случват в празнични дни, но това събитие е на съвсем различно ниво. Преди две години на деня на събитието продадохме 27 580 890 единици стока. Данните се обработваха повече от половин час, което създаваше неудобства за потребителите. Потребителите получиха награди за участието си, но стана ясно, че процесът трябва да се ускори.

В началото на 2019 година решихме, че ни е нужен ElasticSearch. Цяла година организирахме обработката на получените данни в Elastic и тяхното извеждане в API на мобилното приложение и сайта. В крайна сметка, на следващата година по време на събитието обработихме 15 131 783 записа за 6 минути.

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

Заключение/изводи

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

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

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

⌘⌘⌘

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

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