ძიების შედეგების გამომავალი და მუშაობის პრობლემები

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

პეიჯინგის ვარიანტი #1

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

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

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

მოდით შევხედოთ პირველ შეკითხვას სატესტო MS SQL მონაცემთა ბაზის მაგალითის გამოყენებით AdventureWorks 2016 წლის სერვერისთვის. ამ მიზნით ჩვენ გამოვიყენებთ Sales.SalesOrderHeader ცხრილს:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

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

ის სწრაფად მუშაობს სატესტო ბაზაზე, მაგრამ მოდით შევხედოთ შესრულების გეგმას და I/O სტატისტიკას:

Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

თქვენ შეგიძლიათ მიიღოთ I/O სტატისტიკა თითოეული მოთხოვნისთვის SET STATISTICS IO ON ბრძანების გაშვებით შეკითხვის შესრულების დროს.

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

Table 'SalesOrderHeader'. Scan count 1, logical reads 165, physical reads 0, read-ahead reads 5, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

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

SELECT * FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Table 'SalesOrderHeader'. Scan count 1, logical reads 1081, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

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

CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);

მაგალითების ეს სერია შეიძლება დიდხანს გაგრძელდეს, მაგრამ ორი ძირითადი აზრი, რომლის გამოხატვაც მინდა აქ არის:

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

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

SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100

ზემოთ მითითებული კომპოზიციური ინდექსის გათვალისწინებით, ჩვენ ვიღებთ:

Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

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

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

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

პეიჯინგის ვარიანტი #2

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

სინამდვილეში, ერთადერთი, რაც შეიცვალა არის ის, რომ არ არსებობს გზა კონკრეტულ გვერდის ნომრებზე ნავიგაციისთვის და ახლა ამ ცხრილს არ სჭირდება იმის ცოდნა, თუ რამდენი შეიძლება იყოს, რომ აჩვენოს იგი. მაგრამ ჩნდება კითხვა - როგორ იცის ცხრილმა, არის თუ არა მონაცემები შემდეგი გვერდისთვის (იმისთვის, რომ სწორად აჩვენოს "შემდეგი" ბმული)?

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

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

პეიჯინგის განხორციელების ნიუანსები

ზემოთ მოყვანილი შეკითხვის ყველა მაგალითი იყენებს „offset + count“ მიდგომას, როდესაც თავად შეკითხვა აზუსტებს, რა თანმიმდევრობით უნდა დაბრუნდეს შედეგის რიგები და რამდენი მწკრივი უნდა დაბრუნდეს. პირველ რიგში, მოდით შევხედოთ, თუ როგორ უნდა მოაწყოთ პარამეტრის გადაცემა ამ შემთხვევაში. პრაქტიკაში მე შევხვდი რამდენიმე მეთოდს:

• მოთხოვნილი გვერდის სერიული ნომერი (pageIndex), გვერდის ზომა (pageSize).
• დასაბრუნებელი პირველი ჩანაწერის სერიული ნომერი (startIndex), შედეგში ჩანაწერების მაქსიმალური რაოდენობა (დათვლა).
• დასაბრუნებელი პირველი ჩანაწერის მიმდევრობის ნომერი (startIndex), ბოლო დასაბრუნებელი ჩანაწერის მიმდევრობის ნომერი (endIndex).

ერთი შეხედვით შეიძლება ჩანდეს, რომ ეს იმდენად ელემენტარულია, რომ განსხვავება არ არის. მაგრამ ეს ასე არ არის - ყველაზე მოსახერხებელი და უნივერსალური ვარიანტია მეორე (startIndex, count). ამის რამდენიმე მიზეზი არსებობს:

• ზემოთ მოცემული +1 ჩანაწერის კორექტირების მიდგომისთვის, პირველი ვარიანტი pageIndex და pageSize უკიდურესად მოუხერხებელია. მაგალითად, გვსურს 50 პოსტის ჩვენება გვერდზე. ზემოაღნიშნული ალგორითმის მიხედვით, საჭიროა საჭიროზე მეტი ჩანაწერის წაკითხვა. თუ ეს „+1“ არ არის დანერგილი სერვერზე, გამოდის, რომ პირველი გვერდისთვის უნდა მოვითხოვოთ ჩანაწერები 1-დან 51-მდე, მეორესთვის - 51-დან 101-მდე და ა.შ. თუ მიუთითებთ გვერდის ზომას 51 და გაზრდით pageIndex-ს, მაშინ მეორე გვერდი დაბრუნდება 52-დან 102-მდე და ა.შ. შესაბამისად, პირველ ვარიანტში, შემდეგი გვერდზე გადასასვლელი ღილაკის სწორად დანერგვის ერთადერთი გზა არის სერვერის მიერ „დამატებითი“ ხაზის კორექტირება, რაც ძალიან იმპლიციტური ნიუანსი იქნება.
• მესამე ვარიანტს საერთოდ არ აქვს აზრი, რადგან მონაცემთა ბაზების უმეტესობაში მოთხოვნების გასაშვებად მაინც დაგჭირდებათ ბოლო ჩანაწერის და არა ინდექსის გადარიცხვა. startIndex-ის გამოკლება endIndex-ისგან შეიძლება მარტივი არითმეტიკული ოპერაცია იყოს, მაგრამ აქ ზედმეტია.

ახლა ჩვენ უნდა აღვწეროთ პეიჯინგის განხორციელების უარყოფითი მხარეები „ოფსეტური + რაოდენობა“:

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

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

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

და ბოლო ჩანაწერში მივიღეთ შეკვეთის თარიღის მნიშვნელობა '2014-06-29'. შემდეგ შემდეგი გვერდის მისაღებად შეგიძლიათ სცადოთ ამის გაკეთება:

SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

პრობლემა ის არის, რომ OrderDate არის არაუნიკალური ველი და ზემოთ მითითებულ პირობას სავარაუდოდ გამოტოვებს ბევრი საჭირო სტრიქონი. ამ მოთხოვნის გაურკვევლობის დასამატებლად, თქვენ უნდა დაამატოთ უნიკალური ველი პირობას (დავუშვათ, რომ 75074 არის პირველადი გასაღების ბოლო მნიშვნელობა პირველი ნაწილიდან):

SELECT * FROM Sales.SalesOrderHeader
WHERE (OrderDate = '2014-06-29' AND SalesOrderID < 75074)
   OR (OrderDate < '2014-06-29')
ORDER BY OrderDate DESC, SalesOrderID DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

ეს პარამეტრი სწორად იმუშავებს, მაგრამ ზოგადად რთული იქნება ოპტიმიზაცია, რადგან მდგომარეობა შეიცავს OR ოპერატორს. თუ პირველადი გასაღების მნიშვნელობა იზრდება OrderDate-ის მატებასთან ერთად, მაშინ მდგომარეობა შეიძლება გამარტივდეს SalesOrderID-ის მიერ მხოლოდ ფილტრის დატოვებით. მაგრამ თუ არ არსებობს მკაცრი კორელაცია პირველადი გასაღების მნიშვნელობებსა და ველს შორის, რომლითაც დალაგებულია შედეგი, ამ OR-ის თავიდან აცილება შეუძლებელია DBMS-ების უმეტესობაში. გამონაკლისი, რომელიც მე ვიცი არის PostgreSQL, რომელიც სრულად უჭერს მხარს მრავალჯერადი შედარებებს და ზემოაღნიშნული პირობა შეიძლება დაიწეროს როგორც "WHERE (OrderDate, SalesOrderID) < ('2014-06-29', 75074)". ამ ორი ველის კომპოზიციური გასაღების გათვალისწინებით, ასეთი შეკითხვა საკმაოდ მარტივი უნდა იყოს.

მეორე ალტერნატიული მიდგომა შეიძლება მოიძებნოს, მაგალითად, ქ ElasticSearch გადახვევის API ან Cosmos DB — როდესაც მოთხოვნა, მონაცემების გარდა, აბრუნებს სპეციალურ იდენტიფიკატორს, რომლითაც შეგიძლიათ მიიღოთ მონაცემების შემდეგი ნაწილი. თუ ამ იდენტიფიკატორს აქვს შეუზღუდავი სიცოცხლე (როგორც Comsos DB-ში), მაშინ ეს შესანიშნავი გზაა პეიჯინგის განსახორციელებლად გვერდებს შორის თანმიმდევრული გადასვლით (ზემოთ ნახსენები #2 ვარიანტი). მისი შესაძლო უარყოფითი მხარეები: ის არ არის მხარდაჭერილი ყველა DBMS-ში; მომდევნო ნაწილის იდენტიფიკატორს შეიძლება ჰქონდეს შეზღუდული სიცოცხლე, რაც, როგორც წესი, არ არის შესაფერისი მომხმარებლის ინტერაქციის განსახორციელებლად (როგორიცაა ElasticSearch გადახვევის API).

კომპლექსური ფილტრაცია

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

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

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

• კატეგორიების ჯგუფში თითოეული კრიტერიუმისთვის, ამ კატეგორიის პროდუქტების რაოდენობა ნაჩვენები იქნება შავით.
• "ფერები" ჯგუფის თითოეული კრიტერიუმისთვის ნაჩვენები იქნება ამ ფერის ველოსიპედების რაოდენობა.

აქ მოცემულია ასეთი პირობების შედეგის მაგალითი:

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

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

SELECT pc.ProductCategoryID, pc.Name, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
  INNER JOIN Production.ProductCategory pc ON ps.ProductCategoryID = pc.ProductCategoryID
WHERE p.Color = 'Black'
GROUP BY pc.ProductCategoryID, pc.Name
ORDER BY COUNT(1) DESC

SELECT Color, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
WHERE ps.ProductCategoryID = 1 --Bikes
GROUP BY Color
ORDER BY COUNT(1) DESC

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

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

• შეუთავსეთ ყველა რაოდენობის რაოდენობა ერთ შეკითხვაში. ტექნიკურად ეს შესაძლებელია UNION საკვანძო სიტყვის გამოყენებით, მაგრამ ეს დიდად არ დაეხმარება შესრულებას - მონაცემთა ბაზას მაინც მოუწევს თითოეული ფრაგმენტის ნულიდან შესრულება.
• ქეშის რაოდენობა. ამას შემომთავაზებენ თითქმის ყოველ ჯერზე, როცა პრობლემას აღვწერ. გაფრთხილება ის არის, რომ ეს ზოგადად შეუძლებელია. ვთქვათ, გვაქვს 10 „ასპექტი“, რომელთაგან თითოეულს აქვს 5 მნიშვნელობა. ეს ძალიან "მოკრძალებული" სიტუაციაა იმასთან შედარებით, რაც შეგიძლიათ ნახოთ იმავე ონლაინ მაღაზიებში. ერთი ასპექტის ელემენტის არჩევა გავლენას ახდენს 9 სხვაში არსებულ რაოდენობაზე, სხვა სიტყვებით რომ ვთქვათ, კრიტერიუმების თითოეული კომბინაციისთვის რაოდენობები შეიძლება იყოს განსხვავებული. ჩვენს მაგალითში არის 50 კრიტერიუმი, რომელიც მომხმარებელს შეუძლია აირჩიოს, შესაბამისად, იქნება 250 შესაძლო კომბინაცია. არ არის საკმარისი მეხსიერება ან დრო მონაცემთა ასეთი მასივის შესავსებად. აქ შეგიძლიათ გააპროტესტოთ და თქვათ, რომ ყველა კომბინაცია არ არის რეალური და მომხმარებელი იშვიათად ირჩევს 5-10-ზე მეტ კრიტერიუმს. დიახ, შესაძლებელია ზარმაცი ჩატვირთვა და ქეშირება მხოლოდ იმ რაოდენობით, რაც არჩეული იყო, მაგრამ რაც მეტი არჩევანი იქნება, მით უფრო ნაკლებად ეფექტური იქნება ასეთი ქეში და უფრო შესამჩნევი იქნება რეაგირების დროის პრობლემები (განსაკუთრებით თუ მონაცემთა ნაკრები რეგულარულად იცვლება).

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

• რაც შეიძლება იშვიათად მოვუწოდებთ "ასპექტების" სრულ გადაანგარიშებას. მაგალითად, არ გამოთვალოთ ყველაფერი ყოველ ჯერზე, როცა ძებნის კრიტერიუმები იცვლება, არამედ იპოვნეთ შედეგების საერთო რაოდენობა, რომლებიც შეესაბამება მიმდინარე პირობებს და სთხოვეთ მომხმარებელს აჩვენოს ისინი - „1425 ჩანაწერი ნაპოვნია, აჩვენე?“ მომხმარებელს შეუძლია განაგრძოს საძიებო ტერმინების შეცვლა ან დააწკაპუნოს ღილაკზე „ჩვენება“. მხოლოდ მეორე შემთხვევაში შესრულდება ყველა მოთხოვნა შედეგების მოპოვებისა და რაოდენობის ხელახალი გაანგარიშების შესახებ ყველა „ასპექტზე“. ამ შემთხვევაში, როგორც ადვილად ხედავთ, მოგიწევთ გაუმკლავდეთ თხოვნას შედეგების მთლიანი რაოდენობის მისაღებად და მისი ოპტიმიზაციისთვის. ეს მეთოდი შეგიძლიათ იხილოთ ბევრ პატარა ონლაინ მაღაზიაში. ცხადია, ეს არ არის ამ პრობლემის პანაცეა, მაგრამ მარტივ შემთხვევებში ეს შეიძლება იყოს კარგი კომპრომისი.
• გამოიყენეთ საძიებო სისტემები, რომ იპოვოთ შედეგები და დათვალოთ ასპექტები, როგორიცაა Solr, ElasticSearch, Sphinx და სხვა. ყველა მათგანი შექმნილია "ასპექტების" შესაქმნელად და ამას საკმაოდ ეფექტურად აკეთებს ინვერსიული ინდექსის გამო. როგორ მუშაობს საძიებო სისტემები, რატომ არიან ასეთ შემთხვევებში ისინი უფრო ეფექტური ვიდრე ზოგადი დანიშნულების მონაცემთა ბაზები, რა პრაქტიკა და ხარვეზები არსებობს - ეს ცალკე სტატიის თემაა. აქვე მინდა გავამახვილო თქვენი ყურადღება იმ ფაქტზე, რომ საძიებო სისტემა არ შეიძლება ჩაანაცვლოს ძირითადი მონაცემების შესანახად, იგი გამოიყენება როგორც დანამატი: ძირითადი მონაცემთა ბაზის ნებისმიერი ცვლილება, რომელიც შესაბამისია საძიებლად, სინქრონიზებულია საძიებო ინდექსში; საძიებო სისტემა ჩვეულებრივ ურთიერთქმედებს მხოლოდ საძიებო სისტემასთან და არ წვდება ძირითად მონაცემთა ბაზას. ერთ-ერთი ყველაზე მნიშვნელოვანი აქ არის ის, თუ როგორ უნდა მოაწყოთ ეს სინქრონიზაცია საიმედოდ. ეს ყველაფერი დამოკიდებულია "რეაქციის დროის" მოთხოვნებზე. თუ ძირითადი მონაცემთა ბაზის ცვლილებასა და ძიებაში მის „მანიფესტაციას“ შორის დრო არ არის კრიტიკული, შეგიძლიათ შექმნათ სერვისი, რომელიც ეძებს ახლახან შეცვლილ ჩანაწერებს ყოველ რამდენიმე წუთში ერთხელ და ახდენს მათ ინდექსირებას. თუ გსურთ რეაგირების უმოკლეს დრო, შეგიძლიათ განახორციელოთ მსგავსი რამ ტრანზაქციის გასავალი განახლებების გასაგზავნად საძიებო სამსახურში.

დასკვნები

1. სერვერის მხრიდან პეიჯინგის დანერგვა მნიშვნელოვანი გართულებაა და აზრი აქვს მხოლოდ სწრაფად მზარდი ან უბრალოდ დიდი მონაცემთა ნაკრებისთვის. არ არსებობს აბსოლუტურად ზუსტი რეცეპტი, თუ როგორ უნდა შეფასდეს "დიდი" ან "სწრაფად მზარდი", მაგრამ მე მივყვებოდი ამ მიდგომას:
   • თუ მონაცემთა სრული შეგროვების მიღება, სერვერის დროისა და ქსელის გადაცემის გათვალისწინებით, ნორმალურად შეესაბამება შესრულების მოთხოვნებს, არ აქვს აზრი სერვერის მხარეს პეიჯინგის განხორციელებას.
   • შეიძლება არსებობდეს სიტუაცია, როდესაც მუშაობის პრობლემები არ არის მოსალოდნელი უახლოეს მომავალში, რადგან მონაცემები მცირეა, მაგრამ მონაცემთა შეგროვება მუდმივად იზრდება. თუ მომავალში მონაცემთა გარკვეული ნაკრები შეიძლება აღარ დააკმაყოფილოს წინა პუნქტით, უმჯობესია დაუყოვნებლივ დაიწყოთ პეიჯინგი.
2. თუ ბიზნესის მხრიდან არ არსებობს მკაცრი მოთხოვნა შედეგების მთლიანი რაოდენობის ან გვერდების ნომრების ჩვენების შესახებ და თქვენს სისტემას არ აქვს საძიებო სისტემა, უმჯობესია არ განახორციელოთ ეს პუნქტები და განიხილოთ ვარიანტი #2.
3. თუ არსებობს მკაფიო მოთხოვნა სახის ძიებისთვის, თქვენ გაქვთ ორი ვარიანტი შესრულების შეწირვის გარეშე:
   • არ გამოთვალოთ ყველა რაოდენობა ყოველ ჯერზე, როცა ძებნის კრიტერიუმები იცვლება.
   • გამოიყენეთ საძიებო სისტემები, როგორიცაა Solr, ElasticSearch, Sphinx და სხვა. მაგრამ უნდა გვესმოდეს, რომ ის არ შეიძლება იყოს ძირითადი მონაცემთა ბაზის შემცვლელი და უნდა იქნას გამოყენებული, როგორც ძირითადი საცავის დამატება ძიების პრობლემების გადასაჭრელად.
4. ასევე, ასპექტირებული ძიების შემთხვევაში, აზრი აქვს ძიების შედეგების გვერდის მოძიება და დათვლა ორ პარალელურ მოთხოვნად გაიყოს. რაოდენობების დათვლას შეიძლება მეტი დრო დასჭირდეს, ვიდრე შედეგების მიღებას, მაშინ როცა შედეგები უფრო მნიშვნელოვანია მომხმარებლისთვის.
5. თუ თქვენ იყენებთ SQL მონაცემთა ბაზას საძიებლად, ამ ნაწილთან დაკავშირებული ნებისმიერი კოდის ცვლილება კარგად უნდა შემოწმდეს მონაცემების შესაბამის რაოდენობაზე მუშაობისთვის (ცოცხალ მონაცემთა ბაზაში მოცულობის გადაჭარბება). ასევე მიზანშეწონილია გამოიყენოს მოთხოვნის შესრულების დროის მონიტორინგი მონაცემთა ბაზის ყველა ინსტანციაზე და განსაკუთრებით „ცოცხალზე“. მაშინაც კი, თუ შეკითხვის გეგმებთან დაკავშირებით ყველაფერი კარგად იყო განვითარების ეტაპზე, მონაცემთა მოცულობის ზრდასთან ერთად, სიტუაცია შეიძლება შესამჩნევად შეიცვალოს.

წყარო: www.habr.com