Lūdzu palīdzību SQL valodā

[ob1]

-> rATRIJS

Man nav saprotams —-> date(“d.m:Y H:i”)

nesaprotu arī —> ‘$id’

[usver]

ob1: tmp tabulas uz disku nesvaposies, kamēr vien iekļausies DBVS norādītajos limitos. Ja grasies 10 miljonus ierakstu x miljonu preču griezt, tad lasi bez tmp tabulām, ciklus rīkojot izpildāmā koda pusē. Bet šiem 9 ierakstiem vaicājums derēs atliektiem galiem.

Ja interesē – taisi benčmarkus! pašam jau tā datubāze vien ir – neviens cits nevar izzīlēt, vai serverim resursu pietiks.

esmu darbojies ar 12GB datubāzēm. priekš tmp tabulu lietošanas milzīgiem datiem reizēm ir jātūnē serveris. Pie saprātīgiem ierakstu daudzumiem, kamēr ramā satilpst, viss strādā bez aizturēm. Cik nav bijis – aizeju pie datubāzes .. kaut kas bremzē. Pielaboju bērnu smilškastei piemēroto konfigurāciju uz normālu – uz tiem pašiem dzelžiem pēkšņi viss sāk strādāt reizes 4 ātrāk. Un vispār – lieto indeksus, jedritvai. Tieši tas spēj stipri uzlabot veiktspēju. Ja darbosies bez tiem – DBVS tupi mals cauri visu lielo tabulu, neskatoties, ko vajag un ko ne. Ar indeksiem tās tmp tabulas būs daudz mazākas.

[Andress]

ob1 wrote:

-> rATRIJS

Man nav saprotams —-> date(“d.m:Y H:i”)

nesaprotu arī —> ‘$id’

PHP datums un preces $id 🙂 Cmoon big guy, variables…

[ob1]

->Andress

Vispār jau JOIN nebremzē, ja vien WHERE klauze ir optimizējama un ir pareizi salikti indeksi.

A par tiem mainīgajiem, kādām vērtībām tur ir jābūt?

[Andress]

usver wrote:

esmu darbojies ar 12GB datubāzēm.

Muaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahahaha1oneleven11111!!111111 :DDD tu zini cik daudz texta datu ietilpst 12Gb? 😀 Nu kautvai bilžu? 😀 Zini kadam jabut tavam dedicated servim lai spetu apstradat 12Gb VIENKARŠ AS DB ar 1 tabulu un paris kolonnam? Zini ka ar izpildes atrumu 100mbps tavs query pildisies kkur 20min? 😀 Es ļoti gribetu zinat ka tu optimizeji tas tabulas un kas tas bija par serveri :DDDD

[Andress]

ob1 wrote:

->Andress

Vispār jau JOIN nebremzē, ja vien WHERE klauze ir optimizējama un ir pareizi salikti indeksi.

A par tiem mainīgajiem, kādām vērtībām tur ir jābūt?

JOIN iebremzē, iebremzē, pabenčmarko kautway ar dummy datiem iekš sql 🙂

$id = preces id nummurs piemeram 1, date() = 10.11.2009 14:20 piemeram 😉

[ob1]

-> usver

jā indeksi palīdz… bet katrai precei taisīt subselektu? Bremzēs. Jo WHERE nav optimizējams.

[Andress]

Varbut var apvienot abas tabulas? 🙂

[ob1]

-> Andress

Vēlreiz atkārtošu – selekta ātrums praktiski nav atkarīgs no datubāzes izmēra, ja vien where clauze ir optimizējama un ir pareizi salikti indeksi.

[ob1]

Man vienalga – salikt to vienā selektā vai vairākos… galvenais, ka dabūju savus datus un bez bremzes.

[Andress]

Praktiski nav? No diska griešanās ātruma un cpu gan ir atkarīgs. 🙂

Tatad varbut apvieno tabulas? Precei jaunu kolonnu un split data tur iekšā

::10.11.2009 18:43-59.99::10.11.2009 16:43-50.99::10.06.2009 13:20-69.99 talak serevra pusee eksplode datus un paņemam lielako, easy as possible 🙂

[rATRIJS]

Protams, ka daudz kas ir atkarīgs no DB lieluma, bet vairumā gadījumu a-way-to-go būs JOIN’ot tabulas. Ja JOIN’i skatīsies uz indeksējamām vērtībām, tad arī pie lieliem datu apjomiem bremze nebūtu traģiska. Lielāka problēma varētu būt ar to, ka ir jāapstrādā un jāsūta lieli datu apjomi un var pietrūkties atmiņas.

subselekts šajā gadījumā, manuprāt, ir lieks.

ob1 – ja nezini ko varētu nozīmēd $id un date(), tad sorry, bet pie tevis mācīties “programmēt” neiešu

[usver]

Andress wrote:

usver wrote:

esmu darbojies ar 12GB datubāzēm.

Zini ka ar izpildes atrumu 100mbps tavs query pildisies kkur 20min? 😀

Tu jocīgs esi? nafik full table scan darīt, maļot cauri visu saturu? Speciāli priekš tā ir radīti indeksi – lai nav jāpārlasa viss datubāzes saturs pie katra WHERE.

Un jā, es ļoti labi zinu, cik daudz datu satilpst padsmit gigabaitos. Pēdējie dati – 18GB MyISAM datubāze. Tajā satilpst ~ 35`000 dokumentu, 31`000 uzdevumu, 822 lietotāji, 25`000 failu – gan vorda/ekseļa, gan skenētie.

Man liekas, ka šeit ir ideāli nākamie darbinieki – spēj gan stundu muldēt par to, kurš ir lohs un kurš nē, tā vietā, lai 20min laikā uztaisītu kaut feikus datus un patestētu performanci.ar lapvakaru.

[Andress]

usver wrote:

~ 35`000 dokumentu, 31`000 uzdevumu, 822 lietotāji, 25`000 failu – gan vorda/ekseļa, gan skenētie.

Cik liels ir tavs indekss? Izmēru studijā 🙂

[ob1]

Š obrīd usver varians ir labākais… mēģināšu testēt… foxsk8 (pa skaipu) ieteica limitēt rezultātus, hmm, to var mēģināt… bet ja kāds var uzrakstīt selektu ar optimizējamu where clauzi, tad lūdzu dariet tā.

[ob1]

SELECT Goods.id, Goods.name, Price.price;

FROM ;

data1!goods ;

LEFT OUTER JOIN data1!price ;

ON Goods.id = Price.id_good;

WHERE Price.when IN (sele max(when) from price where id_good=goods.id);

GROUP BY Goods.id;

ORDER BY Price.when

Dabūju error: Group clause missing or invalid…

[ob1]

SELECT Goods.id, Goods.name, Price.price;

FROM ;

data1!goods ;

LEFT OUTER JOIN data1!price ;

ON Goods.id = Price.id_good;

WHERE Price.when IN (select max(when) from price where id_good=goods.id);

ORDER BY Goods.id

Strādā. Hmm, tikai WHERE tāds sūdīgs… vai labāk nevar?

[usver]

Andress: indeksi ir vidēji 3..10 katrai tabulai, kopā aizņem 5..10KB uz tabulu. ar to pietiek, lai dati tiktu atrasti pēc vajadzīgajiem kritērijiem.

taisīt serializētus datus btw ir pret pirmo normālformu. Un splitot katru vērtību – tas ir lēnāk nekā selektot datus no normālas tabulas ar pārdesmit tūkstošiem ierakstu.

ob1: uz linukšiem? tad lieto korekti lielos-mazos burtus tabulu nosaukumos. + ” .. IN (sele max(when) ” ja ir cita dbvs nevis mysql, tad apakšvaicājumā limit var mēģināt lietot ar order by.

[ob1]

usver, nav uz linukšiem. Aizgāja, paldies… skat manu iepr. postu… tikai WHERE sūdīgs… 🙁

[ob1]

Paldies vēlreiz par idejām.

Paņēmos, uztaisīju manuprāt daudz ātrāk strādājošu variantu.

Code:

SELECT Goods.id, MAX(Price.when) as when;
FROM goods ;
LEFT JOIN price ON Goods.id = Price.id_good;
GROUP BY Goods.id ;
INTO CURSOR tc_1

SELECT tc_1.id, goods.name, price.price ;
FROM tc_1 ;
LEFT JOIN goods ON tc_1.id = goods.id ;
LEFT JOIN price ON tc_1.id = price.id_good AND tc_1.when = price.when ;
INTO CURSOR tc_2

Kādas domas? usver? rATRIJS?

Hmm, vai nevar vēl labāk?

[Autors]

Ieraksti