[MySQL] Optimalisatie

[Verwijderd]

Hoi. Voor een project worden er de hele dag door veel records opgeslagen, dat kan zo oplopen naar een paar honderduizend. Elk record heeft een veld status, op dit veld zal zeer regelmatig geselecteerd worden.

Misschien is het suf, maar ik vraag me nu af wat het efficientst is: voor elke status een aparte tabel maken (tabel pending, completed, denied) met verder elk dezelfde structuur, of gewoon alles in 1 tabel met een veld status en met goede indexes werken?

[whoami]

Waarom denk je dat het handig / onderhoudbaar / performant is om voor iedere status een aparte tabel te maken.

[Motrax]

Om wat voor statussen gaat het? Om wat voor data uberhaupt en wat is je huidige structuur?

[PeterSelie]

..nvm..

[ Voor 96% gewijzigd door PeterSelie op 22-04-2007 16:50 ]

[Verwijderd]

Waarom denk je dat het handig / onderhoudbaar / performant is om voor iedere status een aparte tabel te maken.

Over de eerste twee ga ik me niet uitspreken, maar performant: hangt er volgens mij heel hard vanaf. Een select doen zonder where clause, en dus maar op 1/3 van de records gaat toch sneller dan een select doen op het volle aantal records? Of komt dat achter de schermen op hetzelfde neer?
Ik denk dat de performance er vooral van afhangt hoe vaak die statussen veranderen... Want dat zijn telkens deletes en inserts natuurlijk...
In ieder geval, ik denk dat het met zo'n dingen meestal het beste is van gewoon is te testen, met een testsetje. Dan weet je het meteen. Ik besef wel dat dat niet altijd even gemakkelijk is

[Apen-nootjes]

Als je Mysql 5 gebruikt zou je views kunnen gebruiken, ik weet niet of dit performance winst oplevert maar je zou zeggen dat mysql een view zou moeten cachen

[Zerotorescue]

Verwijderd schreef op zondag 22 april 2007 @ 17:23:
Een select doen zonder where clause, en dus maar op 1/3 van de records gaat toch sneller dan een select doen op het volle aantal records? Of komt dat achter de schermen op hetzelfde neer?

Ligt eraan waar je database op staat... Heb je meerdere servers (web- & databaseserver minimaal) draaien, dan ligt het weer aan je servers... Wordt je databaseserver alleen gebruikt voor jou database & is die (redelijk) goed, dan zou ik slechts 1/3 ophalen. Heb je een (redelijk) slechte/slome database server of wordt hij door meerdere grote databasen veel gebruikt, terwijl je webvserver dit niet heeft dan zou ik je webserver laten filteren. Oja, als je een sloom netwerk hebt(of ook betaald voor de data die verstuurd wordt tussen data- en webserver), dan is het natuurlijk ook weer slimmer om minder data te versturen tussen de servers. Lopen ze allebei gelijk dan zou ik kiezen voor een WHERE omdat de kans op fouten dan kleiner is

Als je slechts 1 server hebt, dan zal het niet heel veel uitmaken. Als ik jou was zou ik dan een WHERE gebruiken omdat de kans op fouten ook dan kleiner is, en kwa snelheid dit ook logischer klinkt(behalve als de load van mysql heel hoog is terwijl apache dat niet is)

Edit:
Mijn antwoord op je vraag; ik zou 3 tabellen gebruiken omdat dit veel makkelijker is met abckups maken/gebruiken, want als er nl iets fout gaat dan is dit een kleiner(1/3 van normaal) probleem.

[ Voor 17% gewijzigd door Zerotorescue op 22-04-2007 18:01 ]

[brokenp]

Ik zou nooit 3 tabellen gebruiken. Databases zijn ervoor gemaakt om deze soort gegevens aan te kunnen. Het is qua onderhoudbaarheid veel eenvoudiger om 1 tabel te maken. Stel je voor dat er iets in de structuur van de tabel verandert, dan moet je dit 3x aanpassen.
Verder denk ik dat de performance vooral afhangt van de inserts en deletes, met 3 tabellen blijf je constant bezig om data van 1 tabel naar de andere te pompen, wat tijdsintensief is.

Als je database het niet bij kan houden, dan kan je imho de volgende 3 opties overwegen:
- Upgrade hardware
- Clusteren/replicatie etc
- ander DBMS

Ik zou eigenlijk nooit een tabelstructuur laten afhangen van de snelheid van de DB.

[BtM909]

Verwijderd schreef op zondag 22 april 2007 @ 17:23:
[...]

Over de eerste twee ga ik me niet uitspreken, [...]

Dus negeer je die maar in je beredenering

Overigens geef je eigenlijk het antwoord al, gewoon een goede genormaliseerde database structuur en door middel van tuning de juiste indexes zetten...

Je doet alleen je db structuur aanpassen aan je database omgeving in hele speciale gevallen

[Verwijderd]

@Whoami:
Nee, ik wil ze absoluut niet negeren! Ik ken er echt niet zoveel van, maar ik vond dat hij gewoon een interessant punt aanhaalde, en ik snapte niet echt waarom dat sowieso niet zou mogen. Ik weet wel dat onderhoudbaarheid superbelangrijk is, en mijn redenering was puur bedoeld op of het iets zou uitmaken qua performance, absoluut niet of hij het nu uiteindelijk het best zo doet of niet.
Ik hoop dat ik mezelf hier wat mee genuanceerd heb

[_js_]

Ga gewoon tellen wat het meest efficient is. Hoeveel selects doe je over de data, en zijn deze wel of niet gesorteerd/gefilterd op status, hoeveel inserts, hoeveel updates van de status? En hoe belangrijk zijn al deze zaken?

Als je alles in 1 tabel doet, dan moet per insert wat meer gelezen en geschreven worden voor de extra index.
En je hebt per select waar je wilt filteren op de status een extra read nodig op die index.

Als je het splitst in 3 tabellen heb je ipv een update op status een delete en een insert nodig.
Een select die niet gesorteerd of gefilterd is op status is veel meer moeite.

[TeasingU]

Vond het een interessant onderwerp en ben even gaan Googlen:

http://www.mysqlperforman...erformance-presentations/

Leek mij op het eerste gezicht wel interessant.

Succes!