Salom, Xabr! Mening ismim Maksim Vasilev, men FINCH kompaniyasida tahlilchi va loyiha menejeri bo'lib ishlayman. Bugun men sizga ElasticSearch yordamida qanday qilib biz 15 daqiqada 6 million so'rovni qayta ishlashga muvaffaq bo'lganimizni va mijozlarimizdan birining saytiga kunlik yuklashni optimallashtirishni aytmoqchiman. Afsuski, biz nomlarsiz qilishimiz kerak, chunki bizda NDA bor, maqolaning mazmuni bundan zarar ko'rmaydi deb umid qilamiz. Qani ketdik.
Loyiha qanday ishlaydi
Bizning orqa tomonimizda biz mijozimizning veb-saytlari va mobil ilovasining ishlashini ta'minlaydigan xizmatlarni yaratamiz. Umumiy tuzilmani diagrammada ko'rish mumkin:
Ish jarayonida biz juda ko'p miqdordagi tranzaktsiyalarni qayta ishlaymiz: xaridlar, to'lovlar, foydalanuvchi qoldiqlari bilan operatsiyalar, ular uchun biz juda ko'p jurnallarni saqlaymiz, shuningdek, ushbu ma'lumotlarni tashqi tizimlarga import qilamiz va eksport qilamiz.
Mijozdan ma'lumotlarni qabul qilib, foydalanuvchiga uzatganimizda ham teskari jarayonlar mavjud. Bundan tashqari, to'lovlar va bonus dasturlari bilan ishlash jarayonlari ham mavjud.
Qisqacha fon
Dastlab biz PostgreSQL-ni yagona ma'lumotlarni saqlashimiz sifatida ishlatardik. Uning afzalliklari DBMS uchun standartdir: tranzaktsiyalarning mavjudligi, ishlab chiqilgan ma'lumotlarni qidirish tili, integratsiya uchun keng ko'lamli vositalar; yaxshi ishlash bilan birgalikda bizning ehtiyojlarimizni uzoq vaqt davomida qondirdi.
Biz Postgres-da mutlaqo barcha ma'lumotlarni saqladik: tranzaktsiyalardan tortib yangiliklargacha. Ammo foydalanuvchilar soni ko'paydi va shu bilan birga so'rovlar soni ham ko'paydi.
Tushunish uchun, 2017 yilda ish stoli saytida yillik sessiyalar soni 131 millionni tashkil etdi. 2018 yilda - 125 million. 2019 yilda yana 130 million. Sayt va mobil ilovaning mobil versiyasidan yana 100-200 million qo'shing va siz juda ko'p sonli so'rovlarni oladi.
Loyiha o'sib ulg'aygan sari, Postgres endi yukni bardosh bera olmadi; biz davom eta olmadik - ko'plab turli xil so'rovlar paydo bo'ldi, ular uchun biz etarli miqdordagi indekslarni yarata olmadik.
Bizning ehtiyojlarimizni qondiradigan va PostgreSQL yukini olib tashlaydigan boshqa ma'lumotlar do'konlariga ehtiyoj borligini tushundik. Mumkin variantlar sifatida Elasticsearch va MongoDB ko'rib chiqildi. Ikkinchisi quyidagi nuqtalarda mag'lub bo'ldi:
- Indekslardagi ma'lumotlar hajmi oshgani sayin sekin indekslash tezligi. Elastik bilan tezlik ma'lumotlar miqdoriga bog'liq emas.
- Toʻliq matnli qidiruv yoʻq
Shunday qilib, biz o'zimiz uchun Elastikni tanladik va o'tishga tayyorgarlik ko'rdik.
Elastikga o'tish
1. Biz o'tishni savdo nuqtalarini qidirish xizmati bilan boshladik. Bizning mijozimiz jami 70 000 ga yaqin savdo nuqtalariga ega va shu bilan birga veb-saytda va ilovada bir nechta qidiruv turlari talab qilinadi:
- Mahalliy nomi boʻyicha matnli qidiruv
- Ma'lum bir nuqtadan ma'lum radiusda geoizlanish. Misol uchun, agar foydalanuvchi qaysi savdo nuqtalari uning uyiga eng yaqin ekanligini ko'rishni xohlasa.
- Berilgan kvadrat bo'yicha qidirish - foydalanuvchi xaritada kvadratni belgilaydi va bu radiusdagi barcha nuqtalar unga ko'rsatiladi.
- Qo'shimcha filtrlar bo'yicha qidiruv. Savdo nuqtalari assortimentda bir-biridan farq qiladi
Tashkilot haqida gapiradigan bo'lsak, Postgres-da biz xarita va yangiliklar uchun ma'lumotlar manbasiga egamiz va Elastic-da biz asl ma'lumotlardan suratlar yaratamiz. Gap shundaki, dastlab Postgres barcha mezonlarni qidirishga dosh bera olmadi. Indekslar nafaqat ko'p edi, balki ular bir-biriga mos kelishi ham mumkin edi, shuning uchun Postgres rejalashtiruvchisi yo'qoldi va qaysi indeksdan foydalanishni tushunmadi.
2. Keyingi navbatda yangiliklar bo'limi edi. Nashrlar har kuni saytda paydo bo'ladi, shunda foydalanuvchi ma'lumot oqimida yo'qolib qolmaydi, ma'lumotlar berishdan oldin saralanishi kerak. Bu qidiruv uchun: saytda siz matn mosligi bo'yicha qidirishingiz va shu bilan birga qo'shimcha filtrlarni ulashingiz mumkin, chunki ular Elastik orqali ham amalga oshiriladi.
3. Keyin biz tranzaksiyani qayta ishlashga o'tdik. Foydalanuvchilar saytda ma'lum bir mahsulotni xarid qilishlari va sovrinlar o'yinida ishtirok etishlari mumkin. Bunday xaridlardan so'ng biz katta hajmdagi ma'lumotlarni qayta ishlaymiz, ayniqsa dam olish kunlari va bayramlarda. Taqqoslash uchun, agar oddiy kunlarda xaridlar soni 1,5-2 million atrofida bo'lsa, bayramlarda bu ko'rsatkich 53 millionga yetishi mumkin.
Shu bilan birga, ma'lumotlar minimal vaqt ichida qayta ishlanishi kerak - foydalanuvchilar natijalarni bir necha kun kutishni yoqtirmaydi. Postgres orqali bunday muddatlarga erishishning iloji yo'q - biz tez-tez bloklarni oldik va biz barcha so'rovlarni ko'rib chiqayotganimizda, foydalanuvchilar sovrinlarni olgan yoki olmaganligini tekshira olmadilar. Bu biznes uchun unchalik yoqimli emas, shuning uchun biz qayta ishlashni Elasticsearch-ga o'tkazdik.
davriyligi
Endi yangilanishlar quyidagi shartlarga muvofiq voqealarga asoslangan holda sozlanadi:
- Savdo nuqtalari. Biz tashqi manbadan ma'lumot olishimiz bilanoq darhol yangilanishni ishga tushiramiz.
- Yangiliklar. Saytda har qanday yangilik tahrirlangan zahoti u avtomatik ravishda Elastic-ga yuboriladi.
Bu erda yana Elastikning afzalliklarini eslatib o'tish kerak. Postgres-da, so'rov yuborayotganda, u barcha yozuvlarni halollik bilan qayta ishlaguncha kutishingiz kerak. Siz Elastic-ga 10 mingta yozuvni yuborishingiz va yozuvlar barcha Shardlarga tarqatilishini kutmasdan darhol ishlashni boshlashingiz mumkin. Albatta, ba'zi Shard yoki Replica ma'lumotlarni darhol ko'rmasligi mumkin, lekin juda tez orada hamma narsa mavjud bo'ladi.
Integratsiya usullari
Elastic bilan integratsiya qilishning ikkita usuli mavjud:
- TCP orqali mahalliy mijoz orqali. Mahalliy haydovchi asta-sekin o'lib bormoqda: u endi qo'llab-quvvatlanmaydi va uning sintaksisi juda noqulay. Shuning uchun biz amalda foydalanmaymiz va undan butunlay voz kechishga harakat qilamiz.
- JSON so'rovlari va Lucene sintaksisidan foydalanishingiz mumkin bo'lgan HTTP interfeysi orqali. Oxirgisi - Elastic ishlatadigan matn mexanizmi. Ushbu opsiyada biz HTTP orqali JSON so'rovlari orqali to'plash imkoniyatiga ega bo'lamiz. Bu biz foydalanmoqchi bo'lgan variant.
HTTP interfeysi tufayli biz HTTP mijozining asinxron amalga oshirilishini ta'minlaydigan kutubxonalardan foydalanishimiz mumkin. Biz Batch va asinxron API-dan foydalanishimiz mumkin, bu oxir-oqibatda yuqori samaradorlikni beradi, bu katta reklama kunlarida juda ko'p yordam berdi (quyida bu haqda batafsilroq)
Taqqoslash uchun ba'zi raqamlar:
- Postgres-da sovrinlarni olgan foydalanuvchilarni guruhlashsiz 20 ta mavzuda saqlash: 460713 soniyada 42 ta yozuv
- 10 ta ip uchun elastik + reaktiv mijoz + 1000 ta element uchun to'plam: 596749 soniyada 11 ta yozuv
- 10 ta ip uchun elastik + reaktiv mijoz + 1000 ta element uchun partiya: 23801684 daqiqada 4 ta yozuv
Endi biz HTTP so'rov boshqaruvchisini yozdik, u JSON-ni ommaviy/to'plamsiz sifatida quradi va kutubxonadan qat'i nazar, istalgan HTTP mijozi orqali yuboradi. Shuningdek, so'rovlarni sinxron yoki asinxron yuborishni tanlashingiz mumkin.
Ba'zi integratsiyalarda biz hali ham rasmiy transport mijozidan foydalanamiz, ammo bu darhol refaktoring masalasidir. Bunday holda, qayta ishlash uchun Spring WebClient asosida qurilgan o'z mijozi ishlatiladi.
Katta reklama
Yiliga bir marta loyiha foydalanuvchilar uchun katta reklama aksiyasini o'tkazadi - bu bir xil Highload, chunki hozirda biz bir vaqtning o'zida o'n millionlab foydalanuvchilar bilan ishlaymiz.
Odatda, eng yuqori yuklanishlar bayramlarda sodir bo'ladi, ammo bu reklama butunlay boshqacha darajada. O'tgan yil oldin, aksiya kunida biz 27 580 890 dona mahsulot sotgan edik. Ma'lumotlarni qayta ishlashga yarim soatdan ko'proq vaqt ketgan, bu esa foydalanuvchilarga noqulaylik tug'dirgan. Foydalanuvchilar ishtirok etish uchun sovg'alar olishdi, ammo jarayonni tezlashtirish kerakligi ma'lum bo'ldi.
2019 yil boshida biz ElasticSearch kerak deb qaror qildik. Bir yil davomida biz Elastic-da olingan ma'lumotlarni qayta ishlashni va uni mobil ilova va veb-sayt API-ga chiqarishni tashkil etdik. Natijada, biz qayta tashviq davomida keyingi yil 15 daqiqada 131 783 6 ta yozuv.
Aktsiyalarimizda mahsulotni sotib olish va sovrinlar o'yinida ishtirok etish istagida bo'lganlar ko'p ekan, bu vaqtinchalik chora. Endi biz joriy ma'lumotlarni Elastic-ga yuboramiz, ammo kelajakda o'tgan oylar uchun arxivlangan ma'lumotlarni Postgres-ga doimiy saqlash sifatida o'tkazishni rejalashtirmoqdamiz. Elastik indeksni to'sib qo'ymaslik uchun, bu ham o'z cheklovlariga ega.
Xulosa / Xulosa
Ayni paytda biz xohlagan barcha xizmatlarni Elastic-ga o'tkazdik va hozircha to'xtatib qo'ydik. Endi biz Postgres-dagi asosiy doimiy xotira ustiga Elastik-da indeks yaratmoqdamiz, bu foydalanuvchi yukini oladi.
Kelajakda, agar ma'lumotlar so'rovi juda xilma-xil bo'lib borayotganini va cheksiz sonli ustunlar uchun qidirilayotganini tushunsak, xizmatlarni uzatishni rejalashtirmoqdamiz. Bu Postgres uchun endi vazifa emas.
Agar biz funktsiyada to'liq matnli qidiruvga muhtoj bo'lsak yoki bizda juda ko'p turli xil qidirish mezonlari bo'lsa, biz buni Elastik tiliga tarjima qilish kerakligini allaqachon bilamiz.
⌘⌘⌘
O'qiganingiz uchun rahmat. Agar sizning kompaniyangiz ham ElasticSearch-dan foydalansa va o'zingizning amalga oshirish holatlaringiz bo'lsa, iltimos, bizga xabar bering. Boshqalar qanday qilishlarini bilish qiziq :)
Manba: www.habr.com