ჩატვირთეთ ოპტიმიზაცია Highload პროექტზე ElasticSearch-ით

ჰეი ჰაბრ! მე მქვია მაქსიმ ვასილიევი, ვმუშაობ FINCH-ში ანალიტიკოსად და პროექტის მენეჯერად. დღეს მინდა გითხრათ, როგორ ElasticSearch-ის გამოყენებით შევძელით 15 წუთში 6 მილიონი მოთხოვნის დამუშავება და ჩვენი ერთ-ერთი კლიენტის საიტზე ყოველდღიური დატვირთვების ოპტიმიზაცია. სამწუხაროდ, სახელების გარეშე მოგვიწევს საქმე, რადგან ჩვენ გვაქვს NDA, ვიმედოვნებთ, რომ სტატიის შინაარსი ამით არ დაზარალდება. Წავედით.

როგორ მუშაობს პროექტი

ჩვენს ფონზე, ჩვენ ვქმნით სერვისებს, რომლებიც უზრუნველყოფენ ჩვენი კლიენტის ვებსაიტების და მობილური აპლიკაციების მუშაობას. ზოგადი სტრუქტურა ჩანს დიაგრამაში:

მუშაობის პროცესში ჩვენ ვამუშავებთ უამრავ ტრანზაქციას: შესყიდვებს, გადახდებს, ოპერაციებს მომხმარებლის ნაშთებით, რისთვისაც ვინახავთ უამრავ ჟურნალს, ასევე ამ მონაცემების იმპორტს და ექსპორტს გარე სისტემებში.

ასევე არსებობს საპირისპირო პროცესები, როდესაც ვიღებთ მონაცემებს კლიენტისგან და გადავცემთ მომხმარებელს. გარდა ამისა, ჯერ კიდევ არსებობს გადახდების და ბონუს პროგრამებთან მუშაობის პროცესები.

მოკლე ფონი

თავდაპირველად, ჩვენ ვიყენებდით PostgreSQL, როგორც მონაცემთა ერთადერთ მაღაზიას. მისი სტანდარტული უპირატესობები DBMS-ისთვის: ტრანზაქციების არსებობა, მონაცემთა შერჩევის განვითარებული ენა, ინტეგრაციის ინსტრუმენტების ფართო სპექტრი; კარგ შესრულებასთან ერთად საკმაოდ დიდი ხნის განმავლობაში აკმაყოფილებდა ჩვენს მოთხოვნილებებს.

ჩვენ ვინახავდით აბსოლუტურად ყველა მონაცემს Postgres-ში: ტრანზაქციებიდან სიახლეებამდე. მაგრამ მომხმარებელთა რაოდენობა გაიზარდა და მასთან ერთად მოთხოვნის რაოდენობაც.

გასაგებად, 2017 წელს სესიების წლიური რაოდენობა მხოლოდ დესკტოპ საიტზე არის 131 მილიონი, 2018 წელს - 125 მილიონი, 2019 წელს ისევ 130 მილიონი. დაამატეთ კიდევ 100-200 მილიონი საიტის მობილური ვერსიიდან და მობილური აპლიკაციიდან და თქვენ მიიღებს უამრავ მოთხოვნას.

პროექტის ზრდასთან ერთად, Postgres-მა შეწყვიტა დატვირთვის გამკლავება, დრო არ გვქონდა - გამოჩნდა დიდი რაოდენობით სხვადასხვა მოთხოვნა, რისთვისაც საკმარისი რაოდენობის ინდექსები ვერ შევქმენით.

ჩვენ გვესმოდა, რომ საჭირო იყო სხვა მონაცემთა მაღაზიები, რომლებიც უზრუნველყოფდნენ ჩვენს საჭიროებებს და ჩამოართმევდნენ დატვირთვას PostgreSQL. Elasticsearch და MongoDB განიხილებოდა, როგორც შესაძლო ვარიანტები. ამ უკანასკნელმა წააგო შემდეგ ქულებზე:

1. ინდექსირების ნელი სიჩქარე ინდექსებში მონაცემთა რაოდენობის მატებასთან ერთად. Elastic-ით, სიჩქარე არ არის დამოკიდებული მონაცემთა რაოდენობაზე.
2. სრული ტექსტის ძიება არ არის

ასე რომ, ჩვენ ავირჩიეთ ელასტიური ჩვენთვის და მოვემზადეთ გადასვლისთვის.

ელასტიურზე გადასვლა

1. დავიწყეთ გადასვლა გაყიდვების პუნქტის საძიებო სერვისიდან. ჩვენს კლიენტს აქვს სულ დაახლოებით 70 000 გაყიდვის პუნქტი და ეს მოითხოვს რამდენიმე სახის ძიებას საიტზე და აპლიკაციაში:

• ტექსტის ძიება ქალაქის სახელით
• გეოძიება მოცემულ რადიუსში რაღაც წერტილიდან. მაგალითად, თუ მომხმარებელს სურს ნახოს, რომელი სავაჭრო პუნქტია მის სახლთან ყველაზე ახლოს.
• ძიება მოცემული კვადრატის მიხედვით - მომხმარებელი ხაზავს კვადრატს რუკაზე და ამ რადიუსში ყველა წერტილი მას ეჩვენება.
• მოძებნეთ დამატებითი ფილტრებით. გასაყიდი პუნქტები ერთმანეთისგან განსხვავდება ასორტიმენტით

თუ ვსაუბრობთ ორგანიზაციაზე, მაშინ Postgres-ში გვაქვს მონაცემთა წყარო როგორც რუქისთვის, ასევე სიახლეებისთვის, ხოლო Elastic Snapshots აღებულია ორიგინალური მონაცემებიდან. ფაქტია, რომ თავდაპირველად Postgres ვერ უმკლავდებოდა ძიებას ყველა კრიტერიუმით. არა მხოლოდ ბევრი ინდექსი იყო, ისინი ასევე შეიძლება გადაფარონ, ამიტომ Postgres-ის განრიგი დაიკარგა და ვერ გაიგო, რომელი ინდექსი გამოეყენებინა.

2. შემდეგი იყო ახალი ამბების განყოფილება. საიტზე ყოველდღიურად ჩნდება პუბლიკაციები, რათა მომხმარებელი ინფორმაციის ნაკადში არ დაიკარგოს, გაცემამდე მონაცემები უნდა იყოს დახარისხებული. ძიება სწორედ ამისთვისაა: თქვენ შეგიძლიათ მოძებნოთ საიტი ტექსტის შესატყვისით და ამავდროულად დააკავშიროთ დამატებითი ფილტრები, რადგან ისინი ასევე მზადდება Elastic-ის საშუალებით.

3. შემდეგ გადავიტანეთ ტრანზაქციის დამუშავება. მომხმარებლებს შეუძლიათ შეიძინონ გარკვეული პროდუქტი საიტზე და მიიღონ მონაწილეობა საპრიზო გათამაშებაში. ასეთი შესყიდვების შემდეგ ჩვენ ვამუშავებთ დიდი რაოდენობით მონაცემებს, განსაკუთრებით შაბათ-კვირას და არდადეგებზე. შედარებისთვის, თუ ჩვეულებრივ დღეებში შესყიდვების რაოდენობა სადღაც 1,5-2 მილიონია, მაშინ დასვენების დღეებში ეს მაჩვენებელი შეიძლება 53 მილიონს მიაღწიოს.

ამავდროულად, მონაცემები უნდა დამუშავდეს უმოკლეს დროში - მომხმარებლებს არ უყვართ შედეგს რამდენიმე დღის ლოდინი. Postgres-ის საშუალებით ასეთი ვადების მიღწევის გზა არ არის - ჩვენ ხშირად ვიღებდით საკეტებს და სანამ ყველა მოთხოვნას ვამუშავებდით, მომხმარებლები ვერ ამოწმებდნენ მიიღეს თუ არა პრიზები. ეს არც თუ ისე სასიამოვნოა ბიზნესისთვის, ამიტომ დამუშავება გადავიტანეთ Elasticsearch-ში.

პერიოდულობა

ახლა განახლებები კონფიგურებულია მოვლენებზე დაფუძნებული, შემდეგი პირობების მიხედვით:

1. გაყიდვების პუნქტები. როგორც კი მივიღებთ მონაცემებს გარე წყაროდან, დაუყოვნებლივ ვიწყებთ განახლებას.
2. სიახლეები. როგორც კი რაიმე სიახლე მოხდება საიტზე რედაქტირებაში, ის ავტომატურად იგზავნება Elastic-ზე.

აქ კიდევ ერთხელ უნდა აღინიშნოს Elastic-ის უპირატესობები. Postgres-ში, მოთხოვნის გაგზავნისას, თქვენ უნდა დაელოდოთ სანამ ის გულწრფელად დაამუშავებს ყველა ჩანაწერს. თქვენ შეგიძლიათ გაგზავნოთ 10 ჩანაწერი Elastic-ში და დაუყოვნებლივ დაიწყოთ მუშაობა, არ დაელოდოთ ჩანაწერების გავრცელებას ყველა Shards-ში. რა თქმა უნდა, ზოგიერთმა Shard-მა ან Replica-მა შეიძლება დაუყოვნებლივ ვერ დაინახოს მონაცემები, მაგრამ ყველაფერი ძალიან მალე იქნება ხელმისაწვდომი.

ინტეგრაციის მეთოდები

Elastic-თან ინტეგრაციის 2 გზა არსებობს:

1. მშობლიური კლიენტის მეშვეობით TCP-ზე. მშობლიური დრაივერი თანდათან კვდება: ის აღარ არის მხარდაჭერილი, აქვს ძალიან მოუხერხებელი სინტაქსი. ამიტომ, ჩვენ პრაქტიკულად არ ვიყენებთ მას და ვცდილობთ მთლიანად მივატოვოთ იგი.
2. HTTP ინტერფეისის საშუალებით, რომელსაც შეუძლია გამოიყენოს როგორც JSON მოთხოვნები, ასევე Lucene სინტაქსი. ბოლო არის ტექსტური ძრავა, რომელიც იყენებს Elastic-ს. ამ ვერსიაში, ჩვენ ვიღებთ შესაძლებლობას ჯგუფური გავხადოთ JSON მოთხოვნები HTTP-ით. ეს არის ვარიანტი, რომლის გამოყენებასაც ვცდილობთ.

HTTP ინტერფეისის წყალობით, ჩვენ შეგვიძლია გამოვიყენოთ ბიბლიოთეკები, რომლებიც უზრუნველყოფენ HTTP კლიენტის ასინქრონულ განხორციელებას. ჩვენ შეგვიძლია ვისარგებლოთ Batch-ით და ასინქრონული API-ით, რაც იწვევს მაღალ შესრულებას, რაც ძალიან დაეხმარა დიდი აქციის დღეებში (დაწვრილებით ამის შესახებ ქვემოთ)

რამდენიმე რიცხვი შედარებისთვის:

• Postgres Bounty-ის მომხმარებლების შენახვა 20 თემაში დაჯგუფების გარეშე: 460713 ჩანაწერი 42 წამში
• ელასტიური + რეაქტიული კლიენტი 10 ძაფისთვის + პარტია 1000 ელემენტისთვის: 596749 ჩანაწერი 11 წამში
• ელასტიური + რეაქტიული კლიენტი 10 ძაფისთვის + პარტია 1000 ელემენტისთვის: 23801684 ჩანაწერი 4 წუთში

ახლა ჩვენ დავწერეთ HTTP მოთხოვნის მენეჯერი, რომელიც აშენებს JSON-ს როგორც Batch/not Batch და აგზავნის მას ნებისმიერი HTTP კლიენტის მეშვეობით, ბიბლიოთეკის მიუხედავად. თქვენ ასევე შეგიძლიათ აირჩიოთ მოთხოვნების გაგზავნა სინქრონულად ან ასინქრონულად.

ზოგიერთ ინტეგრაციაში ჩვენ კვლავ ვიყენებთ ოფიციალურ სატრანსპორტო კლიენტს, მაგრამ ეს მხოლოდ შემდეგი რეფაქტორირების საკითხია. ამ შემთხვევაში, დამუშავებისთვის გამოიყენება Spring WebClient-ის საფუძველზე შექმნილი საბაჟო კლიენტი.

დიდი ხელშეწყობა

წელიწადში ერთხელ, პროექტი მასპინძლობს დიდ აქციას მომხმარებლებისთვის - ეს არის იგივე Highload, რადგან ამ დროს ჩვენ ერთდროულად ვმუშაობთ ათობით მილიონ მომხმარებელთან.

როგორც წესი, დატვირთვის პიკი ხდება არდადეგების დროს, მაგრამ ეს აქცია სულ სხვა დონეზეა. გასულ წელს, აქციის დღეს გავყიდეთ 27 580 890 ერთეული საქონელი. მონაცემები ნახევარ საათზე მეტხანს მუშავდებოდა, რამაც მომხმარებლების დისკომფორტი გამოიწვია. მონაწილეებმა მიიღეს პრიზები მონაწილეობისთვის, მაგრამ გაირკვა, რომ პროცესის დაჩქარება იყო საჭირო.

2019 წლის დასაწყისში გადავწყვიტეთ, რომ გვჭირდებოდა ElasticSearch. მთელი წლის განმავლობაში ვაწყობდით მიღებული მონაცემების Elastic-ში დამუშავებას და მათ გაცემას მობილური აპლიკაციისა და ვებსაიტის api-ში. შედეგად, მომდევნო წელს კამპანიის დროს დავამუშავეთ 15 ჩანაწერი 131 წუთში.

ვინაიდან ჩვენ გვყავს ბევრი ადამიანი, ვისაც სურს შეიძინოს საქონელი და მონაწილეობა მიიღოს აქციებში პრიზების გათამაშებაში, ეს დროებითი ღონისძიებაა. ახლა ჩვენ ვუგზავნით განახლებულ ინფორმაციას Elastic-ს, მაგრამ სამომავლოდ ვგეგმავთ ბოლო თვეების საარქივო ინფორმაციის გადატანას Postgres-ში, როგორც მუდმივი საცავი. იმისათვის, რომ არ დაიბლოკოს ელასტიური ინდექსი, რომელსაც ასევე აქვს თავისი შეზღუდვები.

დასკვნა/დასკვნა

ამ დროისთვის, ჩვენ გადავიტანეთ ყველა სერვისი, რომელიც გვინდოდა ელასტიკს და ამ დროისთვის შევჩერდით. ახლა ჩვენ ვაშენებთ ინდექსს Elastic-ში Postgres-ში მთავარი მუდმივი შენახვის თავზე, რომელიც იღებს მომხმარებლის დატვირთვას.

სამომავლოდ, ჩვენ ვგეგმავთ სერვისების გადაცემას, თუ გავიგებთ, რომ მონაცემთა მოთხოვნა ძალიან მრავალფეროვანია და იძებნება სვეტების შეუზღუდავი რაოდენობა. ეს პოსტგრესისთვის აღარ არის ამოცანა.

თუ ჩვენ გვჭირდება სრული ტექსტის ძებნა ფუნქციონალურობაში, ან თუ გვაქვს მრავალი განსხვავებული საძიებო კრიტერიუმი, მაშინ უკვე ვიცით, რომ ეს უნდა ითარგმნოს Elastic-ზე.

⌘⌘⌘

Მადლობა წაკითხვისთვის. თუ თქვენი კომპანია ასევე იყენებს ElasticSearch-ს და აქვს საკუთარი განხორციელების შემთხვევები, მაშინ გვითხარით. საინტერესო იქნება სხვები როგორები არიან 🙂

წყარო: www.habr.com