Бізге таныс барлық қолданбалардағы типтік сценарийлердің бірі - белгілі бір критерийлерге сәйкес деректерді іздеу және оны оқуға оңай пішінде көрсету. Сондай-ақ сұрыптау, топтау және беттеу үшін қосымша опциялар болуы мүмкін. Тапсырма, теориялық тұрғыдан алғанда, тривиальды, бірақ оны шешу кезінде көптеген әзірлеушілер кейінірек өнімділіктің төмендеуіне әкелетін бірқатар қателіктер жібереді. Осы мәселені шешудің әртүрлі нұсқаларын қарастырып, ең тиімді іске асыруды таңдау бойынша ұсыныстарды тұжырымдап көрейік.
№1 пейджинг опциясы
Ең қарапайым нұсқа - іздеу нәтижелерін ең классикалық түрде көрсету.
Сіздің қолданбаңыз реляциялық дерекқорды пайдаланады делік. Бұл жағдайда ақпаратты осы пішінде көрсету үшін екі SQL сұрауын орындау қажет:
- Ағымдағы бетке жолдарды алыңыз.
- Іздеу критерийлеріне сәйкес келетін жолдардың жалпы санын есептеңіз - бұл беттерді көрсету үшін қажет.
Мысал ретінде сынақ MS SQL дерекқорын қолданып бірінші сұранысты қарастырайық 2016 серверіне арналған. Ол үшін Sales.SalesOrderHeader кестесін қолданамыз:
SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Жоғарыдағы сұрау қосудың кему күні бойынша сұрыпталған тізімдегі алғашқы 50 тапсырысты, басқаша айтқанда, ең соңғы 50 тапсырысты қайтарады.
Ол сынақ базасында жылдам жұмыс істейді, бірақ орындау жоспарын және енгізу/шығару статистикасын қарастырайық:
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.Әрбір сұрау үшін енгізу/шығару статистикасын сұраудың орындалу уақытында 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 өрісіне басқа индексті қосу арқылы шешіледі және нәтижесінде ол тек 48 логикалық оқуды береді.
Мөлшерді санауға арналған сұраулардың тағы бірнеше мысалын келтіруге болады, бірақ мәні өзгеріссіз қалады: деректер бөлігін алу және жалпы соманы санау - екі түбегейлі әртүрлі сұраулар, және әрқайсысы оңтайландыру үшін өз шараларын қажет етеді. Жалпы, сіз екі сұрау үшін де бірдей жақсы жұмыс істейтін индекстер тіркесімін таба алмайсыз.
Тиісінше, мұндай іздеу шешімін әзірлеу кезінде нақтылануы керек маңызды талаптардың бірі - бизнес үшін табылған объектілердің жалпы санын көру шынымен маңызды ма. Жоқ деген жиі кездеседі. Нақты бет нөмірлері бойынша шарлау, менің ойымша, өте тар ауқымды шешім, өйткені көптеген пейджинг сценарийлері «келесі бетке өту» сияқты көрінеді.
№2 пейджинг опциясы
Пайдаланушыларға табылған нысандардың жалпы санын білу маңызды емес деп есептейік. Іздеу бетін жеңілдетуге тырысайық:
Шындығында, өзгерген жалғыз нәрсе - нақты бет нөмірлеріне өту мүмкіндігі жоқ, енді бұл кесте оны көрсету үшін қанша болуы мүмкін екенін білудің қажеті жоқ. Бірақ сұрақ туындайды - кесте келесі бетке деректердің бар-жоғын қайдан біледі («Келесі» сілтемесін дұрыс көрсету үшін)?
Жауап өте қарапайым: дерекқордан көрсету үшін қажет болғаннан бір жазбаны көбірек оқуға болады және осы «қосымша» жазбаның болуы келесі бөліктің бар-жоғын көрсетеді. Осылайша, деректердің бір бетін алу үшін тек бір сұрауды орындау қажет, бұл өнімділікті айтарлықтай жақсартады және мұндай функционалдылықты қолдауды жеңілдетеді. Менің тәжірибемде жазбалардың жалпы санын санаудан бас тарту нәтижелерді жеткізуді 4-5 есе тездететін жағдай болды.
Бұл тәсіл үшін пайдаланушы интерфейсінің бірнеше опциялары бар: жоғарыдағы мысалдағыдай «артқа» және «алға» пәрмендері, көрсетілген нәтижелерге жай ғана жаңа бөлік қосатын «көбірек жүктеу» түймесі, жұмыс істейтін «шексіз айналдыру» «көбірек жүктеу» » принципі бойынша, бірақ келесі бөлікті алу сигналы пайдаланушыға көрсетілген барлық нәтижелерді соңына дейін айналдыруға арналған. Көрнекі шешім қандай болса да, деректерді іріктеу принципі өзгеріссіз қалады.
Пейджингті жүзеге асырудың нюанстары
Жоғарыда келтірілген барлық сұрау мысалдары сұраудың өзі нәтиже жолдарының қай ретпен және қанша жолды қайтару қажет екенін көрсеткенде, «офсет + санау» әдісін пайдаланады. Алдымен, бұл жағдайда параметрді беруді қалай жақсы ұйымдастыру керектігін қарастырайық. Іс жүзінде мен бірнеше әдістерді кездестірдім:
- Сұралған беттің сериялық нөмірі (pageIndex), бет өлшемі (pageSize).
- Қайтарылатын бірінші жазбаның сериялық нөмірі (startIndex), нәтижедегі жазбалардың ең көп саны (санақ).
- Қайтарылатын бірінші жазбаның реттік нөмірі (startIndex), қайтарылатын соңғы жазбаның реттік нөмірі (endIndex).
Бір қарағанда, бұл соншалықты қарапайым, ешқандай айырмашылық жоқ сияқты көрінуі мүмкін. Бірақ бұл олай емес - ең ыңғайлы және әмбебап нұсқа - екінші (startIndex, count). Мұның бірнеше себептері бар:
- Жоғарыда келтірілген +1 жазбаны түзету тәсілі үшін pageIndex және pageSize бар бірінші опция өте қолайсыз. Мысалы, біз бір бетке 50 жазбаны көрсеткіміз келеді. Жоғарыда келтірілген алгоритмге сәйкес, қажет болғаннан бір жазбаны көбірек оқу керек. Егер бұл «+1» серверде орындалмаса, бірінші бетте 1-ден 51-ге дейінгі жазбаларды, екіншісі үшін - 51-ден 101-ге дейін және т.б. сұрау керек екендігі белгілі болды. Бет өлшемін 51 етіп көрсетсеңіз және pageIndex мәнін арттырсаңыз, екінші бет 52-ден 102-ге дейін қайтарылады, т.б. Тиісінше, бірінші нұсқада келесі бетке өту үшін түймені дұрыс орындаудың жалғыз жолы - сервердің «қосымша» жолды тексеруі, бұл өте жасырын нюанс болады.
- Үшінші нұсқа мүлдем мағынасы жоқ, өйткені көптеген дерекқорларда сұрауларды орындау үшін соңғы жазбаның индексінен гөрі санауды тапсыру қажет болады. endIndex-тен startIndex-ті алып тастау қарапайым арифметикалық операция болуы мүмкін, бірақ бұл жерде артық.
Енді біз «офсет + сан» арқылы пейджингті енгізудің кемшіліктерін сипаттауымыз керек:
- Әрбір келесі бетті шығарып алу алдыңғыға қарағанда қымбатырақ және баяуырақ болады, өйткені дерекқор әлі де іздеу және сұрыптау критерийлеріне сәйкес барлық жазбаларды «басынан бастап» өтуі керек, содан кейін қажетті фрагментте тоқтауы керек.
- Барлық ДҚБЖ бұл тәсілді қолдамайды.
Баламалар бар, бірақ олар да жетілмеген. Осы тәсілдердің біріншісі «кілттер жиынтығы пейджинг» немесе «іздеу әдісі» деп аталады және келесідей: бөлікті алғаннан кейін беттегі соңғы жазбадағы өріс мәндерін есте сақтауға болады, содан кейін оларды алу үшін пайдалануға болады. келесі бөлік. Мысалы, біз келесі сұрауды орындадық:
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
Бұл опция дұрыс жұмыс істейді, бірақ шартта НЕМЕСЕ операторы бар болғандықтан, оны оңтайландыру қиын болады. Тапсырыс күні ұлғайған сайын бастапқы кілттің мәні өссе, SalesOrderID арқылы тек сүзгіні қалдыру арқылы шартты жеңілдетуге болады. Бірақ егер бастапқы кілттің мәндері мен нәтиже сұрыпталатын өріс арасында қатаң корреляция болмаса, бұл НЕМЕСЕ ДҚБЖ көпшілігінде болдырмауға болмайды. Мен білетін ерекшелік - кортежді салыстыруға толық қолдау көрсететін PostgreSQL және жоғарыдағы шартты "ҚАЙДА (Тапсырыс күні, SalesOrderID) < ('2014-06-29', 75074)" деп жазуға болады. Осы екі өрісі бар құрама кілтті ескере отырып, мұндай сұрау өте оңай болуы керек.
Екінші балама тәсілді, мысалы, мына жерден табуға болады немесе — сұрау деректерге қосымша деректердің келесі бөлігін алуға болатын арнайы идентификаторды қайтарғанда. Бұл идентификатордың шексіз қызмет ету мерзімі болса (Comsos DB-дегідей), онда бұл беттер арасында дәйекті өту арқылы пейджингті жүзеге асырудың тамаша тәсілі (жоғарыда айтылған №2 опция). Оның мүмкін болатын кемшіліктері: оған барлық ДҚБЖ қолдау көрсетілмейді; нәтижесінде алынған келесі бөлік идентификаторының шектеулі қызмет ету мерзімі болуы мүмкін, ол әдетте пайдаланушының әрекеттесуін жүзеге асыру үшін жарамсыз (мысалы, ElasticSearch айналдыру API).
Кешенді сүзгілеу
Тапсырманы одан әрі күрделендіріп көрейік. Интернет-дүкендерден барлығына жақсы таныс қырлы іздеуді енгізу талабы бар делік. Тапсырыстар кестесіне негізделген жоғарыда келтірілген мысалдар бұл жағдайда онша көрнекі емес, сондықтан 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 және т.б. сияқты нәтижелерді табу және қырларын санау үшін іздеу жүйелерін пайдаланыңыз. Олардың барлығы «жақтарды» құруға арналған және инверттелген индекстің арқасында мұны өте тиімді жасайды. Іздеу жүйелері қалай жұмыс істейді, неге мұндай жағдайларда олар жалпы мақсаттағы дерекқорларға қарағанда тиімдірек, қандай тәжірибелер мен тұзақтар бар - бұл бөлек мақаланың тақырыбы. Бұл жерде іздеу жүйесі негізгі деректерді сақтау орнын алмастыра алмайтындығына назар аударғым келеді, ол қосымша ретінде пайдаланылады: іздеуге қатысты негізгі дерекқордағы кез келген өзгерістер іздеу индексіне синхрондалады; Іздеу жүйесі әдетте іздеу жүйесімен ғана әрекеттеседі және негізгі мәліметтер қорына кірмейді. Мұндағы ең маңызды сәттердің бірі - бұл синхрондауды сенімді түрде ұйымдастыру. Мұның бәрі «реакция уақыты» талаптарына байланысты. Негізгі дерекқордағы өзгерістер мен оның іздеудегі «көріністері» арасындағы уақыт өте маңызды болмаса, сіз соңғы өзгертілген жазбаларды бірнеше минут сайын іздейтін және оларды индекстейтін қызметті жасай аласыз. Ең қысқа жауап беру уақытын қаласаңыз, сіз осындай нәрсені жүзеге асыра аласыз іздеу қызметіне жаңартуларды жіберу үшін.
қорытындылар
- Сервер жағындағы пейджингті енгізу маңызды қиындық болып табылады және тек жылдам өсетін немесе жай үлкен деректер жиындары үшін мағынасы бар. «Үлкен» немесе «жылдам өсетін» бағалаудың нақты рецепті жоқ, бірақ мен мына тәсілді ұстанатын едім:
- Егер сервер уақытын және желіні жіберуді ескере отырып, деректердің толық жинағын алу өнімділік талаптарына қалыпты сәйкес келсе, сервер жағында пейджингті енгізудің қажеті жоқ.
- Жақын болашақта өнімділік проблемалары күтілмейтін жағдай болуы мүмкін, өйткені деректер аз, бірақ деректерді жинау үнемі өсіп отырады. Болашақта кейбір деректер жинағы бұрынғы тармақты қанағаттандырмауы мүмкін болса, пейджингті дереу бастаған дұрыс.
- Егер бизнес тарапынан нәтижелердің жалпы санын көрсету немесе бет нөмірлерін көрсету бойынша қатаң талап болмаса және жүйеде іздеу жүйесі болмаса, бұл тармақтарды орындамай, №2 нұсқаны қарастырған дұрыс.
- Егер қырлы іздеуге нақты талап қойылса, өнімділікті жоғалтпастан сізде екі нұсқа бар:
- Іздеу критерийлері өзгерген сайын барлық шамаларды қайта есептемеңіз.
- Solr, ElasticSearch, Sphinx және басқалар сияқты іздеу жүйелерін пайдаланыңыз. Бірақ ол негізгі дерекқорды алмастыра алмайтынын және іздеу мәселелерін шешу үшін негізгі жадқа қосымша ретінде пайдаланылуы керек екенін түсіну керек.
- Сондай-ақ, қырлы іздеу жағдайында іздеу нәтижелері бетін іздеуді және санауды екі параллельді сұрауға бөлу мағынасы бар. Мөлшерді санау нәтижелерді алудан ұзағырақ уақыт алуы мүмкін, ал нәтижелер пайдаланушы үшін маңыздырақ.
- Іздеу үшін SQL дерекқорын пайдаланып жатсаңыз, осы бөлікке қатысты кез келген код өзгерісі деректердің сәйкес көлемі бойынша өнімділікке жақсы тексерілуі керек (тірі дерекқордағы көлемнен асып кетеді). Сондай-ақ дерекқордың барлық даналарында, әсіресе «тірі» нұсқасында сұраудың орындалу уақытының мониторингін қолданған жөн. Әзірлеу кезеңінде сұрау жоспарларымен бәрі жақсы болса да, деректер көлемі өскен сайын, жағдай айтарлықтай өзгеруі мүмкін.
Ақпарат көзі: www.habr.com