Оптимизация на силовото натоварване на 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 хиляди записа и веднага да започнеш работа, без да чакаш, докато записите се разпределят по всички 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 клиент, независимо от библиотеката. Също така може да се избира синхронно или асинхронно изпращане на заявки.

В някои интеграции все още използваме официалния transport client, но това е просто въпрос на предстояща рефакторизация. За обработка се използва собствен клиент, построен на базата на 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