Хөөе Хабр! Намайг Максим Васильев гэдэг, би FINCH-д шинжээч, төслийн менежерээр ажилладаг. Өнөөдөр би та бүхэнд ElasticSearch ашиглан 15 минутын дотор 6 сая хүсэлтийг боловсруулж, нэг үйлчлүүлэгчийнхээ сайтын өдөр тутмын ачааллыг оновчтой болгож чадсаныг танд хэлэхийг хүсч байна. Харамсалтай нь бид нэргүй хийх хэрэгтэй болно, учир нь бид NDA-тай тул нийтлэлийн агуулга үүнээс зовохгүй байх гэж найдаж байна. Явцгаая.
Төсөл хэрхэн ажилладаг
Ар талд нь бид үйлчлүүлэгчийнхээ вэбсайт болон гар утасны програмын гүйцэтгэлийг хангах үйлчилгээг бий болгодог. Ерөнхий бүтцийг диаграмаас харж болно.
Ажлын явцад бид маш олон тооны гүйлгээг боловсруулдаг: худалдан авалт, төлбөр тооцоо, хэрэглэгчийн үлдэгдэлтэй холбоотой үйл ажиллагаа, үүнд зориулж бид маш их бүртгэл хадгалдаг, мөн эдгээр өгөгдлийг гадаад системд импортлох, экспортлох.
Үйлчлүүлэгчээс өгөгдлийг хүлээн авч, хэрэглэгч рүү шилжүүлэхэд урвуу процессууд бас байдаг. Нэмж дурдахад төлбөр, урамшууллын хөтөлбөртэй ажиллах процессууд байсаар байна.
Товч мэдээлэл
Эхэндээ бид PostgreSQL-ийг цорын ганц мэдээллийн сан болгон ашигладаг байсан. DBMS-ийн стандарт давуу талууд: гүйлгээ байгаа эсэх, өгөгдлийн түүвэрлэлтийн хэл, нэгтгэх өргөн хүрээний хэрэгсэл; сайн гүйцэтгэлтэй хослуулсан нь бидний хэрэгцээг нэлээд удаан хугацаанд хангасан.
Бид Postgres-д гүйлгээнээс эхлээд мэдээ хүртэл бүх өгөгдлийг хадгалсан. Гэвч хэрэглэгчдийн тоо өсч, түүнийг дагаад хүсэлтийн тоо ч нэмэгдэв.
Ойлгохын тулд 2017 онд зөвхөн ширээний сайт дээр 131 сая сеанс хийдэг. 2018 онд - 125 сая. 2019 онд дахин 130 сая. Сайтын гар утасны хувилбар болон гар утасны програмаас 100-200 саяыг нэмээрэй. асар олон тооны хүсэлтийг хүлээн авах болно.
Төслийн өсөлттэй холбоотойгоор Postgres ачааллыг даван туулахаа больсон тул бидэнд цаг хугацаа байсангүй - олон тооны янз бүрийн асуулга гарч ирсэн бөгөөд бид хангалттай тооны индекс үүсгэж чадаагүй юм.
Бидний хэрэгцээг хангах, PostgreSQL-ийн ачааллыг арилгах өөр мэдээллийн сангууд хэрэгтэй гэдгийг бид ойлгосон. Elasticsearch болон MongoDB боломжит хувилбарууд гэж үзсэн. Сүүлийнх нь дараах оноогоор хожигдсон.
- Индекс дэх өгөгдлийн хэмжээ өсөх тусам индексжүүлэх хурд удааширна. Elastic-ийн тусламжтайгаар хурд нь өгөгдлийн хэмжээнээс хамаардаггүй.
- Бүрэн текст хайлт байхгүй
Тиймээс бид өөрсдөө Elastic-ийг сонгож, шилжилтийн ажилд бэлтгэсэн.
Уян хатан руу шилжих
1. Бид борлуулалтын цэгийн хайлтын үйлчилгээнээс шилжилтийг эхлүүлсэн. Манай үйлчлүүлэгч нийт 70 орчим борлуулалтын цэгтэй бөгөөд энэ нь сайт болон програм дээр хэд хэдэн төрлийн хайлт хийх шаардлагатай.
- Текстийг хотын нэрээр хайх
- Тодорхой цэгээс өгөгдсөн радиус доторх гео хайлт. Жишээлбэл, хэрэв хэрэглэгч гэрт нь хамгийн ойр байгаа худалдааны цэгүүдийг харахыг хүсвэл.
- Өгөгдсөн квадратаар хайх - хэрэглэгч газрын зураг дээр дөрвөлжин зурж, энэ радиусын бүх цэгийг түүнд харуулна.
- Нэмэлт шүүлтүүрээр хайх. Борлуулалтын цэгүүд нь төрөл бүрийн хувьд өөр өөр байдаг
Хэрэв бид байгууллагын тухай ярих юм бол Postgres-д газрын зураг, мэдээний мэдээллийн эх сурвалж байгаа бөгөөд уян харимхай агшинд анхны өгөгдлөөс авсан болно. Баримт нь эхлээд Постгрес бүх шалгуураар хайлтыг даван туулж чадаагүй юм. Зөвхөн олон тооны индексүүд байсан төдийгүй тэд давхцаж болох тул Postgres төлөвлөгч төөрч, аль индексийг ашиглахаа ойлгосонгүй.
2. Дараагийн эгнээнд мэдээний хэсэг байв. Нийтлэлүүд өдөр бүр сайт дээр гарч ирдэг бөгөөд ингэснээр хэрэглэгч мэдээллийн урсгалд төөрөхгүй байхын тулд өгөгдлийг гаргахаас өмнө эрэмбэлсэн байх ёстой. Энэ нь хайлт хийхэд зориулагдсан зүйл юм: та сайтыг текстийн дагуу хайж олох боломжтой бөгөөд нэгэн зэрэг нэмэлт шүүлтүүрүүдийг холбох боломжтой, учир нь тэдгээр нь Elastic-ээр хийгдсэн байдаг.
3. Дараа нь бид гүйлгээний боловсруулалтыг шилжүүлсэн. Хэрэглэгчид сайтаас тодорхой бүтээгдэхүүнийг худалдан авч, сугалаанд оролцох боломжтой. Ийм худалдан авалт хийсний дараа бид их хэмжээний өгөгдөл боловсруулдаг, ялангуяа амралтын өдрүүд болон амралтын өдрүүдэд. Харьцуулбал, хэрэв энгийн өдрүүдэд худалдан авалтын тоо 1,5-2 сая хооронд байдаг бол баярын өдрүүдэд энэ тоо 53 саяд хүрч болно.
Үүний зэрэгцээ өгөгдлийг хамгийн богино хугацаанд боловсруулах ёстой - хэрэглэгчид үр дүнг хэд хоногийн турш хүлээх дургүй байдаг. Postgres-ээр дамжуулан ийм хугацаанд хүрэх арга байхгүй - бид ихэвчлэн түгжээ авдаг байсан бөгөөд бид бүх хүсэлтийг боловсруулж байх үед хэрэглэгчид шагнал авсан эсэхээ шалгаж чадахгүй байв. Энэ нь бизнесийн хувьд тийм ч таатай биш байгаа тул бид боловсруулалтыг Elasticsearch руу шилжүүлсэн.
Давтамж
Одоо шинэчлэлтүүдийг дараах нөхцлийн дагуу үйл явдалд тулгуурлан тохируулж байна.
- Борлуулалтын цэгүүд. Бид гадны эх сурвалжаас мэдээлэл хүлээн авмагц шинэчлэлтийг шууд эхлүүлнэ.
- Мэдээ. Сайт дээр ямар нэгэн мэдээ засварлагдсан даруйд автоматаар Elastic руу илгээгддэг.
Энд дахин Elastic-ийн давуу талыг дурдах нь зүйтэй. Postgres-д хүсэлт илгээхдээ бүх бүртгэлийг үнэн зөвөөр боловсруулах хүртэл хүлээх хэрэгтэй. Та Elastic руу 10 бичлэг илгээж, бүх Shards-д бүртгэл тараахыг хүлээхгүйгээр шууд ажиллаж эхлэх боломжтой. Мэдээжийн хэрэг, зарим Shard эсвэл Replica нь өгөгдлийг шууд харахгүй байж болох ч бүх зүйл тун удахгүй бэлэн болно.
Интеграцийн аргууд
Elastic-тай нэгдэх 2 арга бий:
- TCP-ээр дамжуулан уугуул үйлчлүүлэгчээр дамжуулан. Уугуул драйвер нь аажмаар устаж байна: энэ нь цаашид дэмжигдэхгүй, энэ нь маш тохиромжгүй синтакстай. Тиймээс бид үүнийг бараг ашигладаггүй бөгөөд бүрмөсөн орхихыг хичээдэг.
- JSON хүсэлт болон Lucene синтакс хоёуланг нь ашиглах боломжтой HTTP интерфейсээр дамжуулан. Сүүлийнх нь Elastic ашигладаг текст хөдөлгүүр юм. Энэ хувилбарт бид HTTP-ээр дамжуулан JSON хүсэлтээр багцлах боломжтой болсон. Энэ бол бидний ашиглахыг оролдож буй сонголт юм.
HTTP интерфейсийн ачаар бид HTTP клиентийн асинхрон хэрэгжилтийг хангадаг сангуудыг ашиглаж болно. Бид Багц болон асинхрон API-ийн давуу талыг ашиглах боломжтой бөгөөд энэ нь өндөр гүйцэтгэлийг бий болгодог бөгөөд энэ нь томоохон сурталчилгааны өдрүүдэд маш их тусалсан (доор илүү дэлгэрэнгүй)
Харьцуулах зарим тоо:
- Postgres шагналын хэрэглэгчдийг бүлэглэлгүйгээр 20 хэлхээнд хадгалах: 460713 секундэд 42 бичлэг
- Уян хатан + 10 урсгалтай реактив клиент + 1000 элементийн багц: 596749 секундэд 11 бичлэг
- 10 урсгалт уян хатан + реактив клиент + 1000 элементийн багц: 23801684 минутын дотор 4 бичлэг
Одоо бид JSON-г Багц биш / Багц хэлбэрээр бүтээж, номын сангаас үл хамааран дурын HTTP клиентээр дамжуулан илгээдэг HTTP хүсэлтийн менежерийг бичсэн. Та хүсэлтийг синхрон эсвэл асинхрон байдлаар илгээхийг сонгож болно.
Зарим интеграцид бид албан ёсны тээврийн үйлчлүүлэгчийг ашигладаг хэвээр байгаа ч энэ нь зөвхөн дараагийн рефакторинг хийх асуудал юм. Энэ тохиолдолд Spring WebClient дээр суурилсан захиалгат клиентийг боловсруулахад ашигладаг.
том сурталчилгаа
Жилд нэг удаа уг төсөл нь хэрэглэгчдэд зориулсан томоохон сурталчилгаа зохион байгуулдаг бөгөөд энэ нь яг л өндөр ачаалал юм, учир нь бид яг одоо хэдэн арван сая хэрэглэгчидтэй нэгэн зэрэг ажилладаг.
Ихэвчлэн амралтын үеэр ачаалал дээд цэгтээ хүрдэг боловч энэ урамшуулал огт өөр түвшинд байдаг. Өнгөрсөн жилийн өмнөх сурталчилгааны өдөр бид 27 ширхэг бараа борлуулсан. Мэдээллийг хагас цаг гаруй боловсруулсан нь хэрэглэгчдэд төвөг учруулсан. Хэрэглэгчид оролцсоны төлөө шагнал авсан боловч үйл явцыг хурдасгах шаардлагатай болсон нь тодорхой болсон.
2019 оны эхээр бид ElasticSearch хэрэгтэй гэж шийдсэн. Бүтэн жилийн турш бид хүлээн авсан өгөгдлийг Elastic дээр боловсруулж, гар утасны програм, вэбсайтын api дээр гаргах ажлыг зохион байгууллаа. Үүний үр дүнд дараа жил нь аяны үеэр бид боловсруулсан 15 минутын дотор 131 бичлэг орсон.
Манайд бараа бүтээгдэхүүн худалдан авах, урамшууллын сугалаанд оролцох хүсэлтэй хүмүүс их байгаа тул энэ нь түр зуурын арга хэмжээ юм. Одоо бид Elastic руу хамгийн сүүлийн үеийн мэдээллийг илгээж байгаа боловч ирээдүйд сүүлийн саруудын архивлагдсан мэдээллийг Postgres руу байнгын хадгалалт болгон шилжүүлэхээр төлөвлөж байна. Уян хатан индексийг бөглөрөхгүйн тулд энэ нь бас хязгаарлалттай байдаг.
Дүгнэлт/Дүгнэлт
Одоогоор бид хүссэн бүх үйлчилгээгээ Elastic руу шилжүүлсэн бөгөөд одоогоор үүнийг түр зогсоолоо. Одоо бид Postgres дахь хэрэглэгчийн ачааллыг хариуцдаг үндсэн хадгалалтын дээр Elastic-д индекс байгуулж байна.
Ирээдүйд бид өгөгдлийн хүсэлт хэт олон янз болж, хязгааргүй тооны багана хайж байгааг ойлговол үйлчилгээг шилжүүлэхээр төлөвлөж байна. Энэ нь Postgres-ийн даалгавар байхаа больсон.
Хэрэв бидэнд функциональ байдлаар бүрэн текст хайлт хэрэгтэй бол эсвэл бидэнд олон төрлийн хайлтын шалгуур байгаа бол үүнийг Elastic руу орчуулах хэрэгтэй гэдгийг бид аль хэдийн мэдэж байсан.
⌘⌘⌘
Уншсанд баярлалаа. Хэрэв танай компани ElasticSearch ашигладаг бөгөөд өөрийн гэсэн хэрэглүүртэй бол бидэнд хэлээрэй. Бусад нь ямар байгааг мэдэх нь сонирхолтой байх болно 🙂
Эх сурвалж: www.habr.com