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.

Kurā vēlēšanu iecirknī balsot?

Tuvojoties nākošajām pašvaldību un eiroparlamenta vēlēšanām dzīve Latvijas vēlētājiem – interneta lietotājiem – ir kļuvusi mazliet vieglāka. Ja esat apzinīgs Latvijas pilsonis (vai ES valsts pilsonis) un neesat saņēmis vēstuli ar informāciju, kurā vēlēšanu iecirknī esat reģistrēts, vai arī veiksmīgi esat to pakāsis, un Jūs nomoka mūžīgais jautājums “KUR BALSOT?“, tad viss vēl nav zaudēts, jo savu vēlēšanu iecirkni var uzzināt ļoti vienkārši pat nemaksājot ne santīma zvanam uz CVK informatīvo tālruni. Vienkārši ir jauns e-pakalpojums “Vēlēšanu iecirkņa noskaidrošana“, kurā katram atliek ievadīt personas kodu, uzvārdu un vārdu un Jums taps skaidrs, kādā iecirknī esat vai neesat reģistrēts. Tātad informācija no valsts nozīmes datubāzes – Vēlētāju reģistra – ir kļuvusi parastiem mirstīgajiem mazliet pieejamāka.

Atgādinu arī, ka e-pakalpojumi (vai vismaz lietas, kas par tādām ir nosauktas) ir pieejami arī:

• Portālā latvija.lv - šī nu, protams, ir visslavenākā vietne no visiem e-pakalpojumu sniedzējiem Patīkami, ka pašlaik autentificēties var arī ar internetbankas kontu – tātad nav nepieciešams tikai Latvijas pasta e-paraksts.
• Rīgas pašvaldības portālā - piemēram, kura vieta kurā bērnudārzā ir Jūsu sīkajam, kam autorizācija nav nepieciešama un visādas citādas lietas ar nepieciešamu autentifikāciju. Arī šeit var izmantot internetbankas kontus.
• CSDD – uzzini savus soda punktus, mašīnas, kas Jums pieder, dabūt vienas dienas atļauju utml. Pietiek ar to, ka Jums ir e-pasts un vadītāja apliecība.

Protams, ir vēl milzums vietnes, kurās šis tas ir elektroniski pieejams, taču tajās dotā informācija ir saistoša mazākam cilvēku skaitam.

Oracle SQL teikuma izpildes plāns – prezentācija

Latvijas Oracle lietotāju grupas (LVOUG) pirmā konference/seminārs ir veiksmīgi beidzies – paldies tā organizētājiem! Nezinu īsti, cik oficiāli bija cilvēku pieteikušies, bet es teiktu, ka kāds simtiņš kopā sanāca. Pasākums bija atšķirīgs no oficiālājām Oracle dienām ar to, ka nebija nevienas prezentācijas (vismaz no tām, ko apmeklēju es), kurā nodarbotos ar mārketingu Visas prezentācijas bija tehniski orientētas un bez oficiālajiem reklāmas rullīšiem.

Arī es stāstīju prezentāciju par SQL teikuma izpildes plānu - kā to iegūt, kā attēlot, kā saprast un kā uzlabot. Centos pastāstīt arī par dažām visbiežāk izpildāmajām operācijām un jo sevišķi sīkāk par fiziskajiem savienojumu izpildes veidiem (nested loops, hash join, sort merge join).

Tiem, kam ir dziļāka interese par SQL teikuma izpildes plānu un kam nepaveicās nokļūt uz neseno Tanela Podera semināru, es gribētu speciāli uzsvērt šo viņa emuāra rakstu, kurā ir saite uz failu “Oracle SQL Plan Execution: How It Really Works”. Tā prezentācija ir ļoti interesanta pat tad, ja klātienē nedzirdējāt sīkāku stāstu.

Un visbeidzot šeit ir arī saite uz manis lasīto prezentāciju par to kā saprast SQL teikuma izpildes plānu.