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.

Indeksu spožums un posts

Kas ir indekss?

Indeksi popularitātes ziņā droši vien ir nākošie objekti datubāzēm pēc tabulām. Tos bieži izmanto vietā un iespējams gandrīz tikpat bieži patiesībā lieto nevajadzīgi. Bet tātad vispirms būtu jāsaprot, kas tad tie ir un kāda aptuveni ir to uzbūve.

Parasti runājot par indeksiem vispirms tos saprot kā kokveidīgu struktūru, kuras pirmais un galvenais uzdevums ir ātri atrast datus tabulā, kuras dati, ja vien tā nav ļoti speciāla veida tabula, ir nesakārtoti. Nākošajā attēlā ir parādīta konceptuāla indeksa struktūra. Protams, ka reālajās implementācijās katrā DBVS tas ir mazliet atšķirīgi, bet ideja paliek viena un tā pati – koks, pa kuru ātri nonāk līdz nepieciešamajai vērtībai un tad taisnā ceļā izmantojot norādes dodas uz tabulu, no kuras var nolasīt konkrēto ierakstu. Nevajadzētu, protams, arī uztvert datu bloku skaitīšanu kā precīzu algoritmu, kas pie šīm vērtībām tā arī notiek, bet drīzāk kā konceptuālu ideju.

Indekss un tabula

Tātad, ja mēs meklējam vērtību “Kuldīga” (nosacījums WHERE pilsetas_nosaukums = ‘Kuldīga’) tabulā, tad mums ir divas iespējas:

MySQL profiler

Es ik pa laikam iedomājos vai MySQLā arī var lietot līdzīgas iespējas, kā piemēram Oracle autotrace, lai varētu mērīt izpildes laiku, paveiktos soļus un kaut kādu statistiku vaicājumiem, un lai salīdzinātu, kas tad izpildījās ātrāk un kāpēc. Tad nu izrādās, ka jau vismaz kopš 2007. gada pavasara eksistē tāda lieta, kā MySQL profiler, kas lielā mērā to nodrošina. Jau pašā sākumā jābrīdina, ka MySQL ir visai dīvaina DBVS un visai dīvainas izstrādes metodes vismaz no mana skatupunkta, jo pirmkārt MySQL Profiler nav pieejams MySQL Enterprise Server un notiek arī tāda mistiska dīvainība, ka vecākās versijās ir, bet jaunākās nē, piemēram, 5.0.37 ir, bet 6.0.4 nav (uz to arī es uzrāvos un brīnījos kā gan tas nākas), savukārt pēdējā novelkamajā 6.0.9. alpha atkal ir. Tā kā iespējams ne visiem lietotājiem būs tā iespēja šo rīku arī izmantot. Vēl tāds interesants fakts, ka šajā brīdī meklējot Googlē MySQL profiler latviskās lapās (tas ir pirms šī raksta, ko pašlaik lasat, publicēšanas) tiek atrasti 17 rezultāti, no kuriem tieši 1 ir kādā sakarā ar meklēto frāzi.

Kā jālieto?

Profiler sākšana un beigšana ir ļoti vienkārša. Lai sāktu, rakstam:

mysql> set profiling=1;
Query OK, 0 rows affected (0.00 sec)

Lai beigtu, rakstam:

mysql> set profiling=0;
Query OK, 0 rows affected (0.00 sec)

Lai noskaidrotu, kādā stāvoklī esam:

mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
|           0 |
+-------------+
1 row in set (0.00 sec)

Ko ar to var redzēt?

MySQL performance tuning seminārs

Šo sestdien Rīgā bija Software freedom day, kas notika LU Linux centrā un par ko informēju jau iepriekš. Pirms došanās uz pasākumu izjutu nelielu skepsi, jo pierakstīšanās procesā uz MySQL ātrdarbības skaņošanas semināru valdīja mērens bardaks, tas ir, sākumā tas bija kā visiem pieejams, tad pazuda, tad atkal uzradās, kā arī visu laiku mainījās semināra sākuma laiks, piedevām pēdējo izmaiņu piefiksēju tikai tāpēc, ka nejauši vēlreiz iepētīju pasākumu plānu. Bet nu “viss labs, kas labi beidzās”, un pasākums izvērtās gana interesants.

Semināru vadīja Jay Pipes un slaidi bija tāds kā apkopojums no viņa pēdējām abām prezentācijām, kas redzamas viņa mājaslapā Legend of Drunken Query Master: The Apprentice’s Journey un Join-fu: The Art of SQL – ZendCon 2008. Tātad tie, kas seminārā tādu vai citādu iemeslu dēļ nepiedalījās, var vismaz paskatīties galvenās idejas no tām. Lielākais pluss, protams, bija iespēja uzdot jautājumus un saņemt kompetentas atbildes. Ašākais no klausītājiem, kas pareizi atbildēja uz Jay Pipes jautājumu, savā īpašumā ieguva grāmatu High Performance MySQL, Second Edition. Vēl jāpiebilst, ka semināra pasniedzējs arī ir līdzautors grāmatai Pro MySQL.

Dažas pasākuma bildes var redzēt šeit.

Tā kā neesmu nekāds baisais MySQL specs un lietoju to tā sakot brīvajos brīžos, tad iespējams, ka mani iespaidi ir mazliet savādāki nekā tie, kas būtu radušies MySQL ikdienas lietotājiem, bet daži no tiem bija šādi:

• Tika atgādināts par to, ka MySQLā ir daudz un dažādi tabulu tipi un tas, ka Jūs izmantojat tikai vienu no tiem, visdrīzāk nozīmē, ka Jūsu aplikācija nedarbojas optimāli. Ko tur piebilst, tieši tāpat ir arī, piemēram, Oraclē, bet cik vispār zin, ka Oraclē ir vairāki tabulu tipi, nemaz nerunājot par to, ka ir arī tos lietojuši?
• Atgādināts, ka visa pamatā ir shēma un, ja tā ir izveidota neoptimāli, tad tādi būs arī Jūsu vaicājumi, un neviens pasaules optimizators Jums neko daudz nepalīdzēs. Atliek tikai piekrist.
• Diezgan smagi tika spiests uz piemērotu minimālu datu tipu pielietošanu, lai vienā datu blokā pēc iespējas vairāk sapakotu ierakstus.
• Vertikālā particionēšana – ja Jūsu tabula satur daudzas kolonas, no kurām tikai dažas tiek bieži izmantotas, tad sadalīt tabulu divās – vienā ar bieži izmantotajām kolonām, otrā attiecīgi retāk izmantotās, lai nepiesārņotu kešu. Tehnika, kuru nekur citur tā īsti neesmu redzējis iesakam, ja neskaita kādus ekstrēmus gadījumus ar blobu un clobu likšanu atsevišķās tabulās, lai tās neafektētu pamattabulas.
• Atgādinājums par MySQL vaicājumu kešu (query cache), kurš noklusēti ir 0. Kešošanas algoritms gan ar nekādu dziļu inteliģenci neizceļas tāpēc jābūt uzmanīgam ar vaicājumu kešošanu, kas darbojas uz mainīgām tabulām.
• Atgādinājums un piemērs par to, ka rakstot SQL jādomā kopās nevis ierakstos (think in sets not in rows). Atbalstu ar abām rokam un kājām!
• Īss pārskats par Explain komandu un tās doto rezultātu.

Bija, protams, ne tas vien, bet ne jau visu var atcerēties un šo to no pārējā var redzēt augšminētajās prezentācijās. Pārskatot tagad slaidus, man piesaistīja uzmanību šajā uz beigām parādītās atskaišu iespējas kā ar vienkāršu SQLu (savienojumi un grupēšanas) iegūt sakārtojumus un tekošās summas (running total). Lai gan seminārā Jay Pipes teica, ka neko nezinot par analītiskajām funkcijām, šie ir tipiski analītisko funkciju piemēri, tikai realizēti bez tām. Atliek tikai piebilst, ka izmantojot analītiskās funkcijas, šos SQL teikumus varētu vismaz 3 reizes saīsināt 😉