[PHP/MySQL] Waardes in session cachen of uit DB halen *

[Verwijderd]

Ik vraag me af wat qua prestaties/snelheid het beste is.

Ik heb een database met (250.000) foto's van auto's en iedere foto is gekoppeld aan een merk, model en evt. type

nu heb ik dus ong. de volgende tables:

table: car_pics

pic_id	foto	make	model	type
1	volkswagen_golf.jpg	3	2
2	opel_zafira.jpg	1	1
3	audi_a4.jpg	2	3

table: car_makes

make_id	make_name
1	opel
2	audi
3	volkswagen

table: car_models

model_id	make_id	model_name
1	1	zafira
2	3	golf
3	2	a4

table: car_types (bijna idem als car_models)

nu mijn vraag:

ik bewaar momenteel alle car_makes, car_models en car_types in een sessie array.
Zodra een nieuwe sessie wordt geopend doe ik namelijk het volgende:

PHP:

$q = mysql_query("SELECT * FROM car_makes ORDER BY make_name ASC");
    while($r = mysql_fetch_assoc($q)){
        $_makes[$r['uin']] = $r['naam'];
    }
$_SESSION['makes'] = $_makes;
// en dan het bovenstaand ook voor models en types.

zodat ik die dus niet telkens opnieuw uit de database hoef te halen, maar gewoon dmv
$_SESSION['makes'][$make_id] kan aanroepen. (want geloof me ik moet die namen heeeeel vaak uit de database halen)

is dit slim? of kan ik beter gewoon telkens opnieuw dmv left joins ook meteen de make_naam en model en type uit de database halen.

dus bijv:

code:

//
SELECT p.*,m.make_name as make,m2.model_name as model,t.type_name as type FROM pics p LEFT JOIN car_makes m ON m.make_id=p.make LEFT JOIN car_models  m2 ON m2.model_id=p.model LEFT JOIN car_types t ON t.type_id=p.type WHERE p.pic_id=$_GET['id'] LIMIT 1
//

graag jullie opinie...

btw. het zijn
59 makes/merken
585 modellen
0 types (maar dat worden er ook wel minimaal 1000 denk ik)

[CodeCaster]

Bouw zelf eens een twee testscriptjes waarmee je de pagina 10.000 keer opvraagt met sessievariabelen en 10.000 keer met joins, en vergelijk de tijden?

[Verwijderd]

CodeCaster schreef op woensdag 23 mei 2007 @ 01:23:
Bouw zelf eens een twee testscriptjes waarmee je de pagina 10.000 keer opvraagt met sessievariabelen en 10.000 keer met joins, en vergelijk de tijden?

ik denk dat de sessies in dat geval wel sneller zijn, maar wat als er nou 1000 users tegelijk op de site zijn, dan zijn er dus 1000 sessies waar al die data in bewaard moet worden en mss kost dat weer teveel diskspace in de /tmp/ dir oid?

het gaat mij dus meer om het feit dat je straks dus een x aantal sessies open hebt staan, en of het dan niet slimmer is om het toch maar wel uit de db te halen ipv in sessies te bewaren.

[CodeCaster]

Ik gok sowieso dat de MySQL caching sneller is dan jouw sessie-caching, maar dit is vast wel op een of andere manier te benchmarken (ook voor meerdere bezoekers tegelijkertijd).

Ik zou zo 1-2-3 alleen geen testtool weten, helaas.

[Voutloos]

Tja, als je met zo'n vraag zit, moet je het eerst zelf proberen te testen. Maar imo moet je uberhaupt niet met deze vraag zitten.
Deze tabellen joinen zal echt niet voor een performance probleem gaan zorgen. Join die handel, los je dataprobleem in de db op en houd daarmee je code overzichtelijker en minder foutgevoelig.

En denk als je gewoon gaat joinen nog eens na over de car_pics.make kolom, want die is redundant.

[Janoz]

Snelheden zijn natuurlijk leuk en aardig, maar je ziet een ander punt compleet over het hoofd. Elke keer wanneer een bezoeker op de site komt wordt dat lijstje aangemaakt en dit lijstje blijft minimaal 20 minuten (of wat de session life time ook is) bestaan. Dit wordt ook nog eens voor elke bezoeker gedaan. Zou je binnen 20 minuten bijvoorbeeld 100 bezoekers hebben dan wordt er 100 keer de volledige sessie weggeschreven in je tmp dir.

Waar het ig op neer komt is dat je geheugen en schijf gebruik enorm omhoog zullen gaan. Het cachen in geheugen zou nut gehad hebben wanneer php een application scope had gehad. Nu is het waarschijnlijk handiger om het cahcen aan mysql over te laten (ze zullen daar vast wel iets in hebben waarbij veel opgevraagde gegevens in het geheugen gehouden worden. Dat is dan alvast sneller dan een sessie omdat een sessie eerst nog van schijf ingelezen moet worden)

[Voutloos]

Ook leuk: tijdens de session lifetime van user A wordt een nieuwe foto geupload door B, van een nog niet eerder bekende make of model. Als A nu die foto bekijkt, gaat er iets heel hard fout. Dit is op te lossen door dingen te invalideren bij updates/inserts, of door last changed timestamps te vergelijken en anders de sessie vars opnieuw in te stellen, maar dat zijn dus allemaal stomme workarounds voor een probleem waar je anders helemaal geen last van had.

Dit voorbeeld valt in de categorie 'standaard caching problemen' en hier moet je gewoon direct aan denken zodra het woord caching valt.

[ Voor 13% gewijzigd door Voutloos op 23-05-2007 09:30 ]

[voodooless]

Zie ik het nu goed dat iedere sessie de zelfde info bevat Zoja: doodzonde! Heeft php geen globale webapp omvattende scope waar je dit soort dingen in kan stoppen? Zo kun je alles users vanuit de zelfde data serveren en gewoon netjes als er een aanpassing in de db is je lijstje updated.

[Verwijderd]

voodooless schreef op woensdag 23 mei 2007 @ 10:15:
Heeft php geen globale webapp omvattende scope waar je dit soort dingen in kan stoppen?

Janoz schreef op woensdag 23 mei 2007 @ 09:04:
Het cachen in geheugen zou nut gehad hebben wanneer php een application scope had gehad. Nu is het waarschijnlijk handiger om het cahcen aan mysql over te laten

[voodooless]

Verwijderd schreef op woensdag 23 mei 2007 @ 10:22:

Het wordt maar weer eens pijnlijk duidelijk waarom we hier op het werk PHP "Prutsers Home Page" noemen

Vergeet ook niet dat een beetje SQL engine ook een nette cache heeft. Het vaak opvragen van de zelfde dingen is daarom niet noodzakelijk al te traag.

[ Voor 25% gewijzigd door voodooless op 23-05-2007 10:30 ]

[Icelus]

Niet in een sessie opslaan; uit database halen.
Waarom wil je per se alle gegevens uitlezen? Kun je niet alleen de gegevens ophalen die op dat moment voor de gebruiker van toepassing/interessant zijn?

Application scope is via een ‘kleine omweg’ wel te bereiken maar is wel omslachtig:
Application scope in PHP

[ Voor 33% gewijzigd door Icelus op 23-05-2007 10:34 ]

[Voutloos]

voodooless schreef op woensdag 23 mei 2007 @ 10:24:
Vergeet ook niet dat een beetje SQL engine ook een nette cache heeft. Het vaak opvragen van de zelfde dingen is daarom niet noodzakelijk al te traag.

Daarom dus. Ik snap dat het leuk is om data zo dichtbij mogelijk te hebben, maar met de eenvoudige query uit de topicstart neigt het wel naar premature optimization om daar veel tijd in te steken. Als performance in het gedring is (cq. vastgesteld is dat dit dé bottleneck is) kan je alsnog je best doen om data beter op de frontends te bewaren.

[ReverendBizarre]

Databases zijn niet vies. Gebruik ze gewoon waarvoor ze bedoeld zijn.

[Verwijderd]

Janoz schreef op woensdag 23 mei 2007 @ 09:04:
Snelheden zijn natuurlijk leuk en aardig, maar je ziet een ander punt compleet over het hoofd. Elke keer wanneer een bezoeker op de site komt wordt dat lijstje aangemaakt en dit lijstje blijft minimaal 20 minuten (of wat de session life time ook is) bestaan. Dit wordt ook nog eens voor elke bezoeker gedaan. Zou je binnen 20 minuten bijvoorbeeld 100 bezoekers hebben dan wordt er 100 keer de volledige sessie weggeschreven in je tmp dir.

Waar het ig op neer komt is dat je geheugen en schijf gebruik enorm omhoog zullen gaan. Het cachen in geheugen zou nut gehad hebben wanneer php een application scope had gehad. Nu is het waarschijnlijk handiger om het cahcen aan mysql over te laten (ze zullen daar vast wel iets in hebben waarbij veel opgevraagde gegevens in het geheugen gehouden worden. Dat is dan alvast sneller dan een sessie omdat een sessie eerst nog van schijf ingelezen moet worden)

ja daar was/ben ik dus ook bang voor...

Voutloos schreef op woensdag 23 mei 2007 @ 09:29:
Ook leuk: tijdens de session lifetime van user A wordt een nieuwe foto geupload door B, van een nog niet eerder bekende make of model. Als A nu die foto bekijkt, gaat er iets heel hard fout. Dit is op te lossen door dingen te invalideren bij updates/inserts, of door last changed timestamps te vergelijken en anders de sessie vars opnieuw in te stellen, maar dat zijn dus allemaal stomme workarounds voor een probleem waar je anders helemaal geen last van had.

idd 1 van de problemen waar ik tegenaan loop.

[Verwijderd]

Voutloos schreef op woensdag 23 mei 2007 @ 08:34:
En denk als je gewoon gaat joinen nog eens na over de car_pics.make kolom, want die is redundant.

ow? leg uit...

[Verwijderd]

ik denk dat je het beste gewoon een klein test scriptje kunt scrhijven en kijken wat sneller is.

of, je schijf een custom session.handler die de informatie maar 1 keer opslaat en automatisch toevoegt aan elke sessie, aangezien je veel controle hebt over wat er wel in niet wordt opgeslagen en zelfs waar het wordt opgeslagen kun je met een custom session.handler veel bereiken mocht mysql caching inderdaad significant langzamer zijn wat zelfs ik zo nog niet dufr te zeggen aangezien je ook mysql hiervoor nog behoorlijk kunt tweaken.

een andere initiafief is een aparte ramdisk te maken op je linux bak en daar je session.dir op te zetten. je belast dan in iedergeval je hdd niet en het zou net zo snel kunnen zijn als een ram cache maar dan moet je wel weer controle over die bak hebben wat natuurlijk niet zo hoeft te zijn. je kunt er in iedergeval niet vanuit gaan dat je altijd een ramdisk tot je beschikking hebt.

een manier om te testen hoeveel load je nou werkelijk krijgt is met de apachebench tool. die standaar met apache wordt meegevelerd. hiermee kun je duizenden request genereren naar je apache webserver of elke webserver eigenlijk en daarmee dus ook je script duizenden keren aanroepen per minuut. je kunt dan zien wat de average response time is en hoe snel je /tmp uitpuilt van de verschillende sessies.

kortom, hier zijn een aantal dingen die je kunt doen. ik zou beginnen met testen wat nou werkelijk sneller is want als mysql caching sneller of niet onacceptabel langzamer is heeft dat toch altijd de voorkeur omdat je je dan niet drukt hoeft te maken over caching en dat gewoon aan mysql overlaat.

[Morax]

Waarom dump je niet alle waardes van car_makes in een tekstfile, en laat je die bij elke pageview inlezen, en die file gewoon updaten als de tabel gewijzigd word.

Ligt er natuurlijk wel aan hoe vaak die tabel ge-update word, maar als dat niet vaak is, lijkt het mij iig een goede mogelijkheid

[RobIII]

Morax schreef op donderdag 24 mei 2007 @ 01:16:
Waarom dump je niet alle waardes van car_makes in een tekstfile, en laat je die bij elke pageview inlezen, en die file gewoon updaten als de tabel gewijzigd word.

En dat is sneller

[voodooless]

Misschien op een ramdisk Normaal gezien kun je echter moeilijk sneller zijn dan een goede db.

Maar volgens mij is een vraag nog niet beantwoord: waarom zijn die gegevens bij ieder request nodig?

[TheBorg]

RobIII schreef op donderdag 24 mei 2007 @ 01:25:
[...]

En dat is sneller

Zal met PHP geen drol uitmaken, in het ene geval komt de data uit de file cache, in het andere geval uit de result cache. In C++ kan een tekstfile wel een stuk sneller zijn.

Ik zou het gewoon bij SQL laten, dit is echt geen ingewikkelde query en het zijn maar een paar rijen.

[RobIII]

TheBorg schreef op donderdag 24 mei 2007 @ 01:36:
[...]

Zal met PHP geen drol uitmaken, in het ene geval komt de data uit de file cache, in het andere geval uit de result cache.

Een aantal randvoorwaarden daargelaten wel ja

TheBorg schreef op donderdag 24 mei 2007 @ 01:36:
In C++ kan een tekstfile wel een stuk sneller zijn.

Want dan komt het niet meer uit de cache omdat het C++ is?

TheBorg schreef op donderdag 24 mei 2007 @ 01:36:
Ik zou het gewoon bij SQL laten, dit is echt geen ingewikkelde query en het zijn maar een paar rijen.

My point exactly.

[TheBorg]

RobIII schreef op donderdag 24 mei 2007 @ 01:39:
Want dan komt het niet meer uit de cache omdat het C++ is?

Meer de traagheid van PHP t.o.v. MySQL. Bij C++ merk je pas dat er een laag tussenuit valt.

-edit-
Er zitten wel nogal wat haken en ogen aan. Een klein sessie bestandje is al gauw een factor 2 tot 5 keer sneller dan een MySQL query. Nou weet ik niet hoe snel de serialize/unserialize functie van PHP is, maar bij grote sessie bestanden zou het weer geheel anders uit kunnen vallen. Ook kan PHP de sessie data in memory opslaan (al is dat niet aan te raden met veel data). Stel dat je ze wel op disk opslaat, en een bezoeker refreshed zijn pagina na een paar minuten dan kan de data uit de disk cache verdewenen zijn. In de cache van MySQL staat de result waarschijnlijk nog wel klaar omdat deze cache wordt 'gedeeld' door alle bezoekers. Wat real-life het snelste is vind ik moeilijk te zeggen, ik zou gewoon voor de makkelijkste methode gaan (MySQL query).

[ Voor 59% gewijzigd door TheBorg op 24-05-2007 02:30 ]

[Voutloos]

Verwijderd schreef op woensdag 23 mei 2007 @ 23:40:
[...]
ow? leg uit...

Aangenomen dat modelnummers uniek zijn: bij de car_models tabel staat al een make kolom, dus kan je de make die bij een foto hoort op die manier achterhalen. Maar goed, denk daar dus over na.

En doe het gewoon met een db.

Morax schreef op donderdag 24 mei 2007 @ 01:16:
Waarom dump je niet alle waardes van car_makes in een tekstfile, en laat je die bij elke pageview inlezen, en die file gewoon updaten als de tabel gewijzigd word.

Ligt er natuurlijk wel aan hoe vaak die tabel ge-update word, maar als dat niet vaak is, lijkt het mij iig een goede mogelijkheid

Schaf dan die hele db af, en voeg als er een foto toegevoegd wordt gewoon voor zover nodig regels toe aan de relevante tekstfiles.
Nofi, maar ik kan er gewoon echt niet bij dat dit 'een goede mogelijkheid' is als nog niet eens bewezen is dat dit de bottleneck is. Deze db zoals hier voorgesteld stelt absoluut niets voor: 250k rows met 2/3 kleine efficiente lookup tabelletjes is echt niets. Als je een query schrijft welke > 0.1 seconde duurt zou je je eigenlijk al rot moeten schamen.
Maar goed, naast performance ben ik het dus niet eens met het 'file gewoon updaten' deel. Dat is een probleem dat je anders helemaal niet zou hebben. Uiteraard is het opnieuw schrijven van zo'n bestandje geen rocket science, maar het is wel extra werk, met extra kans op fouten. Keep it simple.

[Gwaihir]

Janoz schreef op woensdag 23 mei 2007 @ 09:04:
Waar het ig op neer komt is dat je geheugen en schijf gebruik enorm omhoog zullen gaan. Het cachen in geheugen zou nut gehad hebben wanneer php een application scope had gehad. Nu is het waarschijnlijk handiger om het cahcen aan mysql over te laten (ze zullen daar vast wel iets in hebben waarbij veel opgevraagde gegevens in het geheugen gehouden worden. Dat is dan alvast sneller dan een sessie omdat een sessie eerst nog van schijf ingelezen moet worden)

voodooless schreef op woensdag 23 mei 2007 @ 10:24:
Het wordt maar weer eens pijnlijk duidelijk waarom we hier op het werk PHP "Prutsers Home Page" noemen

Zijn er andere driestuiver hosting oplossingen die je wel zo'n application scope in het geheugen laten cachen? In een shared hosting omgeving - je default PHP-capable hosting accountje - wil de hoster helemaal niet dat al die kleine sitejes programmatuur draaien die permanent stukken werkgeheugen staat te claimen. Voor een server met veel kleinere sites met elk een relatief klein deel van de totale traffic is dat gewoon niet zinnig (verspilling van resources).

Is je site wat groter en wordt het daarmee om performance redenen wel wenselijk, dan is het ook met PHP geen enkel probleem. Bijvoorbeeld: even APC installeren en klaar is kees.

Kortom: het verwijt betreft niet de taal, maar de randvoorwaarden waarbinnen (hier) gewerkt wordt.

[Janoz]

Sorry, maar de functionaliteit die je met allerlei omwegen php nog ingejast krijgt zijn niet vergelijkbaar met de mogelijkheden die je op dit vlak met ASP(?) .NET en J2EE hebt. De manier waarop het platform (niet perse de taal) opgezet is, belemert een fatsoenlijke implementatie. Het is het platform dus wel degelijk te verwijten.

[voodooless]

Birdie schreef op donderdag 24 mei 2007 @ 12:25:
Kortom: het verwijt betreft niet de taal, maar de randvoorwaarden waarbinnen (hier) gewerkt wordt.

Het feit dat er niet aan randvoorwaarden voldaan kan worden kun je wel degelijk een taal/platform verwijten natuurlijk. In dit geval zie ik echter niet echt een probleem, want randvoorwaarden moeten wel kloppen natuurlijk, anders heb je er niets aan.

Je hebt het over "driestuiver hosting oplossingen", kleine sites en dat soort dingen. Daar werkt php prima voor. Voor grotere en/of complexere oplossing zijn echter andere platformen vaak veel beter uitgerust zoal Janoz al terecht opmerkt. 't is maar net wat je nodig hebt.

[BikkelZ]

Volgens mij is MySQL ontzettend snel bij simpele JOINS (die je onder 3.x schreef als WHERE key = foreign_key), dat de performance winst wel eens zou kunnen liggen in de JOIN manier in plaats van wat jij denkt.

[BikkelZ]

voodooless schreef op woensdag 23 mei 2007 @ 10:24:
[...]


Het wordt maar weer eens pijnlijk duidelijk waarom we hier op het werk PHP "Prutsers Home Page" noemen

Vergeet ook niet dat een beetje SQL engine ook een nette cache heeft. Het vaak opvragen van de zelfde dingen is daarom niet noodzakelijk al te traag.

Hmm. Als je voor dit soort doeleinden Java & co aan het overwegen bent is dat waarschijnlijk meer omdat je in de prutser-ontkenningsfase zit en persé iets wil gebruiken wat 'professioneel' is

Het is een website met plaatjes van auto's, for christ sake

[Gwaihir]

voodooless schreef op donderdag 24 mei 2007 @ 15:03:
Je hebt het over "driestuiver hosting oplossingen", kleine sites en dat soort dingen. Daar werkt php prima voor. Voor grotere en/of complexere oplossing zijn echter andere platformen vaak veel beter uitgerust zoal Janoz al terecht opmerkt. 't is maar net wat je nodig hebt.

Tja; waar heb jij het dan over? Ik heb bij het lezen van dit draadje niet de indruk gekregen dat het over de nieuwe site van Autoweek (o.i.d.) gaat.

Daarnaast is juist Java berucht vanwege de moeite die de deployment kost, omdat er zoveel componenten, libraries, etc. bij elkaar te trekken en in te stellen zijn. Daarbij vergeleken stelt het enkele commando pecl install apc niet echt veel voor. (En bij PHP6 zal het zelfs standaard meegeleverd worden.)

[voodooless]

Birdie schreef op donderdag 24 mei 2007 @ 20:18:
Tja; waar heb jij het dan over? Ik heb bij het lezen van dit draadje niet de indruk gekregen dat het over de nieuwe site van Autoweek (o.i.d.) gaat.

Precies Ik zeg ook niet dat je nooit php moet gebruiken. Blijkbaar is mijn opmerking nogal provocerend opgevat 't was toch echt meer een grap.

Daarnaast is juist Java berucht vanwege de moeite die de deployment kost, omdat er zoveel componenten, libraries, etc. bij elkaar te trekken en in te stellen zijn. Daarbij vergeleken stelt het enkele commando pecl install apc niet echt veel voor. (En bij PHP6 zal het zelfs standaard meegeleverd worden.)

Tja, dat vind ik wel een beetje makkelijk gezegd. Al die dingen zijn echter wel voor het merendeel dingen die je met php nooit of moeilijk voor elkaar zou krijgen. En iets als APC kun je niet vergelijken met al die componenten en libs, en in java heb je zoiets sowieso niet nodig. Dus de vergelijking is niet eerlijk.

Back on topic: we weten nog steeds niet waarom/of dat hele lijstje wel voor ieder request nodig is...

[Verwijderd]

voodooless schreef op donderdag 24 mei 2007 @ 20:49:
[...]

Back on topic: we weten nog steeds niet waarom/of dat hele lijstje wel voor ieder request nodig is...

de makes,models en types zijn op vrijwel iedere pagina (meerdere malen) nodig... de query die ik in de eerste post heb geplaatst is nog de meest simpele query die ik nodig zou hebben voor het ophalen van de make,model,type uit de DB ipv uit de sessie.

hieronder een iets uitgebreidere query die nodig zou zijn, er zijn nog wel meer gevallen waar een nog uitbreidere query nodig is, maar heb geen zin om dat ff on the fly te typen... er zijn iig dus query's met al een stuk of 4 of 5 joins, als die types e.d. dus ook uit de database moeten komen, komen er dus standaard 3 joins bij.

code:

//query met makes e.d. niet uit db (maar uit sessie)...
SELECT SQL_CALC_FOUND_ROWS 
    p.uin,p.file,p.cat,p.sub,
    p.type,p.msgs,p.views,p.votes,
    byear,favorited,SUM(s.views) AS periodscore,
    SUM(s.favorited) AS favorited 
    FROM pics p 
    LEFT JOIN stats_history s ON s.id=p.uin 
    LEFT JOIN stats_history s2 ON s.id=p.uin 
    WHERE screened!=2 
    AND cat!=20 
    AND (byear>=1999 AND byear<=2003) 
    AND s.soort='downloads' 
    AND s.cmd='pic' 
    AND s2.soort='favorited' 
    AND s.cmd='pic' 
    GROUP BY s.id,s2.id ORDER BY periodscore DESC LIMIT 24


//met de makes uit de database
SELECT SQL_CALC_FOUND_ROWS 
    p.uin,p.file,p.cat,p.sub,p.type,
    p.msgs,p.views,p.votes,byear,
    favorited,m.make_name as make,
    m2.model_name as model,t.type_name as type,
    SUM(s.views) AS periodscore,SUM(s.favorited) AS favorited 
    FROM pics p 
    LEFT JOIN stats_history s ON s.id=p.uin 
    LEFT JOIN stats_history s2 ON s.id=p.uin 
    LEFT JOIN car_makes m ON m.make_id=p.make 
    LEFT JOIN car_models  m2 ON m2.model_id=p.model 
    LEFT JOIN car_types t ON t.type_id=p.type
    WHERE screened!=2 
    AND cat!=20 
    AND (byear>=1999 AND byear<=2003) 
    AND s.soort='downloads' 
    AND s.cmd='pic' 
    AND s2.soort='favorited' 
    AND s.cmd='pic' 
    GROUP BY s.id,s2.id 
    ORDER BY periodscore DESC LIMIT 24

sowieso zijn er pagina's waar er in bijv. 5 verschillende query's zijn die die makes,types nodig hebben... dat scheelt dus voor 5 query's zo'n 3 joins per query... dan is de sessie oplossing wel beter denk ik?

[ Voor 4% gewijzigd door Verwijderd op 24-05-2007 22:04 ]

[BikkelZ]

Ja maar als jij die types in een query verwerkt als

SQL:

....AND make_id IN (1, 2, 4, 6, ... 221, 223)

dan kost dat de DB engine misschien wel meer moeite om te verwerken dan een hele simpele join. Met indexen op de juiste plekken mogen die JOINs niet zo veel kosten.

Of snap ik gewoon niet wat je bedoelt?

En als je nou echt persé data snel bij de hand wil hebben, kun je misschien nog beter een data_include.php achtig bestandje maken, welke je aanpast op het moment dat je een merk of model aanpast / toevoegt / verwijdert. Je wil je data toch eigenlijk alleen hebben op het moment dat je die pagina bouwt en tussendoor heb je het niet nodig.

[kmf]

Je hebt meerdere manieren om dit te doen, maar er is niet 1 manier dat altijd goed gaat.
Alles hangt af van de situatie. Heb je een aparte DB en webserver, hoeveel bezoekers heb je, hoeveel noodzakelijke queries heb je nog meer, wat zijn de select/update/delete-queries verhouding, welke tabeltype gebruik je, hoeveel geheugen heb je voor je DB, wat voor configuratie heb je voor de rest etc, etc.

Een aantal opties:
als de car_types en car_models nagenoeg nooit veranderen, dan kan je overwegen om een cache-db tabel te maken waar je de arrays voor car_types, car_models, etc serialized in kan gooien.
Dan kan je met 1 query (select * from cache?) en 1 unserialize al je benodigde data krijgen. Dat scheelt je onnodige connecties maken, zoek, joins en sortacties, arrays aanmaken, toekennen, parsen etc.
Enkel bij een nieuwe update/insert moet je wel recachen.

Zelfs als je niet een volledige "dump" van een queryresultaat wilt bewaren, kan je dit nog doen voor een row van resultaten. Scheelt enorm in parsetime.

Je kan ook e-accelearor, xcache of whatever installeren en dan gebruiken van de shared-memory cache van deze dingen gebruiken om je array in te proppen.

[ Voor 7% gewijzigd door kmf op 24-05-2007 22:35 ]

[Voutloos]

Even serieus: Doe nou aub die oogkleppen af en kijk nou wat écht zwaar is aan die queries.

Een join met een lousy lookup tabelletje maakt de query die je nu geeft dus totaal niet zwaarder. De queryies die er nu staan zijn wellicht zwaar omdat je in een grote log tabel zit te wroeten incl. SQL_CALC_FOUND_ROWS en een ORDER BY op een dynamisch veld (periodscore). Dát kan performance kosten, die suffe make, model en type tabellen doen er niet toe.

Ik heb al vaker gezegd dat je moet aangeven waarom je vermoed dat die make / model tabelletjes de bottleneck zouden zijn en daar ga je maar niet op in. Maar met deze query durf ik dus te zeggen (te herhalen ) dat een join op die make / model tabelletjes helemaal niet zo problematisch is.

[DexterDee]

Even een frisse invalshoek op dit topic. Je kunt in MySQL ook gebruik maken van MEMORY tabellen. De data in deze tabellen bestaat alleen tijdens de levensduur van de MySQL server en gaat verloren als MySQL opnieuw wordt gestart. Voor kleinere hoeveelheden data kan dit ten opzichte van de reguliere MyISAM of InnoDB querycache een fraaie performancewinst opleveren, vooral bij een groot aantal queries die nét te verschillend van elkaar zijn om goed gecached te worden. Een simpel mechanisme om de inhoud van deze tabel te vullen en te (in)valideren is wel vereist. Het is een beetje een fancy versie van het 'text file op ramdisk' idee zoals hierboven is vermeld.

[Pascal Saul]

Ik zit zelf met een soortgelijk probleem. Ik heb ook een redelijke database met 250K records waar ik van sommige tabellen lijsten nodig heb voor in een combobox waarmee resultaten gefilterd kunnen worden.

Op mijn huidige manier doe ik telkens een select op drie tabellen voor de lijsten zonder joins. Ik merk gewoon dat het weergeven van de data traag wordt.

Aangezien de lijsten toch semi-statisch zijn dacht ik er aan om bij een database update deze array's in een file op te slaan die ik kan includen. De resultaten met behulp van de combobox blijft dan nog dynamisch maar de data voor de combobox niet.

De drie lijsten hebben nemen in een sessie 20MB in beslag... niet echt goed voor de performance

[ Voor 7% gewijzigd door Pascal Saul op 29-05-2007 11:54 ]