TL;DR: ოთხი წლის წინ მე დავტოვე გუგლი სერვერის მონიტორინგის ახალი ინსტრუმენტის იდეით. იდეა იყო ჩვეულებრივ იზოლირებული ფუნქციების გაერთიანება ერთ სერვისში კოლექცია და ჟურნალის ანალიზი, მეტრიკის შეგროვება, გაფრთხილებები და დაფები. ერთ-ერთი პრინციპია ის, რომ სერვისი უნდა იყოს ჭეშმარიტი სწრაფი, უზრუნველყოფს დევოპს მარტივ, ინტერაქტიულ, სასიამოვნო გამოცდილებას. ეს მოითხოვს მრავალ გიგაბაიტიანი მონაცემთა ნაკრების დამუშავებას წამის ნაწილებში, ბიუჯეტის ფარგლებში ყოფნისას. ჟურნალის მართვის არსებული ინსტრუმენტები ხშირად ნელი და უხერხულია, ამიტომ ჩვენ დავდექით კარგი გამოწვევის წინაშე: ჭკვიანურად შექმენით ხელსაწყოები, რათა მომხმარებლებს ახალი გამოცდილება მივცეთ.

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

ძველი სკოლის ძალა

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

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

ძირითადი მინიშნებები ამ სტატიიდან:

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

(ეს სტატია აღწერს მონაცემთა ძიებას მეხსიერებაში. უმეტეს შემთხვევაში, როდესაც მომხმარებელი ახორციელებს ჟურნალის ძიებას, Scalyr-ის სერვერებმა უკვე დააგროვეს ის. შემდეგ სტატიაში განიხილება არაქეშირებული ჟურნალების ძიება. იგივე პრინციპები მოქმედებს: ეფექტური კოდი, უხეში ძალა. დიდი გამოთვლითი რესურსებით).

უხეში ძალის მეთოდი

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

მე გამოვიყენე ეს მიდგომა Google-ში და ის კარგად მუშაობდა. მაგრამ Scalyr-ში ჩვენ ვეძებთ ჟურნალებს ბაიტი-ბაიტი.

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

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

ნამდვილი სირთულე მაშინ მოდის, როცა სიტყვებს არ ეძებ. ვთქვათ, გსურთ ნახოთ, რამდენი ტრეფიკი მოდის ბოტებიდან. პირველი აზრი არის ჟურნალებში მოძებნოთ სიტყვა "ბოტი". ასე იპოვით რამდენიმე ბოტს: Googlebot, Bingbot და მრავალი სხვა. მაგრამ აქ 'ბოტი' არ არის სიტყვა, არამედ მისი ნაწილი. თუ ინდექსში „bot“-ს მოვძებნით, ვერ ვიპოვით პოსტებს სიტყვა „Googlebot“. თუ თქვენ შეამოწმებთ ყველა სიტყვას ინდექსში და შემდეგ სკანირებთ ინდექსს ნაპოვნი საკვანძო სიტყვებისთვის, ძიება მნიშვნელოვნად შენელდება. შედეგად, ზოგიერთი ჟურნალის პროგრამა არ იძლევა სიტყვის ნაწილის ძიებას ან (საუკეთესო შემთხვევაში) უშვებს სპეციალურ სინტაქსს დაბალი შესრულებით. ჩვენ გვინდა ამის თავიდან აცილება.

კიდევ ერთი პრობლემა არის პუნქტუაცია. გსურთ იპოვოთ ყველა მოთხოვნა 50.168.29.7? რაც შეეხება გამართვის ჟურნალებს, რომლებიც შეიცავს [error]? ხელმოწერები ჩვეულებრივ გამოტოვებენ პუნქტუაციას.

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

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

საკვანძო სიტყვების ინდექსები ასევე დიდ ადგილს იკავებს და შენახვა არის მთავარი ღირებულება ჟურნალის მართვის სისტემაში.

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

უხეში ძალა მუშაობს, თუ თქვენ გაქვთ უხეში პრობლემა (და ბევრი ძალა)

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

ჩვენს საძიებო კოდს თავდაპირველად ჰქონდა საკმაოდ დიდი შიდა მარყუჟი. ჩვენ ვინახავთ შეტყობინებებს გვერდებზე 4K; თითოეული გვერდი შეიცავს რამდენიმე შეტყობინებას (UTF-8) და მეტამონაცემებს თითოეული შეტყობინებისთვის. მეტამონაცემები არის სტრუქტურა, რომელიც კოდირებს მნიშვნელობის სიგრძეს, შიდა შეტყობინების ID-ს და სხვა ველებს. ძიების ციკლი ასე გამოიყურებოდა:

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

(შეიძლება იკითხოთ, რატომ ვინახავთ შეტყობინებებს ამ ფორმატში 4K გვერდებით, ტექსტით და მეტამონაცემებით, ვიდრე უშუალოდ ჟურნალებთან მუშაობას. მრავალი მიზეზი არსებობს, რაც მთავრდება იმით, რომ Scalyr ძრავა შიგნიდან უფრო განაწილებულ მონაცემთა ბაზას ჰგავს, ვიდრე მონაცემთა ბაზას. ფაილური სისტემა. ტექსტის ძიება ხშირად შერწყმულია DBMS-ის სტილის ფილტრებთან ჟურნალის გაანალიზების შემდეგ. ჩვენ შეგვიძლია ერთდროულად მოვიძიოთ ათასობით ჟურნალი და მარტივი ტექსტური ფაილები არ არის შესაფერისი ჩვენი ტრანზაქციის, ტირაჟირებული, განაწილებული მონაცემთა მართვისთვის).

თავდაპირველად, ჩანდა, რომ ასეთი კოდი არ იყო ძალიან შესაფერისი უხეში ძალის ოპტიმიზაციისთვის. "ნამდვილი სამუშაო" in String.indexOf() CPU პროფილზეც კი არ დომინირებდა. ანუ მხოლოდ ამ მეთოდის ოპტიმიზაცია არ მოიტანს მნიშვნელოვან ეფექტს.

ხდება ისე, რომ ჩვენ ვინახავთ მეტამონაცემებს ყოველი გვერდის დასაწყისში, ხოლო UTF-8-ში ყველა შეტყობინების ტექსტი იფუთება მეორე ბოლოში. ამ უპირატესობით, ჩვენ ხელახლა ჩავწერეთ მარყუჟი მთელი გვერდის ერთდროულად მოსაძებნად:

ეს ვერსია მუშაობს პირდაპირ ხედზე raw byte[] და ეძებს ყველა შეტყობინებას ერთდროულად მთელ 4K გვერდზე.

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

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

ჩვენი განხორციელება მოითხოვს 64K საძიებო ცხრილის შექმნას თითოეული ძიებისთვის, მაგრამ ეს არაფერია იმ გიგაბაიტიან მონაცემებთან შედარებით, რომლებსაც ჩვენ ვეძებთ. შიდა მარყუჟი ამუშავებს რამდენიმე გიგაბაიტს წამში ერთ ბირთვზე. პრაქტიკაში, სტაბილური შესრულება არის დაახლოებით 1,25 GB წამში თითოეულ ბირთვზე და არის გაუმჯობესების ადგილი. შესაძლებელია შიდა მარყუჟის გარეთ არსებული ზედნადების ნაწილის აღმოფხვრა და ჩვენ ვგეგმავთ ექსპერიმენტების ჩატარებას შიდა მარყუჟით C-ში Java-ის ნაცვლად.

ჩვენ ვიყენებთ ძალას

ჩვენ განვიხილეთ, რომ ჟურნალის ძებნა შეიძლება განხორციელდეს "უხეშად", მაგრამ რამდენი "ძალა" გვაქვს? Საკმაოდ ბევრი.

1 იადრო: სწორად გამოყენებისას, თანამედროვე პროცესორის ერთი ბირთვი თავისთავად საკმაოდ ძლიერია.

8 ბირთვი: ამჟამად ვმუშაობთ Amazon hi1.4xlarge და i2.4xlarge SSD სერვერებზე, თითოეული 8 ბირთვით (16 თემა). როგორც ზემოთ აღინიშნა, ეს ბირთვები ჩვეულებრივ დაკავებულია ფონური ოპერაციებით. როდესაც მომხმარებელი ახორციელებს ძიებას, ფონური ოპერაციები შეჩერებულია, რაც ათავისუფლებს 8 ბირთვს საძიებლად. ძებნა, როგორც წესი, სრულდება წამის მეასედში, რის შემდეგაც ფონური მუშაობა განახლდება (გადამჭრელი პროგრამა უზრუნველყოფს, რომ საძიებო მოთხოვნის სიმრავლე არ შეუშლის ხელს მნიშვნელოვან ფონურ მუშაობას).

16 ბირთვი: საიმედოობისთვის, ჩვენ ვაწყობთ სერვერებს master/slave ჯგუფებად. თითოეულ მასტერს აქვს ერთი SSD და ერთი EBS სერვერი მისი მეთაურობით. თუ მთავარი სერვერი ავარიულია, SSD სერვერი დაუყოვნებლივ იკავებს ადგილს. თითქმის ყოველთვის, master და slave კარგად მუშაობს, ასე რომ, მონაცემთა თითოეული ბლოკის ძებნა შესაძლებელია ორ სხვადასხვა სერვერზე (EBS slave სერვერს აქვს სუსტი პროცესორი, ამიტომ ჩვენ არ განვიხილავთ მას). ჩვენ ვანაწილებთ მათ შორის დავალებას, რომ სულ გვაქვს 16 ბირთვი.

ბევრი ბირთვი: უახლოეს მომავალში, ჩვენ გავავრცელებთ მონაცემებს სერვერებზე ისე, რომ ისინი ყველა მონაწილეობენ ყველა არატრივიალური მოთხოვნის დამუშავებაში. ყველა ბირთვი იმუშავებს. [Შენიშვნა: განვახორციელეთ გეგმა და გავზარდეთ ძიების სიჩქარე 1 ტბ/წმ-მდე, იხილეთ შენიშვნა სტატიის ბოლოს].

სიმარტივე უზრუნველყოფს საიმედოობას

უხეში ძალის მეთოდის კიდევ ერთი უპირატესობა მისი საკმაოდ თანმიმდევრული შესრულებაა. როგორც წესი, ძიება არ არის ძალიან მგრძნობიარე პრობლემის დეტალებისა და მონაცემთა ნაკრების მიმართ (ვფიქრობ, ამიტომაც მას უწოდებენ "უხეში").

საკვანძო სიტყვების ინდექსი ზოგჯერ წარმოუდგენლად სწრაფ შედეგებს იძლევა, ზოგჯერ კი არა. დავუშვათ, რომ თქვენ გაქვთ 50 GB ჟურნალი, რომელშიც ტერმინი "customer_5987235982" არის ზუსტად სამჯერ. ამ ტერმინის ძიება ითვლის სამ ადგილს პირდაპირ ინდექსიდან და მყისიერად დასრულდება. მაგრამ კომპლექსური ველური ბარათების ძიებას შეუძლია ათასობით საკვანძო სიტყვის სკანირება და დიდი დრო დასჭირდეს.

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

უხეში ძალის მეთოდის სიმარტივე ნიშნავს, რომ მისი შესრულება ახლოსაა მის თეორიულ მაქსიმუმთან. დისკის მოულოდნელი გადატვირთვის, დაბლოკვის წინააღმდეგობის, მაჩვენებლის დევნისა და მარცხის ათასობით სხვა მიზეზის ნაკლები ვარიანტია. მე უბრალოდ გადავხედე Scalyr-ის მომხმარებლების მიერ გასულ კვირას ჩვენს ყველაზე დატვირთულ სერვერზე გაკეთებული მოთხოვნები. 14 მოთხოვნა იყო. ზუსტად რვა მათგანს ერთ წამზე მეტი დასჭირდა; 000% შესრულებულია 99 მილიწამში (თუ არ გამოგიყენებიათ ჟურნალის ანალიზის ხელსაწყოები, მერწმუნეთ: სწრაფია).

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

შესვლა ძიება მოქმედებაში

აქ არის მოკლე ანიმაცია, რომელიც აჩვენებს Scalyr ძიებას მოქმედებაში. ჩვენ გვაქვს დემო ანგარიში, სადაც ჩვენ შემოვიტანთ ყველა მოვლენას ყველა საჯარო Github საცავში. ამ დემო ვერსიაში მე განვიხილავ ერთი კვირის მონაცემებს: დაახლოებით 600 MB ნედლეული ჟურნალი.

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

დასასრულს

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

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

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

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

წყარო: www.habr.com