Оптимизација на вчитување на проект Highload со ElasticSearch

Здраво, Хабр! Јас се викам Максим Василиев, работам како аналитичар и проект менаџер во FINCH. Денес би сакал да ви кажам како, користејќи го ElasticSearch, успеавме да обработиме 15 милиони барања за 6 минути и да го оптимизираме дневното оптоварување на страницата на еден од нашите клиенти. За жал, ќе мораме без имиња, бидејќи имаме НДА, се надеваме дека содржината на статијата нема да настрада од ова. Да одиме.

Како функционира проектот

На нашиот резервен состав создаваме услуги кои обезбедуваат функционалност на веб-страниците и мобилната апликација на нашите клиенти. Општата структура може да се види на дијаграмот:

Во процесот на работа, обработуваме голем број трансакции: набавки, плаќања, трансакции со салда на корисници, за кои складираме многу дневници, а исто така ги увезуваме и извезуваме овие податоци во надворешни системи.

Има и обратни процеси кога добиваме податоци од клиентот и ги пренесуваме до корисникот. Покрај тоа, постојат и процеси за работа со плаќања и бонус програми.

Кратка позадина

Првично, користевме PostgreSQL како единствено складирање податоци. Неговите предности се стандардни за DBMS: присуство на трансакции, развиен јазик за пребарување на податоци, широк опсег на алатки за интеграција; во комбинација со добри перформанси ги задоволуваше нашите потреби прилично долго време.

Ги складиравме апсолутно сите податоци во Postgres: од трансакции до вести. Но, растеше бројот на корисници, а со тоа и бројот на барања.

За да разберете, годишниот број на сесии во 2017 година само на десктоп страницата беше 131 милион. Во 2018 година - 125 милиони. Во 2019 година повторно 130 милиони. Додадете уште 100-200 милиони од мобилната верзија на страницата и мобилната апликација, и вие ќе добие колосален број барања.

Како што растеше проектот, Postgres повеќе не можеше да се справи со оптоварувањето; не можевме да продолжиме - се појавија голем број различни прашања, за кои не можевме да создадеме доволен број индекси.

Сфативме дека има потреба од други складишта за податоци кои ќе ги задоволат нашите потреби и ќе го отстранат товарот од PostgreSQL. Elasticsearch и MongoDB беа разгледани како можни опции. Вториот загуби на следните поени:

1. Бавна брзина на индексирање како што расте обемот на податоци во индексите. Со Elastic, брзината не зависи од количината на податоци.
2. Нема пребарување на целосен текст

Така ја избравме Еластик за себе и се подготвивме за транзицијата.

Префрлете се на Еластик

1. Ја започнавме транзицијата со услуга за пребарување на продажни места. Нашиот клиент има вкупно околу 70 продажни места, а во исто време се потребни неколку видови на пребарување на веб-страницата и во апликацијата:

• Пребарување текст по име на локалитетот
• Геопребарување во даден радиус од одредена точка. На пример, ако корисникот сака да види кои продажни места се најблиску до неговиот дом.
• Пребарување по даден квадрат - корисникот оцртува квадрат на мапата и му се прикажани сите точки во овој радиус.
• Пребарувајте по дополнителни филтри. Продажните места се разликуваат едни од други по асортиман

Зборувајќи за организацијата, во Postgres имаме извор на податоци и за мапата и за вестите, а во Elastic правиме Snapshots од оригиналните податоци. Факт е дека на почетокот Postgres не можеше да се справи со пребарувањето на сите критериуми. Не само што имаше многу индекси, тие исто така можеа да се преклопуваат, па распоредувачот на Postgres беше изгубен и не разбираше кој индекс да го користи.

2. Следна на ред беше делот за вести. Публикациите се појавуваат на страницата секој ден за корисникот да не се изгуби во протокот на информации, податоците мора да се подредат пред да се издадат. Ова е она за што е пребарувањето: на страницата можете да пребарувате по совпаѓање на текстот, а во исто време да поврзувате дополнителни филтри, бидејќи тие се направени и преку Elastic.

3. Потоа ја преместивме обработката на трансакциите. Корисниците можат да купат одреден производ на страницата и да учествуваат во наградното извлекување. По ваквите набавки, обработуваме голема количина на податоци, особено за време на викендите и празниците. За споредба, ако во нормални денови бројот на купувања е некаде околу 1,5-2 милиони, тогаш на празници бројката може да достигне 53 милиони.

Во исто време, податоците мора да се обработат за минимално време - корисниците не сакаат да чекаат неколку дена за резултати. Не постои начин да се постигнат такви рокови преку Postgres - често добивавме блокови, а додека ги обработувавме сите барања, корисниците не можеа да проверат дали добиле награди или не. Ова не е многу пријатно за бизнис, па ја префрливме обработката во Elasticsearch.

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

Сега ажурирањата се конфигурирани врз основа на настани, според следниве услови:

1. Продажни места. Штом добиеме податоци од надворешен извор, веднаш започнуваме ажурирање.
2. Вести. Штом било која вест е уредена на страницата, таа автоматски се испраќа до Еластик.

Тука повторно вреди да се споменат предностите на Еластик. Во Postgres, кога испраќате барање, треба да почекате додека искрено не ги обработи сите записи. Можете да испратите 10 илјади записи на Еластик и веднаш да започнете со работа, без да чекате записите да бидат дистрибуирани до сите Shards. Се разбира, некои Shard или Replica можеби нема да ги видат податоците веднаш, но многу наскоро сè ќе биде достапно.

Методи на интеграција

Постојат 2 начини да се интегрирате со Elastic:

1. Преку мајчин клиент преку TCP. Домашниот двигател постепено изумира: повеќе не е поддржан, а неговата синтакса е многу незгодна. Затоа, ние практично не го користиме и се обидуваме целосно да го напуштиме.
2. Преку интерфејс HTTP во кој можете да ги користите и барањата за JSON и синтаксата на Lucene. Последниот е текстуалниот мотор што го користи Elastic. Во оваа опција, ја добиваме можноста за Batch преку JSON барања преку HTTP. Ова е опцијата што се обидуваме да ја искористиме.

Благодарение на интерфејсот HTTP, можеме да користиме библиотеки кои обезбедуваат асинхрона имплементација на клиентот HTTP. Можеме да ги искористиме предностите на Batch и асинхроното API, кое на крајот дава високи перформанси, што многу помогна во деновите на голема промоција (повеќе за ова подолу)

Некои бројки за споредба:

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

Сега напишавме менаџер на барања за HTTP кој го гради JSON како Batch/non-Batch и го испраќа преку кој било клиент HTTP, без оглед на библиотеката. Можете исто така да изберете да испраќате барања синхроно или асинхроно.

Во некои интеграции сè уште го користиме официјалниот транспортен клиент, но ова е само прашање на итно рефакторирање. Во овој случај, неговиот сопствен клиент, изграден врз основа на Spring WebClient, се користи за обработка.

Голема промоција

Еднаш годишно, проектот е домаќин на голема промоција за корисниците - ова е истиот Highload, бидејќи во ова време работиме со десетици милиони корисници истовремено.

Вообичаено, врвните оптоварувања се случуваат за време на празници, но оваа промоција е на сосема друго ниво. Претходната година на денот на промоцијата продадовме 27 единици роба. Обработката на податоците траеше повеќе од половина час, што предизвика непријатности кај корисниците. Корисниците добија награди за учество, но стана јасно дека процесот треба да се забрза.

На почетокот на 2019 година, решивме дека е потребен ElasticSearch. Цела година организиравме обработка на примените податоци во Elastic и нивно излегување до API на мобилната апликација и веб-страница. Како резултат на тоа, следната година за време на промоцијата што ја обработивме 15 записи за 131 минути.

Бидејќи во нашите промоции имаме многу луѓе кои сакаат да го купат производот и да учествуваат во наградната игра, ова е привремена мерка. Сега испраќаме тековни информации до Elastic, но во иднина планираме да ги пренесеме архивираните информации за изминатите месеци во Postgres како трајно складирање. За да не се затне Еластичниот индекс, кој исто така има свои ограничувања.

Заклучок/Заклучоци

Во моментов сите услуги што ги сакавме ги префрливме на Еластик и засега паузиравме. Сега градиме индекс во Elastic на врвот на главното постојано складирање во Postgres, кое го презема корисничкото оптоварување.

Во иднина, планираме да пренесуваме услуги ако разбереме дека барањето за податоци станува премногу разновидно и се пребарува за неограничен број колони. Ова веќе не е задача за Postgres.

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

⌘⌘⌘

Ви благодариме за читањето. Ако вашата компанија исто така користи ElasticSearch и има свои случаи за имплементација, ве молиме кажете ни. Ќе биде интересно да се знае како прават другите :)

Извор: www.habr.com