✉️ Saņem šito visu e-pastā. Tā vietā, lai palaistu garām kaut ko no tā, ko es rakstu savā blogā, tagad vari pierakstīties un saņemt e-pastā visu, ko es te rakstu. Tas nav bieži.

← Uz sākumu

MySQL 5 un VIEW

2005. gada 15. decembrī, 16 komentāri

Viens secinājums - iekš piektā MySQL (pagaidām?) VIEWi ir simboliski. Tie netiek optimizēti, kešoti, fonā reģenerēti, u.t.t. Žēl, jo šis ir viens no punktiem, uz kuru liku lielas cerības. Pagaidām atstājam crontabā low-priority-regenerate-views.php...

Tu atbildi augstāk redzamajam komentāram. Atcelt

Gravatar lietotājs

2005. gada 15. decembrī, plkst. 13:41

pie 'ALGORITHM = MERGE' cache gan tiek izmantots normālā veidā, optimizēšana gan vairāk attiecas uz sql rakstītāja sirdsapziņas un indexu pieejamības. Bet optimizējot attiecīgos selectus, iegūt nepieciešamo funkcionalitāti, lietojot view'us, ir iespējams (nerunājot par tiešām specifiskām lietām).

Gravatar laacz Autors

2005. gada 15. decembrī, plkst. 13:54

lietotājs: Neder. Man ir tabula, kura tiek apdeitota (INSERT/UPDATE) reizi dažās sekundēs. Ierakstu skaits sliecās pāri vairākiem miljoniem. Attiecīgi, ar nožēlu jāatzīst, ka cache nepalīdz, jo tabula mainās pārāk bieži. Selektā tiek grupēts pēc INT(11) lauka, uz kuru ir indekss. Selekts vidēji izpildās vairākas minūtes. Man vairāk patiktu, ja es uztaisītu VIEWu un tas, teiksim, reizi desmit/piecpadsmit minūtēs <em>fonā</em> pats sevi lēnām reģenerētu.

Selekta optimizācija nav iespējama, jo tas ir pats vienkāršākais grupēšanas selekts. Indeksu optimizācija, cik nu es saprotu, arī nav iespējama. Jo lauks, pēc kura tiek grupēts, ir viens.

Pilnīgi iespējams, ka šai problēmai ir cits risinājums, bet man kā RDBMS nespeciālistam nekas prātā nenāk (ja neskaita jaudas audzēšanu un db klāsterēšanu).

Gravatar sql

2005. gada 15. decembrī, plkst. 15:30

nejauc "view" ar "materialized view".

pat postgre nav kaartiiga atbalsta materializeetajiem skatiijumiem. ja ar to grib nodarboties nopietni, tad jaanjem oracle vai kas tamlidzigs.

Gravatar misame

2005. gada 15. decembrī, plkst. 16:18

Khm, Laacz, bet kur tad notiek tā, kā Tu gribētu? Cik skatos, microsoft sql arī parastie view-i ir tieši tādi, kā Tu apraksti, proti, ģenerēti atvēršanas laikā. Cita lieta, indeksētie skati, kas patiesībā tādas pat tabulas vien ir.

Gravatar laacz Autors

2005. gada 15. decembrī, plkst. 16:23

misame: Tie tomēr ir nevis parastie viewi, bet gan materializētie, kurus MySQL nesuportē. Tie mani arī interesē. Piem., <a href="http://www.ss64.com/ora/mview_c.html" title="Create Mview" rel="nofollow">tā tas ir iekš ORA</a>.

Gravatar valdiic

2005. gada 15. decembrī, plkst. 18:45

Un kādas problēmas realizēt materiālo skatu, izmantojot trigerus? Vismaz postgresql tas vienmēr izdevies eleganti.

Gravatar sql

2005. gada 16. decembrī, plkst. 09:54

valdiic - kaadas probleemas paarvietosanos no maajaam uz darbu 20km realizeet, izmantojot kaajas?

Gravatar valdiic

2005. gada 16. decembrī, plkst. 12:54

sql: un jūs, cienītais, piedāvājat braukt ar ļoti, ļoti dārgu taksi? Es laprātāk izmantoju sabiedrisko transportu, kas šajā gadījumā, manuprāt, atbilst trigeriem. Nav tik ērti, bet rezultāts ir labs.

Gravatar valdiic

2005. gada 16. decembrī, plkst. 16:13

Tādā gadījumā, kad ir vajdzība lietot materiālos skatus, Oracle Database 10g Express Edition diez vai derēs. Oracle Database XE ir ierobežojoši faktori: 4GB lietotāja dati (uz hdd), 1GB RAM, 1CPU. Tik mazās datubāzēs materiālie skati parasti nav nepieciešami.

Gravatar misame

2005. gada 17. decembrī, plkst. 13:12

valdiic: kā redzi, jau pie dažiem miljoniem rindu sāk gribēties materializētos skatus. Un tas noteikti neaizņem 4gb.

Gravatar valdiic

2005. gada 17. decembrī, plkst. 15:29

misame, un cik pēc tavām domām aizņem sakarīga tabula ar vairākiem miljoniem ierakstu + vēl materiālie skati? Man šķiet, ka ar 4 GB ļoti drīz būs par īsu. Jadomā taču uz priekšu. Tādos retos gadījumos, kad ir skaidri zināms, ka datubāzes lietotāja datu kopējais izmērs nekad, nekad neaizņems vairāk par 4GB, Oracle piedāvāto XE var lietot. Bet es tomēr iesaku palūrēt mazliet tālāk par savu degungalu. ;)

Gravatar jozhix

2005. gada 21. decembrī, plkst. 05:01

tu esi paarliecinaats ka tava selektaa tiek izmantots indeks? paaris minuutes, tas jau izskataas uz full table scan!

  1. pameegjini to pashu selektu, tikai bez group by (lai redzeetu vai bremzee deelj grupeeshanas vai nee)
  2. indexam, protams, ka jaabuut arii uz where nosaciijumiem.

2 valdiic - ir redzeetas arii datubaazes ar 10 mlj ieraxtiem, kas aiznjemt

Gravatar jozhix

2005. gada 21. decembrī, plkst. 05:02

2 valdiic - ir redzeetas arii datubaazes ar 10 mlj ieraxtiem, kas aiznjemt

Gravatar jozhix

2005. gada 21. decembrī, plkst. 05:03

2 valdiic - ir redzeetas arii datubaazes ar 10 mlj ieraxtiem, kas aiznjemt zem 1GB. visa db tiek ielaadeeta un glabaata atminjaa. ilgaakais selects izpildiijaas 10 sec, un tas jau bija pasaules gals (oracle optimizeris izdomaaja ignoreet inexus). ar indexiem selekts izpildaas momentaali (zem 1 sec). nu db serveris protams, atbilstosh, ar 4etriem xenon cpu.

bljin, ziimi mazaaks nevar ieraxtiit.