SQL Server. ինդեքսների օգտագործումն արտադրողականության կարգավորման ընթացքում
Ինդեքսների արդյունավետ կառուցումը տվյալների բազաների հետ աշխատող ծրագրային ապահովման աշխատանքի արտադրողականության բարձրացման ամենալավ տարբերակներից մեկն է: Առանց ինդեքսների օգտագործման, SQL սերվերը նմանվում է ընթերցողի, որը դիտարկում է գրքի բոլոր էջերը` մեկ բառ գտնելու նպատակով: Եթե գրքում կա առարկայական ցուցանիշ /ինդեքս/, ընթերցողը կարող է գտնել անհրաժեշտ տեղեկատվությունը շատ ավելի հեշտ: SQL սերվերը, ինդեքսի բացակայության պարագայում, աղյուսակից տվյալներ ստանալու համար կիրականացնի ամբողջ աղյուսակի սկանավորում ու ամբողջ աղյուսակի յուրաքանչյուր տող կենթարկվի ստուգման` հարցման ցուցանիշներին բավարարելու նպատակով: Այդպիսի ամբողջական սկանավորումը կարող է աղետալի հետևանքներ ունենալ ամբողջ համակարգի աշխատանքի համար, հատկապես այն դեպքում, երբ տվյալները աղյուսակում շատ են: Տվյալների բազայի հետ աշխատելու դեպքում կարևորագույն խնդիրներից մեկը առավել արդյունավետ /օպտիմալ/ ինդեքսի կառուցումն է, որը հնարավորություն է տալիս բարձրացնել համակարգի աշխատանքի արդյունավետությունը: Հիմնական տվյալների բազաների մեծամասնությունը ընձեռում է գործիքներ հարցման կատարման պլանի դիտարկման համար և օգնում է կարգավորել ու օպտիմալացնել ինդեքսները: Այս հոդվածում փորձ է արվելու դիտարկել մի քանի պրակտիկ կանոններ, որոնք կիրառվում են տվյալների բազայի ինդեքսների ստեղծման և փոփոխման դեպքում: Սկզբում դիտարկենք այն դեպքերը, երբ ինդեքսավորումը կարող է արդյունավետ դարձնել աշխատանքը, իսկ երբ կարող է վնասել:
Օգտակար ինդեքսներ
Այսպես, աղյուսակների ինդեքսավորումն արդյունավետ կլինի Where պայմանի կիրառմամբ աղյուսակում որոշակի գրառում փնտրելու դեպքում: Այդպիսի հարցումներ են, օրինակ, որոշակի միջակայքում գտնվող արժեքների որոնման հարցումները, որոշակի արժեքի ճշգրիտ համադրման հարցումները, երկու աղյուսակների միավորման կատարման հարցումները: Օրինակ, ներքոնշյալ Northwind տվյալների բազայի նկատմամբ հարցումները, առավել արդյունավետ կիրականացվեն, եթե ինդեքսը կառուցվի UnitPrice դաշտով:
Delete from Products Where UnitPrice=1 Select * from Products Where UnitPrice between 14 AND 16
Քանի որ ինդեքսի տարրերը պահպանվում են կարգավորված, ապա ինդեքսացիան նույնպես կլինի արդյունավետ, եթե հարցման իրականացման ընթացքում օգտագործվի Order By պայմանը: Առանց ինդեքսի, հարցումները բեռնվում և կարգավորվում են հարցման կատարման ընթացքոըմ: UnitPrice ինդեքսը թույլ կտա հաջորդ հարցման մշակման ժամանակ ուղղակի սկանավորել ինդեքսը և առանձնացնել պահանջվող տողերը: Եթե անհրաժեշտ լինի տողերը կանոնակարգել նվազեցման ուղղությամբ, ապա բավարար կլինի ուղղակի սկանավորել ինդեքսը հակառակ ուղղությամբ:
Select * From Products order by UnitPrice ASC
Գրառման խմբավորումը Group By պայմանի օգտագործմամբ նույնպես պահանջում էկարգավորում: Այսպիսով, UnitPrice-ով ինդեքսի կառուսումը կլինի արդյունավետ նաև հաջորդ հարցման ժամանակ, որը հաշվարկում է արտադրանքի միավորների քանակը ըստ ամեն որոշակի գնի:
Select count(*), UnitPrice From Products Group By UnitPrice
Ինդեքսները կարևորվում են նաև դաշտի ունիկալ արժեքների ապահովման համար, քանի որ ՏԲԿՀ-ը կարող է հեշտությամբ ինդեքսով դիտարկել կա այդպիսի արժեք, թե` ոչ: Այդ իսկ պատճառով առաջնային բանալիները միշտ ինդեքսավորված են:
Ինդեքսավորման թերությունները
Գրառման փոփոխությունների ժամանակ ինդեքսները վատթարացնում են համակարգի աշխատանքի արդյունավետությունը: Յուրաքանչյուր անգամ աղյուսակի տվյալների փոփոխման համար հարցման կատարման ժամանակ, ինդեքսը նույնպես պետք է փոփոխվի: Ւնդեքսների օպտիմալ քանակության ընտրության համար անհրաժեշտ է տվյալների բազայի թեստավորում և նրա աշխատանքի արդյունավետության դիտարկում: Ստատիկ համակարգերը, որտեղ տվյալների բազաները օգտագործվում են հիմնականում տվյալներստանալու համար, օրինակ, հաշվետվությունների կառուցման համար, թույլ են տալիս ունենալ ավելի շատ ինդեքսների քանակ միայն կարդացման հարցումներին աջակցելու համար: Տվյալների փոփոխման մեծ քանակությամբ տրանզակցիաներով տվյալների բազաները կարիք կունենան ոչ շատ քանակությամբ ինդեքսների ապահովման մեջ` ավելի բաևձև արտադրողականության ապահովման համար: Ինդեքսները գրավում են լրացուցիչ տեղ կոշտ սկավառակի վրա և օպերատիվ հիշողությունում: Ճշգրիտ չափը կախված է լինելու աղյուսակում առկա գրառումների քանակից, ինչպես նաև ինդեքսի մեջ գտնվող դաշտերի քանակից և չափսերիցԼ Մեծամասամբ դա չի հանդիսանում հիմնական խնդիր, քանի որ այսօր հեշտ է կոշտ սկավառակում առկա ազատ տեղը զոհաբերել հանուն աշխատանքի արդյունավետության բարձրացման:
Օպտիմալ ինդեքսի կառուցում
Կան բավականին շատ առաջարկություններ ծրագրային ապահովման համար առավել արդյունավետ ինդեքս կառուցելու համար: Ինչ վերաբերվում է դաշտերին, որոնցով կառուցվում է ինդեքսը, գոյություն ունեն հետևյալ կանոնները:
Հասարակ ինդեքս
Հասարակ ինդեքսն այն ինդեքսնէ, որն օգտագործում է աղյուսակի մեկ դաշտի արժեքները: Հասարակ ի ինդեքսի օգտագործումը ձեռնտու է երկու պատճառով: Առաջինը, տվյալների բազայի աշխատանքը շատ է ծանրաբեռնում կոշտ սկավառակը: Մեծ ինդեքսային բանալիները պետք է ստիպեն տվայլների բազային կատարել ավելի շատ քանակությամբ մուտքի-ելքի գործողոըթյուններ, ինչը սահմանափակում է աշխատանքի արդյունավետությունը: Երկրորդ, քանի որ ինդեքսի տարրերը հաճախ ընդգրկված են համեմատության մեջ, փոքր ինդեքսներն ավելի հեշտ է համեմատել: Այս երկու պատճառով, միակ ամբողջական թվով դաշտը հանդիսանում է լավագույն ինդեքս, քանի որ այն փոքր է և հեշտ համեմատության համար: Մյուս կողմից, նշանների դաշտերը պահանջում են եմեն նշանի համեմատում և ուշադրություն պարամետրերի մշակմանը:
Սելեկտիվ ինդեքս
Առավել արդյունավետ ինդեքսները քիչ տոկոսով կրկնվող արժեքներ ունեցող ինդեքսներն են: Օրինակ, քաղաքի հեռախոսների տեղեկատուն, որտեղ ամեն երկրերդը կրում է Սմիթ ազգանունը, չի լինի այդքան արդյունավետ, եթե գրառումները կարգավորել ազգանուններով: Ունիկալ արժեքներով բարձր տոկոսային ինդեքսները նույնպես անվանում են սելեկտիվ: Պարզ է, որ ունիկալ ինդեքսը օժտված է առավել սելեկտիվոըթյամբ, քանի որ չի պարունակում կրկնվող արժեքներ: Շատ ՏԲԿՀ-եր կարող են դիտել յուրաքանչյուր ինդեքսի մասին վիճակագրությունը և կարող են ճանաչել որքան չկրկնվող արժեքներ է պարունակվում յուրաքանչյուր ինդեքսում: Տվյալ վիճակագրությունը օգտագործվում է հարցման կատարման պլանի գեներացման ժամանակ:
Ծածկող ինդեքս
Ինդեքսները կազմված են տվյալների դաշտից, որով և կառուցված է ինդեքսը, և համապատասխան տողի վրա ցուցիչից: Այն նման է գրքի առարկայական ցուցիչի /ինդեքսի/ - այն կազմված ք միայն կարևոր բառերից և հղումից այն էջի վրա, որին կարելի է դիմել լրացուցիչ տեղեկատվության համար: Սովորաբար ՏԲԿՀ-ը կհետևի ինդեքսի տողի ցուցիչին, որպեսզի հավաքի հարցման համար անհրաժեշտ տեղեկատվությունը: Բոլոր դեպքերում, եթե ինդեքսը պարունակում է բոլոր դաշտերը, որոնք անհրաժեշտ են հարցման համար, տեղեկատվությունը կարելի է ստանալ առանց տվյալ աղյուսակին դիմելու: Դիտենք վերոնշյալ UnitPrice դաշտով ինդեքսը: ՏԲԿՀ-ը կարող է օգտագործել միայն ինդեքսի տարրերը հետևյալ հարցման համար`
Select count(*), UnitPrice From Products Group By UnitPrice
Հարցման այսպիսի տեսակն անվանում են ծածկող հարցում, քանի որ բոլոր հարցվող դաշտերը կարելի է ստանալ մեկ ինդեքսից: Առավել կարևոր հարցումների համար կարելի է դիտարկել ծածկող ինդեքսի ստեղծման հնարավորությունը աշխատանքի առավել արդյունավետության համար: Այդպիսի ինդեքսները առավել հավանականությամբ կարող են լինեն բաղկացուցիչ /օգտագործված է մեկից ավել դաշտ/, ինչը հակադրվում է առաջին սկզբունքին – ստեղծել հասարակ ինդեքսներ: Պարզ է, որ օպտիմալ քանակությամբ տողերի ընտրությունն ինդեքսում հնարավոր է գնահատել միայն թեստավորման միջոցով և տարբեր իրավիճակներում տվյալների բազայի աշխատանքի արդյունավետության դիտարկման միջոցով:
Կլաստերային ինդեքս
Տվյալների բազաներից շատերն ունեն մեկ հատուկ ինդեքս աղյուսակում, որտեղ տողի բոլոր տվյալները պարունակվում են ինդեքսում: SQL սերվերում նման ինդեքսը կոչվում է կլաստերային /կլաստերիզացված/: Կլաստերային ինդեքսը կարելի է համեմատել հեռախոսային տեղեկագրի հետ, քանի որ ինդեքսի յուրաքանչյուչ տարր պարունակում է ողջ տեղեկատվությունը, որն անհրաժեշտ է, և չի պարունակում հղումներ լրացուցիչ տվյալներ ստանալու համար: Կա ընդհանուր կանոն – յուրաքանչյուր ոչ տրիվիալ աղյուսակ պետք է ունենա կլաստերային ինդեքս: Եթե հնարավոր է ստեղծել աղյուսակում միայն մեկ ինդեքս, ապա ցանկալի է անել այն կլաստերային: SQL սերվերում առաջնային բանալի ստեղծելու ժամանակ ավտոմատ կերպով կստեղծվի կլաստերային ինդեքս /եթե այն արդեն չի պարունակվում/ օգտագործելով առաջնային բանալիով դաշտը, որպես ինդեքսավորման համար բանալի: Կլաստերային ինդեքսն առավել արդյունավետ ինդեքսն է /եթե այն օգտագործվում է, ապա ծածկում է ամբողջ հարցումը/ և շատ ՏԲԿՀ-րում այդպիսի ինդեքսն աջակցում է կոշտ սկավառակի ազատ տարածության արդյունավետ ղեկավարմանը, որը հարցվում է աղյուսակների պահպանման նպատակող, քանի որ հակառակ դեպքում /առանց կլաստերային ինդեքսի/ աղյուսակների տողերը պահպանվում են ոչ կանոնակարգված կառուցվածքում, որը անվանում են կույտ: Կլաստերային ինդեքսի դաշտերի ընտրության ժամանակ պետք է լինել զգույշ: Եթե փոխել կլաստերային ինդեքսի գրառումը և դաշտի արժեքը, ապա տվյալների բազան ստիպված է լինելու փոխել ինդեքսի տարրերը /որպեսզի պահի դրանք կարգավորված տեսքով/: Պետք է հիշել, որ կլաստերային ինդեքսի համար ինդեքսի տարրերը պարունակում են դաշտերի բոլոր արժեքները, այսպիսով, դաշտի արժեքի փոփոխությունը համեմատվում է Delete հրամանի, և նրան հաջորդող Insert հրամանի կատարման հետ, որը բնականաբար կառաջացնի խնդիրներ աշխատանքի արդյունավետության հետ, եթե դա անել հաճախ: Այս պատճառով կլաստերային ինդեքսները հաճախ կազմված են առաջնային բանալիի դաշտերից և արտաքին բանալիից: Իսկ բանալիների արժեքները անգամ եթե փոխվում են, ապա` շատ հազվադեպ:
Եզրակացություն
Ճիշտ ինդեքսների հասկացությունը, որոնք օգտագործվում են տվյալների բազաներում, պահանջում է մանրակրկիտ վերլուծություն և համակարգի թեստավորում: Պրակտիկ մեթոդները, որոնք ներկայացված են այս հոդվածում, հանդիսանում են բավականին հաջող կանոններ ինդեքսների կառուցման համար: Այս մեթոդների կիրառումից հետո անհրաժեշտ կլինի նորից թեստավորել համապատասխան կոնկրետ ծրագրային ապահովումը` ըստ կոնկրետ ապարատային պայմանների, հիշողության և գործողությունների: