Hey Habr! Mənim adım Maksim Vasilyevdir, mən FINCH-də analitik və layihə meneceri kimi işləyirəm. Bu gün sizə danışmaq istərdim ki, ElasticSearch-dən istifadə edərək, biz 15 dəqiqə ərzində 6 milyon sorğunu necə emal edə bilmişik və müştərilərimizdən birinin saytında gündəlik yükləmələri optimallaşdırmışıq. Təəssüf ki, adsız işləməli olacağıq, çünki NDA-mız var, ümid edirik ki, məqalənin məzmunu bundan əziyyət çəkməyəcək. Gedək.
Layihə necə işləyir
Biz öz arxa planımızda müştərimizin veb-saytlarının və mobil tətbiqinin işini təmin edən xidmətlər yaradırıq. Ümumi quruluşu diaqramda görmək olar:
İş prosesində biz çoxlu sayda əməliyyatları emal edirik: alışlar, ödənişlər, istifadəçi balansları ilə əməliyyatlar, bunun üçün çoxlu qeydlər saxlayırıq, həmçinin bu məlumatları xarici sistemlərə idxal və ixrac edirik.
Müştəridən məlumatları qəbul edib istifadəçiyə ötürdükdə də əks proseslər var. Bundan əlavə, ödənişlər və bonus proqramları ilə işləmək üçün hələ də proseslər var.
Qısa fon
Əvvəlcə PostgreSQL-dən yeganə məlumat anbarı kimi istifadə etdik. DBMS üçün onun standart üstünlükləri: əməliyyatların mövcudluğu, işlənmiş məlumat seçmə dili, inteqrasiya üçün geniş alətlər; yaxşı performansla birləşərək, kifayət qədər uzun müddət tələblərimizi təmin etdi.
Biz Postgres-də tamamilə bütün məlumatları saxladıq: əməliyyatlardan tutmuş xəbərlərə qədər. Ancaq istifadəçilərin sayı artdı və bununla da sorğuların sayı artdı.
Anlamaq üçün qeyd edək ki, 2017-ci ildə yalnız desktop saytında illik sessiyaların sayı 131 milyon. 2018-ci ildə - 125 milyon. 2019-cu ildə yenidən 130 milyon. Saytın mobil versiyasından və mobil proqramdan daha 100-200 milyon əlavə edin və siz çoxlu sayda müraciət alacaq.
Layihənin böyüməsi ilə Postgres yükün öhdəsindən gəlməyi dayandırdı, vaxtımız yox idi - çox sayda müxtəlif sorğular meydana çıxdı, bunun üçün kifayət qədər sayda indeks yarada bilmədik.
Biz başa düşdük ki, ehtiyaclarımızı təmin edəcək və PostgreSQL-dən yükü götürəcək digər məlumat anbarlarına ehtiyac var. Mümkün variantlar kimi Elasticsearch və MongoDB hesab edildi. Sonuncu aşağıdakı məqamlarda məğlub oldu:
- İndekslərdə məlumatların miqdarı artdıqca yavaş indeksləşdirmə sürəti. Elastik ilə sürət məlumatların miqdarından asılı deyil.
- Tam mətn axtarışı yoxdur
Beləliklə, biz özümüz üçün Elastik seçdik və keçidə hazırlaşdıq.
Elastikliyə keçid
1. Biz keçidə satış nöqtəsi axtarış xidmətindən başladıq. Müştərimizin cəmi 70-ə yaxın satış nöqtəsi var və bunun üçün saytda və tətbiqdə bir neçə növ axtarış tələb olunur:
- Şəhər adı ilə mətn axtarışı
- Müəyyən bir nöqtədən müəyyən bir radiusda geoaxtarış. Məsələn, istifadəçi hansı satış nöqtələrinin evinə ən yaxın olduğunu görmək istəyirsə.
- Verilmiş kvadrat üzrə axtarış - istifadəçi xəritədə kvadrat çəkir və bu radiusun bütün nöqtələri ona göstərilir.
- Əlavə filtrlərlə axtarın. Satış nöqtələri çeşidinə görə bir-birindən fərqlənir
Təşkilatdan danışırıqsa, Postgres-də həm xəritə, həm də xəbərlər üçün məlumat mənbəyimiz var və Elastic Snapshots-da orijinal məlumatlardan götürülür. Fakt budur ki, əvvəlcə Postgres bütün meyarlar üzrə axtarışın öhdəsindən gələ bilmədi. Nəinki çoxlu indekslər var idi, onlar da üst-üstə düşə bilərdi, buna görə Postgres planlaşdırıcısı itdi və hansı indeksdən istifadə edəcəyini başa düşmədi.
2. Növbəti sırada xəbərlər bölməsi var idi. Nəşrlər hər gün saytda görünür ki, istifadəçi məlumat axınında itməsin, məlumat verilməzdən əvvəl çeşidlənməlidir. Axtarışın məqsədi budur: siz saytda mətn uyğunluğu ilə axtarış edə və eyni zamanda əlavə filtrləri birləşdirə bilərsiniz, çünki onlar da Elastic vasitəsilə hazırlanır.
3. Sonra əməliyyatın işlənməsini köçürdük. İstifadəçilər saytda müəyyən bir məhsul ala və uduş tirajında iştirak edə bilərlər. Bu cür satınalmalardan sonra, xüsusən də həftə sonları və bayramlarda çoxlu məlumat emal edirik. Müqayisə üçün deyək ki, adi günlərdə alışların sayı hardasa 1,5-2 milyon arasındadırsa, bayram günlərində bu rəqəm 53 milyona çata bilər.
Eyni zamanda, məlumatlar ən qısa müddətdə işlənməlidir - istifadəçilər nəticəni bir neçə gün gözləməyi sevmirlər. Postgres vasitəsilə belə son tarixlərə çatmağın heç bir yolu yoxdur - biz tez-tez kilidlər alırdıq və bütün sorğuları emal edərkən istifadəçilər mükafat alıb-almadıqlarını yoxlaya bilmirdilər. Bu, biznes üçün o qədər də xoş deyil, ona görə də biz emal prosesini Elasticsearch-a köçürdük.
Dövrü
İndi yeniləmələr aşağıdakı şərtlərə uyğun olaraq hadisə əsasında konfiqurasiya edilir:
- Satış nöqtələri. Xarici mənbədən məlumat alan kimi dərhal yeniləməyə başlayırıq.
- Xəbərlər. Saytda hər hansı xəbər redaktə edilən kimi avtomatik olaraq Elastic-ə göndərilir.
Burada bir daha Elastikin üstünlüklərini qeyd etmək lazımdır. Postgres-də, sorğu göndərərkən, bütün qeydləri vicdanla emal edənə qədər gözləmək lazımdır. Elastik-ə 10 qeyd göndərə və qeydlərin bütün Shards arasında paylanmasını gözləmədən dərhal işə başlaya bilərsiniz. Əlbəttə ki, bəzi Shard və ya Replica məlumatları dərhal görməyə bilər, lakin hər şey çox tezliklə əlçatan olacaq.
İnteqrasiya üsulları
Elastic ilə inteqrasiyanın 2 yolu var:
- TCP üzərindən yerli müştəri vasitəsilə. Doğma sürücü tədricən ölür: artıq dəstəklənmir, çox əlverişsiz sintaksisə malikdir. Buna görə də biz praktiki olaraq ondan istifadə etmirik və onu tamamilə tərk etməyə çalışırıq.
- Həm JSON sorğularını, həm də Lucene sintaksisini istifadə edə bilən HTTP interfeysi vasitəsilə. Sonuncu, Elastic istifadə edən mətn mühərrikidir. Bu versiyada biz HTTP üzərindən JSON sorğuları vasitəsilə Batch etmək imkanı əldə edirik. Bu, istifadə etməyə çalışdığımız seçimdir.
HTTP interfeysi sayəsində biz HTTP müştərisinin asinxron həyata keçirilməsini təmin edən kitabxanalardan istifadə edə bilərik. Biz Batch və asinxron API-dən istifadə edə bilərik, bu da yüksək performansla nəticələnir və bu, böyük tanıtım günlərində çox kömək etdi (aşağıda daha ətraflı)
Müqayisə üçün bəzi rəqəmlər:
- Postgres mükafatı istifadəçilərini qruplaşdırmadan 20 mövzuda saxlamaq: 460713 saniyədə 42 qeyd
- 10 iplik üçün elastik + reaktiv müştəri + 1000 element üçün toplu: 596749 saniyədə 11 qeyd
- 10 iplik üçün elastik + reaktiv müştəri + 1000 element üçün toplu: 23801684 dəqiqə ərzində 4 giriş
İndi biz JSON-u Batch/Batch kimi quran və kitabxanadan asılı olmayaraq istənilən HTTP müştərisi vasitəsilə göndərən HTTP sorğu meneceri yazdıq. Siz həmçinin sorğuları sinxron və ya asinxron göndərməyi seçə bilərsiniz.
Bəzi inteqrasiyalarda biz hələ də rəsmi nəqliyyat müştərisindən istifadə edirik, lakin bu, yalnız növbəti refaktorinq məsələsidir. Bu halda, Spring WebClient əsasında qurulmuş xüsusi müştəri emal üçün istifadə olunur.
böyük promosyon
İldə bir dəfə, layihə istifadəçilər üçün böyük bir promosyona ev sahibliyi edir - bu, eyni Highload-dır, çünki hazırda biz eyni vaxtda on milyonlarla istifadəçi ilə işləyirik.
Adətən yüklərin pik həddi bayram günlərində baş verir, lakin bu təşviqat tamam başqa səviyyədədir. Ötən il, promosyon günündə biz 27 ədəd mal satdıq. Məlumatlar yarım saatdan çox işlənib və bu, istifadəçilər üçün narahatlıq yaradıb. İstifadəçilər iştirak üçün mükafatlar aldılar, lakin prosesi sürətləndirmək lazım olduğu aydın oldu.
2019-cu ilin əvvəlində ElasticSearch-ə ehtiyacımız olduğuna qərar verdik. Bütün il ərzində biz Elastic-də alınan məlumatların işlənməsini və mobil proqramın və vebsaytın api-də verilməsini təşkil etdik. Nəticədə, növbəti il kampaniya zamanı biz emal etdik 15 dəqiqə ərzində 131 giriş.
Bizdə mal almaq və promosyonlarda uduşların oynanılmasında iştirak etmək istəyənlərin sayı çox olduğundan bu, müvəqqəti tədbirdir. İndi biz Elastic-ə ən son məlumatları göndəririk, lakin gələcəkdə son aylar üçün arxivləşdirilmiş məlumatı daimi yaddaş kimi Postgres-ə köçürməyi planlaşdırırıq. Elastik indeksi tıxanmamaq üçün, onun da məhdudiyyətləri var.
Nəticə / Nəticələr
Hal-hazırda biz Elastik-ə istədiyimiz bütün xidmətləri köçürdük və hələlik buna fasilə verdik. İndi biz Postgres-də istifadəçi yükünü götürən əsas davamlı yaddaşın üstündə Elastic-də bir indeks qururuq.
Gələcəkdə biz məlumat sorğusunun həddən artıq müxtəlif olduğunu və limitsiz sayda sütun axtarıldığını başa düşsək, xidmətləri ötürməyi planlaşdırırıq. Bu artıq Postgres üçün bir vəzifə deyil.
Funksionallıqda tam mətn axtarışına ehtiyacımız varsa və ya çoxlu müxtəlif axtarış meyarlarımız varsa, bunun Elastik dilinə tərcümə edilməsi lazım olduğunu artıq bilirik.
⌘⌘⌘
Oxuduğunuz üçün təşəkkür edirik. Əgər sizin şirkətiniz də ElasticSearch-dən istifadə edirsə və özünün tətbiqi halları varsa, o zaman bizə deyin. Başqalarının necə olduğunu bilmək maraqlı olacaq 🙂
Mənbə: www.habr.com