Pirmo N ierakstu atlase

Atlasīt pirmos N (2, 3, 5, 10, 20, 100 utt.) ierakstus ir diezgan izplatīta prasība. Atlasīt N lielākos, N mazākos, N jaunākos utt. Angliski to parasti sauc kā Top N analysis vai Top N Query. Savukārt (parasti webiskās aplikācijās) mēdz būt vēl viena diezgan tipiska prasība – lapošana (pagination) – ierakstu atlase pa porcijām. Šīs ir tās lietas, kur datu bāzu vadības sistēmu atšķirības spīd visā savā spožumā. Tikai relatīvi pēdējā laikā izmantojot analītiskās funkcijas vismaz dažās DBVS var mēģināt izlīdzēties ar vienu un to pašu SQL teikumu pirmo N ierakstu atlasē un lapošanā. Kā jau vienmēr esmu mēģinājis uzsvērt, tas gan nebūtu jāuzskata par milzīgu trūkumu, jo arī, iekāpjot cita ražotāja automašīnā, Jūs negaidat, ka ātruma pārslēgs slēgsies precīzi tāpat ka iepriekšējā. Truli laužot to pierastajā pozīcijā, Jūs varat iegūt tikai salauztu mašīnu un ar datubāzēm, protams, ir līdzīgi. Tiktāl ievads, bet tagad pēc kārtas par Oracle, MySQL, SQL Server un analītisko funkciju universālo risinājumu.

Oracle apmācības un jauns seminārs

Ja vēl neesat pamanījis, tad Oracle sertificētās apmācības ir pārgājušas no Affecto Latvia (lai vieglas tam smiltis ) uz BDA. Pozitīvā ziņa ir tāda, ka gan kursu organizatore, gan pasniedzēji (tai skaitā arī man tas gods ) ir palikuši tie paši. Tā kā Jums ir visas iespējas apskatīt potenciālo kursu grafiku un izvēlēties sev tīkamāko. OK, OK, es jau tāpat virtuāli jūtu skeptisko noskaņojumu par šodienas ekonomiskās situācijas nesavienojamību ar apmācībām un kursiem, bet pārāk ekonomējot uz tām arī nav tālredzīga rīcība.

Oracle apmācības ir un būs ilgtermiņā, bet ļoti drīz būs vienreizējs pasākums Joze Senegacnik seminārs “Optimizing for Performance” tepat Rīgā, arī Baltijas datoru akadēmijas telpās. Pasniedzēju neesmu redzējis dzīvē, bet esmu redzējis viņa prezentācijas tekstuālā formā un arī Jozes Senegacnik mājaslapa ir pietiekami daiļrunīga. Personas, kas vēlas lietot cilvēka labāko draugu googli, lai sīkāk iepazītu autoru, var pamēģināt šādu maģisku kombināciju un paskatīties, kas no tā sanāk.

Oracle + Sun (arī MySQL)

Viss plūst viss mainās, MySQL te bija pats savs MySQL, te Sun MySQL, tagad jau Oracle’s MySQL
Oracle savai 11 dažādu DBVS kolekcijai varēs pievienot vēl vienu. OK nezinu kā tur ir ar visādām licencēm/autortiesībām, bet katrā ziņā nākotne izskatās interesanti.

Tā kā Oracle dzimtā DBVS jau ir kļuvusi pārāk sakārtota un tuvu pilnībai un kā mēs zinām, tad viss, kas kļūst pilnīgs, bankrotē un tiek aizvietots ar kaut ko haotiskāku un mazāk sakārtotu, tad var izrādīties, ka vismaz lielākais haoss būs jāmeklē tajā pašā kompānijā

Darījums, protams, vēl procesā, cena 7,4 miljardi, sīkākas detaļas skat. Bloomberg.com lapā un arī pašas Oracle interpretācijā. Sapnis par Oracle spēju nodrošināt visu sākot ar dzelžiem, operētājsistēmu, līdz DBVS un gatavām aplikācijām kļūst aizvien tuvāks…

SQL teikuma izpildes plāna iegūšana – Oracle, MySQL, SQL Server

SQL teikumu izpildes plāns (query execution plan) – kurš gan nopietni interesējoties par datubāzu izstrādi tādu terminu nav dzirdējis? Vaicājums lēni strādā – paskaties izpildes plānu! Tiesa gan vairumā gadījumu tiek pašas par sevi pieņemtas divas (varbūt pat trīs) lietas:

• persona zin, kā izpildes plānu dabūt;
• persona zin, ko iegūtais izpildes plāns nozīmē;
• persona zin, kā panākt, lai izpildes plāns būtu optimālāks nekā iegūtais vai arī saprot, ka nekas labāks nevar sanākt (neobligātais solis).

Šai rakstā apspriedīšu pirmo soli jau parasti izvēlētajām DBVS – Oracle, MySQL, SQL Server. Kā jau Jūs noteikti zinat visas DBVS ir atšķirīgas, attiecīgi atšķirīgas ir arī metodes, kā izpildes plānu iegūt. Tātad pēc kārtas.

Oracle

Oraclē ir vairākas metodes, kā iegūt SQL teikuma izpildes plānu, ar dažādu sarežģītību un ticamības pakāpi. Ja izmantojat rīku SQL*Plus, tad visvienkāršāk ir izmantot šī rīka komandu autotrace. Es šeit gari nekāvēšos pie šī rīka un komandas apraksta, jo tie abi ir augšminētajās saitēs, šeit tikai īss piemērs. Visiem turpmākajiem piemēriem tiks izmantotas tabulas no raksta par Dekarta reizinājumu.

Paradigmas maiņa – SQL ātrdarbības atslēga

Strādājot ar lielākiem datu apjomiem, datubāzēs parasti rodas problēmas ar ātrdarbību. Viens no izplatītiem iemesliem (par ko es rakstīju arī savās 7 lietās, ko nevajag darīt) ir datu uztveršana un darbības ar tiem pa ierakstiem un nevis kopām. Protams, ne es pirmais, ne pēdējais, kas izrunā šo maģisko vārdu savienojumu “apstrādāt datus datubāzē KĀ KOPAS“, tikai, skatoties uz komentāru pie šī paša raksta, acīmredzot ir problēmas saprast, ko tas īsti nozīmē. Tad nu mēģināšu paskaidrot sīkāk, ko nozīmē datus uztvert kā kopas un ar ko tas atšķiras no tradicionālās programmēšanas pieejas. Tā lūk ir paradigmas maiņa no viena veida datu uztveres uz citu.

Tradicionālā programmēšanas pieeja

Tradicionālajā programmēšanā darbība vienlaicīgi notiek ar vienu ierakstu. Tas var būt vienkāršs ar vienu vienkāršu lauku, piemēram, skaitlis 17, tas var būt sarežģītāks, piemēram, adreses objekts, kurš sastāv no 10 sīkākiem laukiem, bet objekts parasti ir viens. Un tas viens arī tiek vienlaicīgi apstrādāts. Dabiski, ka programmētājam, sākot darboties ar datubāzēm, šāda pieeja tiek pārnesta arī tur. Programmētājs, rakstot pieprasījumus datubāzei (gan datu atlases, gan mainīšanas), vienlaicīgi “redz” tikai vienu ierakstu. Tas var būt sarežģītāks, mazāk sarežģīts, bet tikai vienu. Šāda pieeja nerada nekādas vai rada relatīvi mazas problēmas tradicionālu ievades/rediģēšanas formu gadījumā, jo tajās lietotāji arī parasti strādā ar vienu vai dažiem ierakstiem un parasta programmētāja pieeja “redzot” tikai vienu ierakstu neko daudz neskādē, vai pat bieži nekāda cita pieeja vispār nav izmantojama. Taču problēmas rodas lielāku datu kopu apstrādē. Un tad ir jāveic izmaiņas domāšanā un jāpāriet uz..

Datu kopu pieeja

Šī pieeja ir svarīga un vislielākos ieguvumus dod, ja tiek apstrādāts relatīvi liels ierakstu skaits. Daži piemēri:

• Atskaišu izveide;
• Vienreizēja datu migrācija no vecās sistēmas uz jauno;
• Regulāra datu pārnešana/sinhronizācija no vienas sistēmas uz otru;
• Regulāra specifiska lielu apjoma datu apstrādes (dienas rezultātu apstrāde, noteiktā laika periodā ievadīto datu kvalitātes pārbaude) utt.

Izmantojot tradicionālo viena ieraksta pieeju, rezultāta ieguve ir aptuveni šāda:

Ciklā pa nepieciešamajiem ierakstiem atskaitei vai apstrādei
  Veicam katram ierakstam nepieciešamās darbības
    (kolonu aprēķini, kvalitātes pārbaudes utml)
  Papildinam gala summu vai saglabājam rezultātu datubāzē

Ko tas nozīmē no ātrdarbības viedokļa? Rezultāta ieguve ir tieši proporcionāla apstrādājamo datu apjomam. Ja katra ieraksta apstrāde mums prasa nieka 0,1 sekundi, tad pie ierakstu skaita 1 miljons (kas nav nekas īpašs) rezultāta ieguve prasīs 1 000 000 * 0,1 sekundes ≈ 1667 minūtes ≈ 28 stundas. Tātad, ja reizi diennaktī Jūs saņemat šādu datu apjomu, tad diemžēl ir liela problēma, jo datu apstrāde aizņem vairāk nekā diennakti. Pat, ja šāds datu apjoms ir reizi nedēļā, patērētais laiks nav īpaši iepriecinošs. Un ko darīt, ja datu apjoms var tikai pieaugt? Tādā gadījumā ir jāveic principiālas izmaiņas un jāpāriet no domas ierakstu pa ierakstiem uz domu par visiem ierakstiem reizē, un tātad:

• Kā visiem ierakstiem reizē iegūt atskaites kolonu vai vēl labāk vairākas, vai vislabāk visas kolonas?
• Kā veikt noteiktu kvalitātes pārbaudi nevis vienam ierakstam, bet kā to paveikt visiem ierakstiem reizē? Vai sliktākajā gadījumā ierakstu daļai?
• Kā ierakstīt tabulā nevis viena ieraksta datus, bet kā ierakstīt visus uzreiz.

Tātad domāt kopās nozīmē nevis

• paņemt kārtējo ierakstu un izpildīt tam 17 pārbaudes un tad to izmētāt pa 10 tabulām,

bet

• visiem ierakstiem reizē izpildīt pārbaudi 1, 2, … , 17 un tad visus ierakstus reizē ielikt tabulā 1, 2, …, 10.

Tātad domāt kopās nozīmē nevis

• paņemt kārtējo ierakstu un izrēķināt tam visas atskaites kolonas, pieskaitīt tās starprezultātam un beigās izdot gala rezultātu,

bet

• izrēķināt kolonu A visiem ierakstiem, izrēķināt kolonu B visiem ierakstiem, optimālā gadījumā šos rēķinus apvienojot vienā vaicājumā.

Protams, nevajadzētu šo pasākumu kaut kādā veidā nomaskēt, piemēram, ar lietotāja definētu funkciju, kas tiek izsaukta katram pārbaudāmajam ierakstam un kurā, savukārt, atkal iekšā ir ntie vaicājumi. Šādā veidā ieguvums vai nu nebūs nekāds, vai relatīvi niecīgs.

Iespējams arī, ka Jūs nevarat VISUS ierakstus apstrādāt vienlaicīgi, t.i., atkarībā no ieraksta veida un datiem veicamās darbības ir ļoti atšķirīgas. Tādā gadījumā Jūs noteikti varat ierakstus sadalīt loģiskās daļās, kur visiem vienas daļas ierakstiem veicamā darbība ir vienāda.

Kāds ir ieguvums?

Galvenais ieguvums ir tāds, ka izveidotais process vairs nav tieši proporcionāli atkarīgs no ierakstu skaita. Kāpēc? Tam ir vairāki iemesli:

• Protams, ka palielinoties ierakstu skaitam, izveidotajiem SQL teikumiem būs jāapstrādā lielāks datu apjoms, taču parasti šis process nav tieši proporcionāls datu apjomam, tas ir – ir iespēja datus apstrādāt ātrāk nekā tieši proporcionāli.
• Nav nepieciešams atkal un atkal lasīt vienus un tos pašus datus (klasifikatorus vai citus references datus), kas neglābjami būs, ja notiks apstrāde ierakstu pa ierakstam.
• Nav nepieciešams atkal un atkal izpildīt vienus un tos pašus mazos SQL teikumiņus, kas katrs prasa maz laika, bet kopsummā tomēr laiks salasās.
• Nav nepieciešams mētāties no procedurālās programmēšanas vides uz SQL vidi. Oraclē tas ir PL/SQL un SQL, citur tas var būt kaut kas cits, bet ideja nemainās un laiks tiek patērēts.

Laika izteiksmē ieguvums, protams, ir atkarīgs no datu daudzuma, izejas stāvokļa un gala stāvokļa, cik viens un otrs ir bijis optimāls. Bet ir redzēti gadījumi, gan kad ieguvums ir bezgalīgs, jo nevienam nebija pacietības sagaidīt rezultātu no ierakstu pa ierakstam pieejas , un arī tādas reizes, kad ieguvums ir bijis vismaz par kārtu.

Tālākā lasāmviela

• 7 lietas, ko nevajag darīt;
• Thinking Set-Based …. or not? - raksts par to, ka problēmas ir jāmēģina saskaldīt un atrisināt soli pa solim.