|
Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
| autor |
|
spreiii
HV kasutaja
liitunud: 27.12.2008
|
11.11.2011 01:19:56
MySQL päringu optimeerimine |
|
|
Tervist, vajan abi sql päringu optimeerimisel (või siis uue lahenduse leidmisel). Tegu on menüü tabeliga, kust peaks teatud read igal korral lehele väljastama.
Mida üritan saavutada: Tabelist "mainmenu" valitakse pealkirja tüüp (title_type - Väärtused: 0-Samast tabelist, pole php konstant, 1-Mooduli tabelist ID järgi, 2-Samast tabelist, on php-s konstant),
custom_a (link, kui tegu pole mooduliga), custom_click (onclick action lingil), objekti nimi(kui tüüp = 1), module_name (kui tüüp = 1), link_title (igal tüüp = x korral)
| sql:
|
SELECT `title_type`, `custom_a`, `custom_click`, IF(title_type = '1', (SELECT objects.object_name FROM `objects` WHERE mainmenu.object_id = objects.object_id), '0') AS object_name, IF(title_type = '1', (SELECT `short` FROM `modules` WHERE mainmenu.module_id = modules.id), '0') AS module_name, IF(title_type = '1', (SELECT `long` FROM `modules` WHERE mainmenu.module_id = modules.id), (SELECT `title`)) AS link_title FROM `mainmenu` WHERE enabled = '1' ORDER BY `position`
|
Kood ise on toimiv, aga ilmselgelt pole see optimaalne lähenemine. Kas mingil viisil on võimalik subquery'd panna ühe IF'i alla? Kas peaks mainmenu tabeli üleüldse ringi tegema?
Tabelid:
 Spoiler
| sql:
|
CREATE TABLE IF NOT EXISTS `mainmenu` ( `item_id` int(11) NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL DEFAULT 'Link', `title_type` int(1) NOT NULL DEFAULT '0' COMMENT '0 - From title field; 1 - From module; 2 - From constant', `object_id` int(11) NOT NULL DEFAULT '0', `module_id` int(11) NOT NULL DEFAULT '0', `custom_a` varchar(255) NOT NULL DEFAULT '#', `custom_click` varchar(255) DEFAULT NULL, `enabled` int(1) NOT NULL DEFAULT '1', `level` int(1) NOT NULL DEFAULT '0', `level_max` int(1) NOT NULL DEFAULT '0', `position` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`item_id`), KEY `enabled_INDEX` (`enabled`), KEY `level_level_max_INDEX` (`level`,`level_max`), KEY `position_INDEX` (`position`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ;
|
| sql:
|
CREATE TABLE IF NOT EXISTS `objects` ( `object_id` int(11) NOT NULL AUTO_INCREMENT, `object_name` varchar(50) NOT NULL, PRIMARY KEY (`object_id`), UNIQUE KEY `object_name` (`object_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=4 ;
|
| sql:
|
CREATE TABLE IF NOT EXISTS `modules` ( `id` int(11) NOT NULL AUTO_INCREMENT, `short` varchar(50) NOT NULL, `long` varchar(255) NOT NULL, `object_id` int(11) NOT NULL, `enabled` int(1) NOT NULL DEFAULT '0', `configurable` int(1) NOT NULL DEFAULT '0', `core_element` int(1) NOT NULL DEFAULT '0', `user_level` int(1) NOT NULL DEFAULT '0', `admin_level` int(1) NOT NULL DEFAULT '9', PRIMARY KEY (`id`), UNIQUE KEY `short_UNIQUE` (`short`), KEY `enabled_INDEX` (`enabled`), KEY `admin_level_INDEX` (`admin_level`), KEY `user_level_INDEX` (`user_level`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=8 ;
|
|
|
| Kommentaarid: 23 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
23 |
|
| tagasi üles |
|
 |
Fukiku
Kreisi kasutaja
liitunud: 06.11.2003
|
|
11.11.2011 10:27:21
|
|
|
Ilusam ja elegantsem ja paremini loetav lahendus oleks äkki sellest päringust teha view? Ehk siis - sul on kaks päringut põhimõtteliselt - title_type = 1 ja title_type != 1. View jaoks võiks kummagi juhu eraldi ühe päringuna välja kirjutada - siis saab kenasti JOIN konstruktsioone kasutada ja asi näeb oluliselt viisakam välja ning siis mõlemad päringud view definitsiooni panna ja UNION võtmesõnaga kokku liita. Rakendusse saab siis panna aga juba mingi täiesti primitiivse päringu, mis selle view pihta käib.
Koodikeeles võiks see välja näha midagi taolist:
| sql:
|
CREATE OR REPLACE VIEW menu_data AS SELECT ... -- lisa vajalikud väljad, tabelite join'id jne WHERE title_type = 1 UNION SELECT ... -- lisa vajalikud väljad, tabelite join'id teise variandi jaoks WHERE title_type != 1
|
Rakendusse jääb siis aga lihtsalt
| sql:
|
SELECT * FROM menu_data WHERE ...
|
_________________
Foxic is just a simple fox
Enne kui sa küsid oma küsimuse - küsi seda vannipardilt! Rangelt soovitatav enne programmeerimise alafoorumisse uue teema tegemist. |
|
| Kommentaarid: 2 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
2 |
|
| tagasi üles |
|
|
nemu
HV vaatleja
liitunud: 22.01.2002
|
|
11.11.2011 10:28:02
Re: MySQL päringu optimeerimine |
|
|
Kõigepealt vähe loetavamale kujule
| sql:
|
SELECT mm.title_type, mm.custom_a, mm.custom_click, o.object_name AS object_name, m.short AS module_name, m.long AS module_longname FROM mainmenu mm LEFT JOIN objects o ON (mm.object_id = o.object_id AND mm.title_type = 1) LEFT JOIN modules m ON (mm.module_id = m.id AND mm.title_type = 1) WHERE mm.enabled = 1 ORDER BY mm.position;
|
|
|
| Kommentaarid: 12 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
11 |
|
| tagasi üles |
|
|
Fukiku
Kreisi kasutaja
liitunud: 06.11.2003
|
|
11.11.2011 12:28:28
Re: MySQL päringu optimeerimine |
|
|
| nemu kirjutas: |
Kõigepealt vähe loetavamale kujule
| sql:
|
SELECT mm.title_type, mm.custom_a, mm.custom_click, o.object_name AS object_name, m.short AS module_name, m.long AS module_longname FROM mainmenu mm LEFT JOIN objects o ON (mm.object_id = o.object_id AND mm.title_type = 1) LEFT JOIN modules m ON (mm.module_id = m.id AND mm.title_type = 1) WHERE mm.enabled = 1 ORDER BY mm.position;
|
|
Hetkel jätab Sinu lahendus arvestamata asjaolu, et kui title_type != 1, siis oli vaja teised andmed pärida. Jah, need võiks hetkel lihtlabaselt lisada päritavate veergude hulka, aga sel juhul tuleb hakata rakenduses päringu tulemustest erinevaid veerge lugema vastavalt title_type väärtusele, mis tekitab täiendava keerukuse, mida poleks ilmselt vaja.
Aga eks teemapüstitaja ise otsustab, mis talle meeldib.. 
_________________
Foxic is just a simple fox
Enne kui sa küsid oma küsimuse - küsi seda vannipardilt! Rangelt soovitatav enne programmeerimise alafoorumisse uue teema tegemist. |
|
| Kommentaarid: 2 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
2 |
|
| tagasi üles |
|
|
nemu
HV vaatleja
liitunud: 22.01.2002
|
|
11.11.2011 12:45:29
|
|
|
Arvestamata asjaolud on ilmselt kuskil ridade vahel nii et ma ei suuda neid näha.
Lähtusin rohkem lausest "Kood ise on toimiv...".
Kui "menu" pole ajas eriti muutuv, siis võiks hoopis mälus hoida ja aegajalt baasist värskendada.
|
|
| Kommentaarid: 12 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
11 |
|
| tagasi üles |
|
|
spreiii
HV kasutaja
liitunud: 27.12.2008
|
|
11.11.2011 12:50:48
|
|
|
Fukiku, tänud kõigepealt  , proovin seda lahendust ning annan teada kuidas õnnestus.
| nemu kirjutas: |
| Kui "menu" pole ajas eriti muutuv, siis võiks hoopis mälus hoida ja aegajalt baasist värskendada. |
Menu on ajas muutuv niipalju, et kui kasutaja pole sisse logitud, näidatakse üht, kui kasutaja on sisse logitud, on menüü jällegi veidi teistsugune.
|
|
| Kommentaarid: 23 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
23 |
|
| tagasi üles |
|
|
Fukiku
Kreisi kasutaja
liitunud: 06.11.2003
|
|
11.11.2011 12:57:19
|
|
|
| nemu kirjutas: |
Arvestamata asjaolud on ilmselt kuskil ridade vahel nii et ma ei suuda neid näha.
Lähtusin rohkem lausest "Kood ise on toimiv...".
Kui "menu" pole ajas eriti muutuv, siis võiks hoopis mälus hoida ja aegajalt baasist värskendada. |
Viitasin sellele, et esialgses päringus oli IF lausetel olemas ka ELSE osa, mille sinu päring arvestamata jättis.
_________________
Foxic is just a simple fox
Enne kui sa küsid oma küsimuse - küsi seda vannipardilt! Rangelt soovitatav enne programmeerimise alafoorumisse uue teema tegemist. |
|
| Kommentaarid: 2 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
2 |
|
| tagasi üles |
|
|
nemu
HV vaatleja
liitunud: 22.01.2002
|
|
11.11.2011 13:07:17
Re: MySQL päringu optimeerimine |
|
|
Viimane on tõesti kaduma läinud.
| sql:
|
SELECT mm.title_type, IF (mm.title_type = 1, NULL, mm.custom_a) AS custom_a, mm.custom_click, o.object_name AS object_name, m.short AS module_name, IF (mm.title_type = 1, m.long, mm.title) AS link_title FROM mainmenu mm LEFT JOIN objects o ON (mm.object_id = o.object_id AND mm.title_type = 1) LEFT JOIN modules m ON (mm.module_id = m.id AND mm.title_type = 1) WHERE mm.enabled = 1 ORDER BY mm.position;
|
|
|
| Kommentaarid: 12 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
11 |
|
| tagasi üles |
|
|
spreiii
HV kasutaja
liitunud: 27.12.2008
|
|
11.11.2011 13:23:53
|
|
|
nemu, see lahendus täitsa toimib
Pole veel jõudnud VIEW varianti proovida, kuid kumb peaks loogiliselt võttes kiirem olema?
Niipalju kui jõudsin selle kohta lugeda, sain teada, et teatud query'de puhul võib ta kiirust hoopis alandada.
Explain annab järgmise tulemuse:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE mm ref enabled_INDEX enabled_INDEX 4 const 2 Using where; Using filesort
1 SIMPLE o eq_ref PRIMARY PRIMARY 4 data.mm.object_id 1
1 SIMPLE m eq_ref PRIMARY PRIMARY 4 data.mm.module_id 1 |
Kõigi puhul võib ilmselt rahule jääda.
|
|
| Kommentaarid: 23 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
23 |
|
| tagasi üles |
|
|
Le Inc
HV Guru
liitunud: 06.09.2002
|
|
24.11.2011 20:19:29
|
|
|
Kiiruse saad teada kui päringu sooritad. Üks viis "optimeerimiseks" on kasutada SSD kettaid. 
Näiteks sama päring SSD vs. vanakooli SCSI vint on ~10x kiiruse vahe mäluketta kasuks.
|
|
| Kommentaarid: 56 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
54 |
|
| tagasi üles |
|
|
spreiii
HV kasutaja
liitunud: 27.12.2008
|
|
24.11.2011 23:03:52
|
|
|
| Le Inc kirjutas: |
Kiiruse saad teada kui päringu sooritad. Üks viis "optimeerimiseks" on kasutada SSD kettaid.
Näiteks sama päring SSD vs. vanakooli SCSI vint on ~10x kiiruse vahe mäluketta kasuks. |
Seda kindlasti.
Kahjuks kogemusi hetkel SSD ketastega ei ole, kuid järgmisel kuul lähen üle Sandy Bridge'ile (i5 2500K) ja loodetavasti järgmisel aastal saan soetada oma esimese SSD. 
|
|
| Kommentaarid: 23 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
23 |
|
| tagasi üles |
|
|
Redikate
HV veteran
liitunud: 30.12.2005
|
|
28.11.2011 13:03:08
|
|
|
| Le Inc kirjutas: |
Kiiruse saad teada kui päringu sooritad. Üks viis "optimeerimiseks" on kasutada SSD kettaid.
Näiteks sama päring SSD vs. vanakooli SCSI vint on ~10x kiiruse vahe mäluketta kasuks. |
Kodus võid ju oma baase SSD peal hoida, kuid paljud teenuspakkujad tänasel päeval SSD lahendust pakuvad?
_________________
http://nodejs.org/
"I'm also a person. Programming is just one thing I do." |
|
| Kommentaarid: 34 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
33 |
|
| tagasi üles |
|
|
2korda2
HV kasutaja
liitunud: 19.07.2003
|
|
01.12.2011 18:14:34
|
|
|
| Le Inc kirjutas: |
Kiiruse saad teada kui päringu sooritad. Üks viis "optimeerimiseks" on kasutada SSD kettaid.
Näiteks sama päring SSD vs. vanakooli SCSI vint on ~10x kiiruse vahe mäluketta kasuks. |
Siin on 2 viga:
1. Kiiruse teadasaamiseks pressid "Explain Plan" (või mis iganes selle nupu nimi kasutatavas vahendis on). See ei soorita päringut. Küll ja küll olen sedasi kinni püüdnud päringuid "oleks kiirelt LIVE-st vaja andmeid saada, pane ainult käima".
2. Tarkvaralisi probleeme ei lahendata riistvaraga. See "10x vahe" on optimistlik, samas päringut optimeerides võid võita mitme suurusjärgu rohkem ja seda igasuguse riistvara peal. Optimeerimine algab aga andmemudelist - kui selles faasis on üle jala lastud, siis hiljem on väga raske.
|
|
| Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
| tagasi üles |
|
|
serk
HV kasutaja
liitunud: 24.05.2003
|
|
01.12.2011 23:16:58
|
|
|
Reaalne päring + fetch ja selleks kujunev aeg selgub ikka peale käivitamist, explain plan annab mingisuguse aimduse sellest.
Väide on õige, et optimeerimine algab andmemudelist, aga reaalsuses on seda hiljem muuta sama võimatu kui saada lahti Savisaarest. Ehk lõpuks hakatake ikka sitast saia tegema kuna lihtsalt muud võimalust ei ole.
Ma muidugi ei ütleks, et riistvaraliselt tuunimine oleks väga vale. Me saime näiteks 10% baasi võimsuses juurde liikudes Linuxile, mis võimaldas kasutada teisi prosesi. Sama numbri saamiseks softi tuunides, oleks investeering pidanud olema ca 10x rohkem kui raha kulus riistvarale. Oracle mõistes upgrade näiteks 10g pealt 11g peale annab niivõrd palju võimalusi päringute tuunimiseks, et tõenäoliselt jällegi odavam kõik suured päringud üle käia ja ringi kirjutada kui riistvara juurde osta.
Case by case.
|
|
| Kommentaarid: 8 loe/lisa |
Kasutajad arvavad: |
|
:: |
1 :: |
0 :: |
7 |
|
| tagasi üles |
|
|
Le Inc
HV Guru
liitunud: 06.09.2002
|
|
18.12.2011 20:08:06
|
|
|
| 2korda2 kirjutas: |
| Le Inc kirjutas: |
Kiiruse saad teada kui päringu sooritad. Üks viis "optimeerimiseks" on kasutada SSD kettaid.
Näiteks sama päring SSD vs. vanakooli SCSI vint on ~10x kiiruse vahe mäluketta kasuks. |
Siin on 2 viga:
1. Kiiruse teadasaamiseks pressid "Explain Plan" (või mis iganes selle nupu nimi kasutatavas vahendis on). See ei soorita päringut. Küll ja küll olen sedasi kinni püüdnud päringuid "oleks kiirelt LIVE-st vaja andmeid saada, pane ainult käima".
2. Tarkvaralisi probleeme ei lahendata riistvaraga. See "10x vahe" on optimistlik, samas päringut optimeerides võid võita mitme suurusjärgu rohkem ja seda igasuguse riistvara peal. Optimeerimine algab aga andmemudelist - kui selles faasis on üle jala lastud, siis hiljem on väga raske. |
Mida teha kui pärid ~1 miljonilisest tabelist näiteks max(id) väärtust? Või küsid mingit osa tabelist? Tabelil on unikaalne id ja indeksid olemas. Ei oska rohkem optimeerida. Päring võtab ~13 .. 15 sek aega. SSD peal kuskil sekundi kandis. Mälu ja prose on ka uuel baasil kiiremad/suuremad. See pole ilmselt nii määrav kui vint, too on just põhiline mis pidurdab (ketas on tõesti vana, ilmselt tänapäevane "tavaline" desktopi 1 TB ketas oleks kiirem).
SSD on uus ja uurimata bisnis andmebaasides. Teatud olukordades on asi väga põhjendatud, iseasi kas ka kestvust on. Eks aeg näitab.
|
|
| Kommentaarid: 56 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
54 |
|
| tagasi üles |
|
|
2korda2
HV kasutaja
liitunud: 19.07.2003
|
|
18.12.2011 21:21:12
|
|
|
| Le Inc kirjutas: |
| Mida teha kui pärid ~1 miljonilisest tabelist näiteks max(id) väärtust? .....Päring võtab ~13 .. 15 sek aega. |
Ma pean tunnistama, et olen MySQL-ga kokku puutunud ainult libamisi aga see lihtsalt ei saa tõsi olla tingimusel, et see ID on PK. Midagi peab süsteemis VÄGA mäda olema (mälu ei ole piisavalt?).
Miljoni kirjega tabelid baasis, mis jooksis tavalises desktopis - see oli tuttav probleem aastal 2001-2003, kui riistavara maksis palju ja korralikku serveri jaoks polnud paljudel raha. Ma kahtlen, et su riistvara veel kehvem on. Ometi ei võtnud ka tollal sellised päringud nii kaua aega. Mootoriks oli Sybase ASA (7 või 8).
Lisaks, milleks kasutad max(id)? Minul on seda vaja olnud vaid probleemsetes olukordades, kus keegi on osanud kuidagi sequence-i katki teha (andmete baasi laadimine sequence't kasutamata vms).
|
|
| Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
| tagasi üles |
|
|
Le Inc
HV Guru
liitunud: 06.09.2002
|
|
18.12.2011 22:05:39
|
|
|
See oli lihtsalt näide. Kui küsid näiteks mingit osa tabelist read 340 - 360 vms (kuvatakse mingi X arv lehti korraga), siis on sama päringu aeg. Kusjuures see kasvas koos tabeli suurenemisega proportsionaalselt. Jah "select count(*) from tabel" võtab tõesti murdosa sekundist aega iga ilmaga.
Tegu siis ikkagi tasulise Oracle 10g baasiga. Tõsi raud on vana ja jookseb XP peal. Nii või naa, SSD'ga on elu hoopis teises dimensioonis. Siin põmst ei peagi koodi optimeerima. Peaasi et kettad kestaks.
|
|
| Kommentaarid: 56 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
54 |
|
| tagasi üles |
|
|
serk
HV kasutaja
liitunud: 24.05.2003
|
|
19.12.2011 11:11:08
|
|
|
See et sul on primary key ja indeksid ja üle nende teed päringu, ei tähenda veel, et käivitusplaan korras oleks.
Alati on võimalus arvutada andmeid ette kas planeeritult või online'is või kasutada Compressionit(aitab kombinatsioonis aeglane ketas-kiire prose. 10g küll natuke piiratud, aga effekti annab), partitsioneerimist või hoopis midagi muud.
|
|
| Kommentaarid: 8 loe/lisa |
Kasutajad arvavad: |
|
:: |
1 :: |
0 :: |
7 |
|
| tagasi üles |
|
|
2korda2
HV kasutaja
liitunud: 19.07.2003
|
|
19.12.2011 18:51:19
|
|
|
Oracle XP peal on nagu sadul sea seljas - saab aga pole kombeks. Kõige tõenäolisem probleem (kui baas on tõesti suur) - mälukasutus.
| tsitaat: |
| Nii või naa, SSD'ga on elu hoopis teises dimensioonis. Siin põmst ei peagi koodi optimeerima. |
Palun kustuta see väide oma postitusest - mõni veel loeb ja usubki. Kordan veelkord - riistvaraga ei saa kuidagi õige tarkvaralise lähenemise (andmemudel+päringute optimeerimine) vastu.
Kui teinekord on tõesti puudu just see viimased 10% jõudlusest, siis ehk on odavam riistvaraga punnitada aga 90+% juhtudest ei ole see ka siis õige lähenemine (vajadused kipuvad kasvama vms).
|
|
| Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
| tagasi üles |
|
|
Le Inc
HV Guru
liitunud: 06.09.2002
|
|
21.12.2011 09:30:59
|
|
|
.. selge see, et päringud peavad korras olema. Kindlasti korraliku RAID ketta paariga jookses sql nigu tuli takus. Optimeerimine muutub vististi eriti tähtsaks suurte, mitmemiljoniliset kirjete puhul (a la facebuugid, google kama jne.). Eks kiirem raud annab rohkem andeks (selles oli mu eelmise postituse iva). Samas olgem ausad, kiirusevõit pole mitte "tsipa" vaid ikkagi s*taks suur, kui sa vaatad 4kb I/O teste siis saad aru millest ma räägin. 
Endal pikem kogemus puudub SSD ja samas ka korraliku ketta süsteemiga varustatud Oracle'ga. Nüüd MS 2008 R2 ja 11g 64bit (16GB mälu).
|
|
| Kommentaarid: 56 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
54 |
|
| tagasi üles |
|
|
2korda2
HV kasutaja
liitunud: 19.07.2003
|
|
21.12.2011 13:05:04
|
|
|
Le Inc,
kui sa vaataks reaalsete süsteemide reaalset kõvaketta trace-i, siis saaksid aru, miks võit ei ole "s*taks suur". Mind häirib see haip SSD juures - ikka ja jälle tuuakse näiteks 4kb/32Q tulemusi adumata, et 32-ni ei jõua desktopi kasutaja paremagi tahtmise juures (Tomshardware testis hiljuti ja leidis, et isegi 2 on pigem harv näitaja) ja isegi serveritel on tegemist väga erilise olukorraga. Korrektselt kokku pandud serveri puhul töötab baas suuresti mälust - see on kordi kiirem, kui ka kiireim SSD. Ma ei ütle, et SSD võitu ei anna - midagi ikka annab. Sellele lootma jääda oleks aga suur rumalus. Lihtsalt tüüpiliselt on suurte baaside korral andmemassiivis märksa rohkem kui "RAID ketta paar" ja seetõttu ka võimalik võit SSD-le minnes väiksem.
Mis puudutab aga miljoni kirjega tabeleid, siis neid leidub ka meie kodumaral töötavates süsteemides hulgem. Esimene baas, kus "minu käe all" miljon täis sai, oli aga tollal veel suhteliselt väikese pagari/kulinaariatööstuse oma. Facebookid, googlid jms kama ei jookse enam "vana hea" relatsioonilise baasi peal. Need mootorid ei skaleeru piisavalt 
|
|
| Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
| tagasi üles |
|
|
b_alex
HV kasutaja
liitunud: 22.02.2008
|
|
21.12.2011 17:55:34
|
|
|
| tsitaat: |
abi sql päringu optimeerimisel (või siis uue lahenduse leidmisel).
Tegu on menüü tabeliga, kust peaks teatud read igal korral lehele väljastama.
Mida üritan saavutada: Tabelist "mainmenu" valitakse pealkirja tüüp
(title_type - Väärtused: 0-Samast tabelist, pole php konstant, 1-Mooduli tabelist ID järgi
|
kas mingi tulemust ka testid, katsud, mis kiirem vms
, sekundides testi vms, teed kah?
_________________
O: HDD 2,5-3,5" - 2-4TB |
|
| Kommentaarid: 22 loe/lisa |
Kasutajad arvavad: |
|
:: |
1 :: |
0 :: |
20 |
|
| tagasi üles |
|
|
Le Inc
HV Guru
liitunud: 06.09.2002
|
|
22.12.2011 13:00:55
|
|
|
| 2korda2 kirjutas: |
Le Inc,
kui sa vaataks reaalsete süsteemide reaalset kõvaketta trace-i, siis saaksid aru, miks võit ei ole "s*taks suur". Mind häirib see haip SSD juures - ikka ja jälle tuuakse näiteks 4kb/32Q tulemusi adumata, et 32-ni ei jõua desktopi kasutaja paremagi tahtmise juures (Tomshardware testis hiljuti ja leidis, et isegi 2 on pigem harv näitaja) ja isegi serveritel on tegemist väga erilise olukorraga. Korrektselt kokku pandud serveri puhul töötab baas suuresti mälust - see on kordi kiirem, kui ka kiireim SSD. Ma ei ütle, et SSD võitu ei anna - midagi ikka annab. Sellele lootma jääda oleks aga suur rumalus. Lihtsalt tüüpiliselt on suurte baaside korral andmemassiivis märksa rohkem kui "RAID ketta paar" ja seetõttu ka võimalik võit SSD-le minnes väiksem.
Mis puudutab aga miljoni kirjega tabeleid, siis neid leidub ka meie kodumaral töötavates süsteemides hulgem. Esimene baas, kus "minu käe all" miljon täis sai, oli aga tollal veel suhteliselt väikese pagari/kulinaariatööstuse oma. Facebookid, googlid jms kama ei jookse enam "vana hea" relatsioonilise baasi peal. Need mootorid ei skaleeru piisavalt |
Sul võib täiesti õigus olla. Samas ei saa öelda et SSD põhine baas kiire ei oleks.
|
|
| Kommentaarid: 56 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
54 |
|
| tagasi üles |
|
|
spreiii
HV kasutaja
liitunud: 27.12.2008
|
|
31.12.2011 02:06:08
|
|
|
b_alex, lähipäevil üritan ära teha
Hetkel asi täiesti toimib kogu süsteemi kõrval ning erilist kiirusekadu pole märganud (kogu lehe load time Netpointi serveris ~0,02-0,08 sec - mõõdetud PHPs microtime'i abiga). See aga kindlasti kuigipalju tõuseb, kuna mooduleid lisandub juurde.
Edit:
Niisiis, siin on lõpptulemus:
Query:
| sql:
|
SELECT mm.title_type, IF( mm.title_type = '1', NULL , mm.custom_a ) AS custom_a, IF( mm.title_type = '1', NULL , mm.custom_click ) AS custom_click, o.object_name AS object_name, m.short AS module_name, IF( mm.title_type = '1', m.long, mm.title ) AS link_title FROM mainmenu mm LEFT JOIN objects o ON ( mm.object_id = o.object_id AND mm.title_type = '1' ) LEFT JOIN modules m ON ( mm.module_id = m.id AND mm.title_type = '1' ) WHERE mm.enabled = '1' AND 0($user_level väärtus) >= level AND 0($user_level väärtus) <= level_max ORDER BY mm.position
|
EXPLAIN annab järgmise tulemuse:
Spoiler
Ja mitmeid kordi query't tehes sain tulemusteks:
Query took 0.0011 sec
Query took 0.0009 sec
Query took 0.0010 sec
Ja PHP's teen järgnevat:
| php:
|
{ { if($menu_r['title_type'] == 1) { $return .= '<a href="'.addr_home . addr_homedir . strtolower($menu_r['object_name']) . '/' . strtolower($menu_r['module_name']). '/"><ul><li>'. constant($menu_r['link_title']). '</li></ul></a>'; } else { $return .= '<a href="'.addr_home . addr_homedir . strtolower($menu_r['custom_a']) . '" onclick="'. $menu_r['custom_click']. '"><ul><li>'; if($menu_r['title_type'] == 0) $return .= $menu_r['link_title']; else { $return .= constant($menu_r['link_title']); } $return .= '</li></ul></a>'; } } } else $return .= "<ul><li>".lib_mainmenu_no_items."</li></ul>";
|
|
|
| Kommentaarid: 23 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
23 |
|
| tagasi üles |
|
|
|
:: KKK
:: otsing 
:: statistika
:: kasutajate nimekiri
:: kasutajate grupid
:: registreeri
teata moderaatorile
