[MySQL] Hoeveel data?

[DanceTrend]

Ik vroeg me eigenlijk af, hoe snel een MySQL tabel langzaam wordt, als er veel data instaat. Ik heb voor mn site bijv. een tabel 'votes', waarin info staat over een bepaalde vote . Voor elk iets waar gevote op moet worden staan er minstens 10 in. Op deze manier loopt deze tabel dus zeer snel vol. Mijn vraag is dus hoe lang ik dit vol kan houden / hoe lang het gaat duren dat ik ga merken dat mijn site ongelooflijk traag wordt?
Iemand idee?
Thx.

[whoami]

Als ik me niet vergis draait GoT op een MySQL databank.

[Janoz]

1 hint.. Alle topics, reacties, niewsberichten, notes, userdata van tweakers staat ook in een MySQL db.... Beantwoord dat je vraag?

[serieus mode]
Database systemen zijn als het goed is juist gemaakt om enorme hoeveelheden data op te slaan en efficient te kunnen reproduceren. Zolang je in je DB model + queries maar een beetje netjes houdt hoef je je daar geen zorgen over te maken.
[/serieus]

[ikke_]

Geen idee wanneer het echt langzaam wordt. Als je maar indexeert waarop je zoekt. Waarschijnlijk wil je alleen de votes bij een bepaalde vraag, dus indexeer het. Ik denk dat 10000 voor een database nog niet echt een ramp is.

[Rashann]

ikke_ schreef op 26 augustus 2002 @ 21:48:
Geen idee wanneer het echt langzaam wordt. Als je maar indexeert waarop je zoekt. Waarschijnlijk wil je alleen de votes bij een bepaalde vraag, dus indexeer het. Ik denk dat 10000 voor een database nog niet echt een ramp is.

Ik neem aan dat ieder topic een uniek nummer heft, en zo te zien zit GoT nu op zo'n 580.000 topics, en jouw bericht was bericht nummer 14919015.

10.000 is echt geen probleem (mits de datastructuur/indexen goed zijn)

[DanceTrend]

Ja ik zie maar goed GoT, dan noem je ook wat

Verder heeft elke waarde in die tabel en column met het id nummer van datgene waarop gevote is, ook geen byzondere queries ofzo... Gewoon

selet * from votes where id = $id

zeg maar.
Is dit een goede query of kan ik beter goed zoeken op GoT en kijken hoe het ingewikkeld kan?

[Rashann]

Gebruik niet *, maar pak de individuele kolomnamen, dan weet je altijd zeker wat je opgevraagd hebt, en haal je nooit teveel (overbodige) data uit de tabel...

En het probleem zit hem meestal ook niet in de selects, maar in de tabelopbouw en indexering (kijk de FAQ maar eens na)

[Edit]
Voorbeeldje:
ik had een website gemaakt waarin een tabel gebruikt werd die ongeveer 100.000 rijen had. Het opvragen hieruit ging echt verschrikkelijk langzaam omdat ik vergeten was te indexen (5-10 seconden wachten op een pagina). Na indexering komen de pagina's nu meteen op het scherm, dus het kan veel schelen

[ Voor 0% gewijzigd door Rashann op 26-08-2002 22:22 . Reden: zie edit ]

[gorgi_19]

Beter is misschien: (klein beetje performancewinst)..

code:

Select waarde FROM votes WHERE id = $id

[WouterG]

Ik weet helemaal niets van het werken met mysql of tabellen ofzo af maar toch een vraag:
Zou het niet mogelijk zijn om die tabellen weer in hapklare blokken op te delen. Dus bv. de vele topics van got in stukken van 10000 en die dan in aparte tabellen zetten en met php een scrippie schrijven dat 1t/m10000 uit tabel a moeten komen enz. Of is dat dom geredeneert en moet ik mn mond houden over zaken waar ik nix van weet?

[Verwijderd]

Tomcat schreef op 26 augustus 2002 @ 22:34:
Ik weet helemaal niets van het werken met mysql of tabellen ofzo af maar toch een vraag:
Zou het niet mogelijk zijn om die tabellen weer in hapklare blokken op te delen. Dus bv. de vele topics van got in stukken van 10000 en die dan in aparte tabellen zetten en met php een scrippie schrijven dat 1t/m10000 uit tabel a moeten komen enz. Of is dat dom geredeneert en moet ik mn mond houden over zaken waar ik nix van weet?

Als je de indexen goed maakt dan zorgt het databeest intern wel voor dit soort grappen. Verder is geheugen erg belangrijk, als de indexen in het geheugen staan dan is het ophalen van de data sneller dan het openen van bestand

[ACM]

Een %blaat% like search op de reacties van de frontpage van tweakers.net (stuk of 500000) gaat nog vrij vlot, maar is wel al seconden werk.

Een %blaat% like search op de messages-tabel van GoT is niet werkbaar meer (minuten werk), maar je ziet aan het laden van deze reactie dat de database vrij vlot met die 7GB om kan gaan...

Oftewel, zolang je niet "dom" tegen je data aanpraat dan maakt de grootte erg weinig uit.

[Verwijderd]

gorgi_19 schreef op 26 augustus 2002 @ 22:21:
Beter is misschien: (klein beetje performancewinst)..

code:

Select waarde FROM votes WHERE id = $id

Ook is dit beter om later je $content beter te kunnen beheren... als er later 'n kolom in de table is toegevoegd wordt ie met '*' ook meege-fetcht.

[ACM]

gorgi_19 schreef op 26 augustus 2002 @ 22:21:
Beter is misschien: (klein beetje performancewinst)..

code:

Select waarde FROM votes WHERE id = $id

Afhankelijk van het doel van je query kan dit zelfs grote performance winst opleveren, als je alleen maar de mensen die in een topic gereageerd hebben wilt weten (om het forum maar als voorbeeld te nemen) zal je met select * ook WAT ze gereageerd hebben meenemen, wat toch aardig in de kilo/megabytes kan lopen per query.

[DanceTrend]

Oke danku, ik was toch al van plan om mn code te checken op die dingen..
Dat van indexen snap ik nog niet helemaal maar ben al op zoek naar een duidelijk artikel.

[ACM]

DanceTrend schreef op 27 augustus 2002 @ 12:30:
Dat van indexen snap ik nog niet helemaal maar ben al op zoek naar een duidelijk artikel.

Zie de P&W-faq, staat wel een aardig stukje van MrX over indexeren in.

[DanceTrend]

Yup gezien Maar werd niet echt duidelijk gemaakt wat het precies is, maar dat weet ik ook inmiddels.
Kort samengevat is het toch gewoon bepaalde fields die he unique, primary, index maakt?

[ACM]

DanceTrend schreef op 27 augustus 2002 @ 13:05:
Kort samengevat is het toch gewoon bepaalde fields die he unique, primary, index maakt?

Euh nee... Dat zijn een paar halfbakken mysql-termen.

Index is puur en alleen een methode om snel toegang tot de data te krijgen.

Een unique index gebruiken dwingt je ertoe dat je unieke items in een column moet plaatsen.
Een primary key is DE identifier in een tabel en moet perse uniek zijn, dat er dbms-en zijn die dat met een unique-index oplossen is weer wat anders