Onderwerp: Wat zegt dit over de webhoster?

Ik heb een php pagina waarin ik 2 zoekresultaten oproep van 2 databases. Database 1 heeft 2 tabellen met elk bijna een miljoen records (beide samen bijna twee milj), waaronder zinnen. Database 2 heeft ook 2 tabellen met evenveel data als db1, maar hier geen lange zinnen.
Elke database is niet groter dan 50 MB.

De zoekresultaten bestaan uit max zoveel regels (25), en er wordt maar in 1 tabel per database gezocht.

Nu laadt de pagina retetraag, en dus mijn vraag wat dit zegt over de webhoster van mijn shared account. Of zijn mijn databases gewoon veeeeel te zwaar voor een shared account.

Het ligt er helemaal aan hoe de structuur van je tabellen er uit ziet en wat voor query je er op los laat.
Als je bv een SELECT * from table where column1 = '%woord%' op een tabel met een miljoen records los laat,
kan ik me voorstellen dat dat wel eventjes duurt voordat je een antwoord krijgt.

Oorspronkelijk geplaatst door timvermaesen

Ik heb een php pagina waarin ik 2 zoekresultaten oproep van 2 databases. Database 1 heeft 2 tabellen met elk bijna een miljoen records (beide samen bijna twee milj), waaronder zinnen. Database 2 heeft ook 2 tabellen met evenveel data als db1, maar hier geen lange zinnen.
Elke database is niet groter dan 50 MB.

De zoekresultaten bestaan uit max zoveel regels (25), en er wordt maar in 1 tabel per database gezocht.

Nu laadt de pagina retetraag, en dus mijn vraag wat dit zegt over de webhoster van mijn shared account. Of zijn mijn databases gewoon veeeeel te zwaar voor een shared account.

Dit is zoals Marcellow aangeeft afhankelijk van de query, de type data, hoe de indexen gemaakt zijn, de cache van de hoster, etc etc etc.. Veel records zorgen er voor dat de server enorm traag kan worden en zoveel records icm complexe queries zijn veelal niet geschikt voor normale shared hosting omgevingen. Je kan ook zelf kijken of je cache in je applicatie kan programmeren, waardoor de resultaten maar één keer binnen de zoveel tijd opgehaald hoeft te worden.

Ik gebruik inderdaad zoiets:
SELECT * FROM tabel WHERE kolom LIKE '%blabla%' ORDER BY RAND() LIMIT 0

Is er dan een betere manier?

Oorspronkelijk geplaatst door timvermaesen

Ik gebruik inderdaad zoiets:
SELECT * FROM tabel WHERE kolom LIKE '%blabla%' ORDER BY RAND() LIMIT 0

Is er dan een betere manier?

Wat wil je precies bereiken/is het doel van het script?

Klopt het dat je dus een query als deze door 4 miljoen records heen gooit?

Oorspronkelijk geplaatst door Yourwebhoster

Wat wil je precies bereiken/is het doel van het script?

Klopt het dat je dus een query als deze door 4 miljoen records heen gooit?

De pagina bevat zoekresultaten. Een zoekopdracht resulteert dan in een zoektocht in de 2 databases.

En dat is wat ik dus gebruik om de data weer te geven.

Order by rand() is zóóóóóó fout... (en die limit 0 is een fout neem ik aan?)

Edit: ter info.

Een like '%blabla%' help je index gebruik al om zeep. Daarnaast is order by rand() een 100% performance killer. Mysql moet namelijk eerst je hele tabel scannen omdat je niet kunt indexeren op %blabla%. Daarnaast moet ie ook nog eens random een x aantal records selecteren uit je totale resultset.
Dit kun je niet afschuiven op je hoster maar is puur een programmeursfout.

Edit 2: resultsets zjn tijdelijke tabellen zónder index. Als ze in het ram passen is dat niet altijd zo heel erg, maar met een x mil. records gaat dat geheid naar schijf. Niet vooruit te branden dus.

Oorspronkelijk geplaatst door timvermaesen

De pagina bevat zoekresultaten. Een zoekopdracht resulteert dan in een zoektocht in de 2 databases.

En dat is wat ik dus gebruik om de data weer te geven.

En waarom dan RAND()?

En idd zoals Systemdeveloper aangeeft limit 0 is zeker een copy/paste foutje, daar was ik min of meer van uit gegaan.

Oorspronkelijk geplaatst door systemdeveloper

Order by rand() is zóóóóóó fout... (en die limit 0 is een fout neem ik aan?)

SELECT * FROM tabel WHERE kolom LIKE '%blabla%' ORDER BY RAND() LIMIT 0, en hier komt automatisch een getal als limiet van het aantal weer te geven resultaten

Ik ben die Order by rand() eens nader gaan bekijken en het schijnt inderdaad een extra belasting te geven. Erg bedankt om mij hierop te wijzen!

Jouw doel is alleen om het maximum aantal regels op te vragen, maar waarom vraag je dan de volledige tabel op in plaats van alleen het aantal regels? Staat in de code echt limit 0 of is dat als voorbeeld? In dat eerste geval heeft het geen zin om de resultaten in willekeurige volgorde weer te geven. In de select vraag je tevens alle kolommen op.

Oorspronkelijk geplaatst door timvermaesen

SELECT * FROM tabel WHERE kolom LIKE '%blabla%' ORDER BY RAND() LIMIT 0, en hier komt automatisch een getal als limiet van het aantal weer te geven resultaten

Ik ben die Order by rand() eens nader gaan bekijken en het schijnt inderdaad een extra belasting te geven. Erg bedankt om mij hierop te wijzen!

Dit omschrijven is trouwens geen makkelijke opgave. Wat je eigenlijk moet doen is een join maken met een fictieve tabel waarbij geen order by wordt gedaan, maar waarbij je on the fly de kans berekent dat een record wel/niet geselecteerd wordt. Voorbeelden kun je wel googlen en met wat aanpassingen werkend krijgen. Wij gebruiken het regelmatig voor tabellen met vele miljoenen records.
Het zijn en blijven echter hersenbrekertjes

Oorspronkelijk geplaatst door Stewie

Jouw doel is alleen om het maximum aantal regels op te vragen, maar waarom vraag je dan de volledige tabel op in plaats van alleen het aantal regels? Staat in de code echt limit 0 of is dat als voorbeeld? In dat eerste geval heeft het geen zin om de resultaten in willekeurige volgorde weer te geven. In de select vraag je tevens alle kolommen op.

Dat script gebruik ik al een hele tijd, en mijn doel is voor dat specifieke zoekopdracht maximum 25 regels weer te geven, en dit in random order.

SELECT * FROM 'mijn tabel' WHERE 'mijn kolom' LIKE '%$zoekopdracht%' LIMIT 0, 25 ...en met die BY RAND() zorg ik ervoor dat de weergegeven resultaten voor iedereen anders is, maar steeds relevant.

Nu heb ik gelezen dat die RAND() een probleem geeft voor grote databases, en dat er niet zo maar alternatieven voor handen zijn. Ik ben me hier nu in nog aan het verdiepen...

Oorspronkelijk geplaatst door timvermaesen

Dat script gebruik ik al een hele tijd, en mijn doel is voor dat specifieke zoekopdracht maximum 25 regels weer te geven, en dit in random order.

SELECT * FROM 'mijn tabel' WHERE 'mijn kolom' LIKE '%$zoekopdracht%' LIMIT 0, 25 ...en met die BY RAND() zorg ik ervoor dat de weergegeven resultaten voor iedereen anders is, maar steeds relevant.

Nu heb ik gelezen dat die RAND() een probleem geeft voor grote databases, en dat er niet zo maar alternatieven voor handen zijn. Ik ben me hier nu in nog aan het verdiepen...

Je eerste probleem is de like '%---

Door dat eerste % kan je index al niet meer gebruikt worden. Let wel.. het % op het einde is geen probleem.
Het beste kun je dit deel oplossen met een 'match against' en een fulltext index.
De rand() moet je oplossen zoals ik zei als je het goed wilt doen, maar uiteraard kun je je ook limiteren tot bv de laatste 10-20-30k records. Voor de user is dat meestal random genoeg.

als je perse random wil. kan je natuurlijk ook (in php) gaan voor iets als.

Code:

<?php
//even snel
$start=rand(0,1000000-25); // er vanuitgaand dat er precies 1000000 rijen zijn.
$sql="SELECT id FROM table WHERE col='bla' LIMIT ".$start.", 25";

Oorspronkelijk geplaatst door davinci

als je perse random wil. kan je natuurlijk ook (in php) gaan voor iets als.

Code:

<?php
//even snel
$start=rand(0,1000000-25); // er vanuitgaand dat er precies 1000000 rijen zijn.
$sql="SELECT id FROM table WHERE col='bla' LIMIT ".$start.", 25";

Nee, dat kan niet (om minimaal 2 redenen) maar ook daar zit je met het probleem dat de mysql resultset tot aan het $start moet worden weggegooid (aan de serverkant).