Бизге тааныш болгон бардык тиркемелердеги типтүү сценарийлердин бири бул белгилүү бир критерийлерге ылайык маалыматтарды издөө жана аны окууга оңой формада көрсөтүү. Ошондой эле сорттоо, топтоо жана пейджинг үчүн кошумча параметрлер болушу мүмкүн. Тапшырма теориялык жактан анча деле маанилүү эмес, бирок аны чечүүдө көптөгөн иштеп чыгуучулар бир катар каталарды кетиришет, алар кийинчерээк өндүрүмдүүлүктүн начарлашына алып келет. Келгиле, бул көйгөйдү чечүүнүн ар кандай варианттарын карап чыгууга жана эң натыйжалуу ишке ашырууну тандоо боюнча сунуштарды иштеп чыгууга аракет кылалы.
Беттештирүү опциясы №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 талаасы биринчи позицияда эмес, андыктан суроо аны колдоно албайт. Маселе 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ти кемитүү жөнөкөй арифметикалык операция болушу мүмкүн, бирок бул жерде ашыкча.
Эми биз "офсет + сан" аркылуу пейджингди ишке ашыруунун кемчиликтерин сүрөттөшүбүз керек:
- Ар бир кийинки баракты алуу мурункуга караганда кымбатыраак жана жайыраак болот, анткени маалымат базасы дагы эле издөө жана сорттоо критерийлерине ылайык бардык жазууларды “башынан баштап” өтүп, андан кийин керектүү фрагментке токтошу керек.
- Бардык DBMSs бул ыкманы колдой албайт.
Альтернативалар бар, бирок алар да жеткилең эмес. Бул ыкмалардын биринчиси "ачкычтын пейджинги" же "издөө ыкмасы" деп аталат жана төмөнкүчө: бөлүктү алгандан кийин, сиз беттеги акыркы жазуудагы талаа маанилерин эстеп, андан кийин аларды алуу үчүн колдоно аласыз. кийинки бөлүгү. Мисалы, биз төмөнкү суроону иштеттик:
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
Бул параметр туура иштейт, бирок шартта ЖЕ оператору камтылгандыктан, жалпысынан оптималдаштыруу кыйын болот. Эгерде баштапкы ачкычтын мааниси OrderDate көбөйгөн сайын көбөйсө, анда SalesOrderID боюнча чыпка калтыруу менен шартты жөнөкөйлөштүрсө болот. Бирок, эгерде баштапкы ачкычтын маанилери менен натыйжа сорттолгон талаанын ортосунда катуу корреляция жок болсо, анда бул ЖЕ көпчүлүк DBMSтерде качууга болбойт. Мен билген өзгөчөлүк - бул PostgreSQL, ал кортеждик салыштырууларды толугу менен колдойт жана жогорудагы шартты "КАЙДА (OrderDate, 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 маалымат базасын колдонуп жатсаңыз, бул бөлүккө тиешелүү ар кандай коддун өзгөрүшү тиешелүү маалыматтардын көлөмүндө (жандуу маалымат базасындагы көлөмдөн ашкан) иштеши үчүн жакшы текшерилиши керек. Ошондой эле маалымат базасынын бардык инстанцияларында, өзгөчө “тирүү” инстанцияларында сурамдардын аткарылышынын мониторингин колдонуу сунушталат. Өнүгүү стадиясында суроо пландары менен баары жакшы болгон күндө да, маалыматтардын көлөмү өскөн сайын, кырдаал байкаларлык түрдө өзгөрүшү мүмкүн.
Source: www.habr.com
