[PHP/Apache] Data Query probleem ( performance e.d. )

[Basszje]

Goedemorgen.

Ik ben hier op mijn werk bezig met een systeem waarbij het absoluut relevant is dat er een enorme hoeveelheid data snel ge-queried kan worden met bepaalde filters. Ik zal het een en ander proberen te verduidelijken.

We noemen de set gegevens gewoon iets van "Responses" .

Responses

ID - Datum - Taal - Periode - Waarde - UserID

De uiteindelijk werking van een programma is dat je bijvoorbeeld van UserID xxx ( of een groep users ) met een bepaalde periodes waardes kan optellen, gemiddelden etc. Maar bv deze data ook afzetten tegen verschillende periodes, talen of groepen users.

De tabel kan uiteindelijk enkele honderduizenden records gaan bevatten.

Nu loop ik nu met de tradionele query methodiek een beetje op tegen het probleeem van excessieve laadtijd met het querien en opbouwen van alles.

Maar ook tegen het feit dat je bijna voor elke situatie een andere query moet bouwen. Wat de overzichtelijkheid niet ten goede komt.

Ik had het plan opgevat om in JAVA (oid ) een soort 'eigen' database-proxy server ( of hoe noem je dat ) te bouwen. Bijvoorbeeld een programmaatje wat aanroepbaar is in PHP dat bij het starten eenmalig alle gegevens uit de database trekt ( of delen cacht oid ) en waar je dan makkelijke records uit kan 'filteren' dmv diverse rules ( Ik denk hierbij een beetje aan bv de GUI van MS Access met filtering) .

Eerlijk gezegd heb ik geen idee waar ik moet beginnen met zoeken of of zoiets mogelijk is en de vraag hoe je het kan oplossen .

[whoami]

Honderdduizenden records? Dat valt wel nog redelijk mee. Heb je indexen op die tabel gelegd? Welk DBMS gebruik je trouwens?

Je kan eventueel ook een soort 'cache' object schrijven die reeds opgehaalde records in het geheugen houdt. (Dit kan wel resources vreten als het over zeer veel records gaat). Als je dan dus een record wilt ophalen, dan doe je dat via dat 'cache' object. Die gaat eerst kijken of hij dat record reeds in memory staan heeft. Heeft hij dat, dan hoeft het niet uit de DB gehaald te worden. Heeft hij dat nog niet, dan haalt hij het uit de databank en zet het in het geheugen.

[Verwijderd]

Dus als ik het goed begrijp duurt het te lang voordat je queries een resultaat laten zien?
En daarbij heb je ook nog eens zoveel queries dat het onoverzichtelijk wordt en moeilijk onderhoudbaar is?

Voor punt 1 zou je kunnen kiezen om iedere nacht een soort export te maken van de database, die alvast een deel van de gegeven klaarzet. Op die manier hoef je overdag alleen maar het resultaat uit die export op te halen, of eventueel nog enkele simpele queries uit te voeren. Als realtime-info niet superbelangrijk is, zou dit een oplossing kunnen zijn.
Ik heb ooit voor een klant een 'Dossier Generator' gemaakt in MS-Access. Deze pompt iedere nacht vanuit een supergrote database alle relevante info over. En met deze subset wordt overdag gewerkt. Het ideale is dat je gewoon de namen van de uit te voeren queries in een tabel zet, en de queries zelf op een bepaalde plek beschikbaar stelt, vervolgens regelt de Generator alles verder zelf.

Punt 2, die onoverzichtelijkheid... het bijhouden van goede documentatie over wat de queries doen, wordt dan heel belangrijk denk ik. Laatst had ik een systeem met meer dan 50 queries. Allemaal uitgeprint in Word, en een beschrijving erbij. Dat maakt het zoeken alvast een heel stuk makkelijker.

[Basszje]

De DBMS is Mysql . En de belangrijkste tabel staan idd indexen op bijna alles. Ook omdat bovengenoemde velden allemaal gewoon integers zijn .

Hum en zo'n Cache object. waar de hell vind ik daar meer informatie over ? Zijn dat soort dingen er b.v. voor PHP.

Zoals ik trouwens al zei ligggen de meeste problemen met de performance van het zutje, maar ook bij de dynamiek van het ophalen van de gegevens, omdat een berg berekeningen mogelijk moeten zijn.

[bartvb]

Eeh, wat dacht je van een nieuwe database server? Een tabel van dit formaat met een paar honderd duizend items mag niet veel problemen opleveren al helemaal niet als je fatsoenlijk gebruik maakt van indices en LIMIT...

[Basszje]

bartvb schreef op 03 februari 2003 @ 10:05:
Eeh, wat dacht je van een nieuwe database server? Een tabel van dit formaat met een paar honderd duizend items mag niet veel problemen opleveren al helemaal niet als je fatsoenlijk gebruik maakt van indices en LIMIT...

Als je mijn verhaal had gelezen had je geweten dat limit geen optie is .


En op de punten van IntroV.

De data moet helaas wel redelijk realtime op het scherm verschijnen . Het 's nachts cachen en opbouwen van het e.e.a. is niet echt een optie.

Ik probeer trouwens juist het gebruik van veel verschillende query's te voorkomen. Het verschil tussen een SUM en een AVG query is weliswaar minimaal ( en ga ik dus ook echt niet twee keer opgeschrijven, maar doe je gewoon met een if statement ) , maar het is toch lastig als je veel variaties hebt ivm performance en overzichtelijkheid van het scripts. Het is n.l. nog erg waarschijnlijk dat er meer functies nog bijmoeten.

[whoami]

Basszje schreef op 03 februari 2003 @ 10:17:
[...]


Ik probeer trouwens juist het gebruik van veel verschillende query's te voorkomen. Het verschil tussen een SUM en een AVG query is weliswaar minimaal ( en ga ik dus ook echt niet twee keer opgeschrijven, maar doe je gewoon met een if statement ) , maar het is toch lastig als je veel variaties hebt ivm performance en overzichtelijkheid van het scripts. Het is n.l. nog erg waarschijnlijk dat er meer functies nog bijmoeten.

Het verschil is minimaal, maar het komt de duidelijkheid toch niet ten goede.
Verder denk ik ook dat het dynamisch opbouwen van een sql-statement ook een vertragende factor zal zijn. Strings zijn nl. immutable, wat dus wil zeggen dat, iedere keer je een andere string aan een string toevoegt, er een nieuw string object moet gecreeërd worden.
Jammer dat MySQL geen stored procedures ondersteunt, anders kan je alle queries in stored procedures onderbrengen.

Zo'n cache/dictionary object zal je trouwens zelf moeten schrijven, maar da's zo lastig niet.

[ Voor 5% gewijzigd door whoami op 03-02-2003 10:20 ]

[bartvb]

Eeh, waar staat dan dat LIMIT geen optie is

Anyway, waar zit je probleem? Heb je al wat getest? Wat voor een tijden hebben we het over? Hoeveel selects/updates/inserts per tijdseenheid? Hoe groot is de data die je bekijkt? Zijn dat tabelletjes van 10 rows of lijsten van 100en rows?