Ավելի օպտիմալ SQL

Հիմա, երբ սովորել ես տվյալներն ընտրելու բազում եղանակներ և փորձում ես տարբեր աղյուսակների վրա կատարել SELECT-ներ, ճիշտ ժամանակն է խոսել SQL հարցումների արդյունավետության մասին․ որքա՞ն ժամանակում են դրանք աշխատում, կամ կարո՞ղ են արդյոք ավելի արագ աշխատել։

SQL-ը հայտարարվող լեզու է․ ամեն հարցումը հայտարարում է, թե ինչ ենք ուզում, որ SQL համակարգը կատարի, բայց չի հայտարարում, թե ինչպես։ Եվ հետևաբար գործընթացի ինչպես-ը՝ «ծրագիրը», այն է, ինչ ազդում է հարցումների արդյունավետության վրա, և այդպիսով այն նույնպես շատ կարևոր է։

Ինչու է SQL-ի հարցումներին պետք ծրագիր

Պատկերացնենք, թե ունենք այս պարզ հարցումը՝

SELECT * FROM books WHERE author = "J K Rowling";

Այս հարցման համար կա 2 տարբեր եղանակ, որոնցով SQL-ը կարող է գտնել արդյունքները․

Զննել ամբողջ աղյուսակը: Աղյուսակում անցնել բոլոր տողերի վրայով և վերադարձնել համապատասխանող տողերը։
Ստեղծել ցուցիչ: Պատճենել աղյուսակը և պատճենված աղյուսակը դասավորել ըստ հեղինակի և դրա վրա կատարել երկուական որոնում, որպեսզի գտնենք այն տողը, որտեղ հեղինակը «J K Rowling»-ն է, գտնել համապատասխանող ID-ները և հետո իրական աղյուսակի վրա կատարել երկուական որոնում, որը կվերադարձնի այն տողերը, որոնք համապատասխանում են ID-ին։

Ո՞րն է ավելի արագ։ Կախված է տվյալներից, և թե քանի անգամ հարցումը կաշխատի։ Եթե աղյուսակն ունի 10 տող, ապա ամբողջ աղյուսակը զննելիս համակարգը կստուգի ընդամենը 10 տող և կվերադարձնի պետքական տողերը։

Եթե աղյուսակն ունի 10 միլիոն տող, ապա ամբողջ աղյուսակը զննելիս կանցնենք 10 միլիոն տողի վրայով։ Ավելի արագ կլինի կատարել երկուական որոնում, որով կպահանջվի առավելագույնը 23 ստուգում, որպեսզի գտնենք մեր ցանկալի արժեքը 10 միլիոն տողից։ Սակայն տեսակավորված աղյուսակ ստեղծելը շատ ժամանակ կտանի (~230 միլիոն գործողություն՝ կախված համակարգչի հզորությունից)։ Եթե այդ հարցումը կատարելու ենք մի քանի անգամ (ավելի, քան 23 անգամ), կամ եթե արդեն ունենք տեսակավորված աղյուսակը, երկրորդ տարբերակն օգտագործելն ավելի լավ կլինի։

Ինչպե՞ս է SQL-ի համակարգը որոշում, թե որ ծրագիրն է պետք ընտրել։ Սա շատ կարևոր քայլ է, որին դեռ չենք անդրադարձել, որովհետև մինչ այս կենտրոնացել էինք հարցումների գրելաձևի վրա, ոչ թե դրանց աշխատելու եղանակների։ Երբ ավելի խորանաս մեծ տվյալների բազաների համար SQL-ն օգտագործելու մեջ, այս քայլերը կդառնան անչափ կարևոր։

SQL-ի հարցումների կյանքի տևողությունը

Այսպես կարող ենք պատկերացնել, թե ինչպես է SQL համակարգն ամեն հարցման համար գնում այս քայլերի վրայով․

Հարցումների վերլուծիչն այնպես է անում, որ հարցումը ճիշտ գրված լինի գրելաձևի (ստորակետներ և այլն) և ընդհանուր տեսքի առումով (աղյուսակների լինել-չլինելը և այլն), և վերադարձնում է վրիպումներ, եթե ինչ-որ բան սխալ է։ Ճիշտ լինելու դեպքում այն վերածվում է հանրահաշվական գործողության և անցնում հաջորդ քայլին։ 2. Հարցումներ կազմակերպողն ու իրացնողը կատարում է մտածելու աշխատանքը։ Սկզբում այն արագ օպտիմալացումներ է անում (բարելավումներ, որոնց արդյունքում գործը կհեշտանա, օրինակ՝ 5*10-ը դարձնել 50)։ Այնուհետև այն մտածում է տարբեր «հարցումների նախագծեր», որոնք, հնարավոր է, կունենան տարբեր օպտիմալացումներ, հետո մոտարկում է յուրաքանչյուր նախագծի ծախսը (CPU-ն և ժամանակը)՝ կախված տարբեր աղյուսակների տողերի քանակից, հետո ընտրում է ամենաօպտիմալ նախագիծն ու փոխանցում հաջորդ քայլին։
Հարցում կատարողը վերցնում է նախագիծն ու դրա հրամաններով սարքում տվյալների բազա՝ մեզ վերադարձնելով դրա արդյունքները։

Որտեղ են պետք գալիս մարդիկ

Հարցումների ծրագրումը և բարելավումը բոլոր տեսակի հարցումների համար է, և հնարավոր է՝ ամբողջ կյանքումդ զբաղվես SQL-ի հարցումներ կատարելով՝ առանց նույնիսկ գիտակցելու։ Ամեն դեպքում, երբ սկսում ես աշխատել ավելի մեծ տվյալների փնջերի հետ, քեզ սկսում է ավելի շատ հուզել հարցումների արագությունը, և քեզ մոտ հարց կառաջանա, թե ինչպես կարելի է արագացնել քո հարցումների աշխատանքը։

Շատ անգամներ, հիմնականում բարդ հարցումների համար, կան հարցումը բարելավելու եղանակներ․ այդ գործընթացը կոչվում է «հարցումների կարգավորում»։

Առաջին քայլն է՝ հասկանալ, թե որ հարցումներն է պետք կարգավորել, որոնք կարող ես հասկանալ՝ տեսնելով, թե որ կանչերն են ամենից շատ ժամանակ պահանջում կամ ամենից շատ ռեսուրսներ օգտագործում։ Դրա համար կարող ես օգտագործել SQL-ի արդյունաչափիչ։ Երբեմն կարող ես հասկանալ, որ հարցումը վատ է աշխատում, եթե այն այնքան երկար է աշխատում, որ անջատում է ամբողջ տվյալների բազան։ Լավ կլինի, եթե այդպիսի վտանգներն ավելի շուտ նկատես։

Մյուս քայլն է հասկանալ, թե ինչպես է տվյալ SQL-ի շարժիչն աշխատեցնում հարցումը, և ինչպես են բոլոր SQL համակարգերն ինչ-որ եղանակներով դա հարցնում շարժիչից։ SQLite-ում յուրաքանչյուր SQL-ի դիմաց կարող ես դնել EXPLAIN QUERY PLAN, որպեսզի տեսնես, թե ինչ է այն անում վարագույրի հետևում։ Եթե դա օգտագործելու ես, պատրաստ եղիր խորանալ EXPLAIN QUERY PLAN-ի մեջ, որովհետև «բացատրությունը» բավական մանրամասն է։ Եթե այլ SQL-ի շարժիչ ես օգտագործում, կարող ես որոնել այսպիսի մի բան՝ «how do I get an execution plan in X»։

Հիմա գալիս է դժվար հատվածը․ հարցումների աշխատանքի օպօտիմալացումը։ Սա նաև այն հատվածն է, որը հաճախ կախված է, թե որ SQL շարժիչն ես օգտագործում, և թե ինչպիսի տվյալների հետ ես աշխատում։

Օրինակ՝ հիշո՞ւմ ես վերևում մեր քննարկած հարցումը։ Եթե սկզբում իմանայինք, որ հարյուրավոր հարցումներ ենք անելու, որոնք WHERE-ով են գտնում տվյալները, կարող ենք ուղղակի կողքից ստեղծել ցուցիչ՝ օգտագործելով CREATE INDEX։ Այս կերպ SQL-ի շարժիչն արդյունավետ կերպով կկարողանա օգտագործել այդ ցուցիչը, որ գտնի համապատասխան տողերը։ Կարող ես կարդալ SQLite-ի հարցումների ծրագրման ուղեցույցը, որպեսզի հասկանաս, թե երբ է հարկավոր ցուցիչներ ավելացնել։

Ցուցիչներ ստեղծելը հաճախ ավելի արդյունավետ է դառնում կրկնվող հարցումներ կատարելու ժամանակ։ Բայց կան բազում այլ մոտեցումներ։ SQLite-ի համար կարող ես ավելի շատ բան իմանալ հարցումների ծրագրման ամփոփման մեջ։

Մենք այստեղ չենք կարող անդրադառնալ հարցումների բարելավման և կարգավորման հետ կապված բոլոր մանրամասներին։ Խորհուրդ ենք տալիս խորանալ դրանց մեջ այն ժամանակ, երբ կարիքն ունենաս։

(Այստեղ կան տարբեր SQL հարցումների ծրագրիչների մասին անգլերենով նյութեր, որոնք հետաքրքիր կլինեն․ SQL Server Query Optimizer, Oracle SQL Tuning, MSSQL Execution Plan Basics)

Ուզո՞ւմ ես միանալ խոսակցությանը։

Մուտք գործել

Դասակարգել ըստ

Առայժմ հրապարակումներ չկան։

Անգլերեն հասկանո՞ւմ ես: Սեղմիր այստեղ և ավելի շատ քննարկումներ կգտնես «Քան» ակադեմիայի անգլերեն կայքում: