[MYSQL] 150 kolommen of 2 kolommen?

[Anoniem: 25556]

Anoniem: 97422 schreef op 21 juni 2004 @ 19:08:
---------------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) langzamer is dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.
---------------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)
?

Volgens mij klopt je vraag niet. Als ik het goed begrijp heb je 150 velden die je allemaal nodig hebt, niet 150 records.

Ik zeg niet dat het perse sneller moet zijn, maar zie geen redenen waarom het langzamer zou moeten zijn. Hoe je je data ook ordent, je server moet evenveel bitjes bij elkaar sprokkelen en versturen, je wil immers alle data hebben. De verpakking is dan niet al te relevant, zolang je er geen redundantie inbouwt.

Kort gezegd.. of de database nou

code:

|1|hezik|blaat|1-2-2003|

of

code:

|1;hezik;blaat;1-2-2003|

als resultatenset verstuurt maakt weinig uit. Bij voldoende records is de overhead van de metagegevens te verwaarlozen imo.

De grootte van de resultatenset blijft dus ongeveer gelijk.

Ik weet niet hoe groot je veld met 150 kolommen erin is; maar controleer ook eens hoe mysql de zaken fysiek opslaat. Het zou me niets verbazen dat het ophalen van één fat-assed 'string' uit een DB langer duurt dan 150 'normale'.

Ik zal het heel simpel proberen uit te leggen waarom DRM's optie sneller kan zijn:

Je hebt 10 gelijke ladingen welke je bij 10 klanten moet bezorgen. Je magazijn heeft zo'n deur:

code:

|----|
|    |-----------------------------------------------------|
|                                                          |  
|                                                          |
|----------------------------------------------------------|

Nu heb je keuze voor verschillende verpakkingsmogelijkheden van je lading. Je kunt de lading in zijn geheel in 1 grote doos stoppen (voorwaarde is dat je dat dan bij alle ladingen doet). Die grote doos past slechts per één tegelijk door het hoge stuk van je magazijndeur.

Je kunt de ladingen ook splitsen in kleinere pakketjes, welke met meerdere tegelijk door de deur passen.

[glashio]

[boerenmodus]
Deze topic gaat over "relaties" horizontaal opslaan ( relatie is DE row zelf ) ipv vertikaal opslaan ( normaal model , dmv Primary & Secundairy Keys )
[/boerenmodus]

Het idee klinkt intressant.
Alleen moet je je toch echt af vragen waarom de "Developers" van o.a. MySQL aangeven dat je beter het normaal model kan gebruiken.
Tuurlijk wees Creatief! ( het kan altijd beter ) maar om nu zelf een C plugin voor MySQL te gaan maken.. klinkt makkelijker dan dat het is
( of behoor je tot de Elite ? Referentie's ? )
Een ander puntje kan zijn dat je Werk-,Opdrachtgever zekerheid wil over de stabiliteit ( MySQL versie 5 is ook nog steeds Expirimental )

• Algemene [b]Creatieve/Handige Oplossingen[/b] met MySQL vanuit me [url=http://gathering.tweakers.net/forum/list_bookmarks/0//forum]bookmarks[/url]
• [MySQL] Multiple rows update, single query?
• [MySQL] LIKE query op komma-gescheiden veld
• [mysql]oplossing query probleem zonder subqueries
• Mijn Favoriet : [SQL] snel zoeken met 2 wildcards _{Ode aan cameodski O+}

Dus wees scherp, maar doe ook aannamens van andere Dev'ers ( ze hebben zich al bewezen )

* glashio hoopt op een briljant idee/opmerking om deze draad tot een goed einde te brengen, maar blijft versteld staan van TS eigenwijsheid

[ Voor 9% gewijzigd door glashio op 21-06-2004 20:36 . Reden: flame @ TS ]

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 19:20:
[...]
Ik heb nog niemand gezien die de volgende stelling onjuist vind:

Ik tel hier anders 6 man die erop hebben gereageerd met een reactie die laat blijken dat ze vinden dat je stelling niet klopt.

Anoniem: 97422 schreef op 21 juni 2004 @ 19:15:
[...]
Waarom niet, je begint met meten als de eerste query begin en stopt met meten als de eerste query af is, vervolgens doe je stoptijd-eindtijd=tijd1. Hetzelfde doe je bij de tweede query (tijd2). Dit doet je een paar honderd keer onder realistische omstandigheden. De query die gemiddeld het korste duurt is de winnaar.

Meten? maar dan moet je een andere benchmark maken die deze twee meet, de benchmark die jij hebt gebruikt heeft niet deze methode gemeten, echter heb jij wel dezelfde conclusie eraan gehangen aan de hand van juist die benchmark. Immers kon dat iedereen "aanvoelen" volgens jou. Wat is het nou? kan je het nou beredeneren of moet je toch meten?

Dit is nou typisch een verschil tussen vergelijken en meten. Je kunt het verschil tussen beiden methoden meten, echter kun je niet zeggen dat 1 keer 150 velden gelijk is aan 150 keer 1 veld. (niet voor de database in iedergeval)

[whoami]

Anoniem: 97422 schreef op 21 juni 2004 @ 19:20:
[...]

Ik heb nog niemand gezien die de volgende stelling onjuist vind:
---------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) is sneller dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.

Ik vind ze onjuist.
Een RDBMS is geoptimaliseerd om met JOINS te werken. De overhead die je daardoor krijgt is miniem, en weegt totaal niet op tegen de voordelen van een goed genormaliseerd datamodel.
Het is natuurlijk wel zo dat bij datawarehouses de tabellen zo gemaakt zijn dat er door gequeried kan worden zonder veel joins te doen, maar dat is dan ook altijd historische data, waar geen updates nodig zijn.
Daarbij is het gewoon inefficiënt om al die irrelevante data terug te geven.

Ik vind het trouwens behoorlijk arrogant om alle goede adviezen die je door verschillende pro's gegeven werden in de wind te slaan zonder ze ook maar één keer verder te onderzoeken.

[Anoniem: 97422]

whoami schreef op 21 juni 2004 @ 20:24:
[...]

Ik vind ze onjuist.
Een RDBMS is geoptimaliseerd om met JOINS te werken. De overhead die je daardoor krijgt is miniem, en weegt totaal niet op tegen de voordelen van een goed genormaliseerd datamodel.
Het is natuurlijk wel zo dat bij datawarehouses de tabellen zo gemaakt zijn dat er door gequeried kan worden zonder veel joins te doen, maar dat is dan ook altijd historische data, waar geen updates nodig zijn.
Daarbij is het gewoon inefficiënt om al die irrelevante data terug te geven.

Je spreekt je zelf tegen. Je vind de stelling dat oplossing .2 sneller is dan oplossing .3 onjuist. Maar je geeft aan dat oplossing 3. overhead heeft. Zoals eerder gezegd het gaat hier om performance. Dus je zegt eigenlijk dat oplossing 3. langzamer is dan oplossing 2., wat weer inhoud dat oplossing 2. sneller is dan oplossing 3. En dat was de orginele stelling.

Ik vind het trouwens behoorlijk arrogant om alle goede adviezen die je door verschillende pro's gegeven werden in de wind te slaan zonder ze ook maar één keer verder te onderzoeken.

Ik heb ze niet in de wind geslagen, lees de reacties maar. Alleen is het mij bekend dat oplossing 3. langzamer is dan oplossing 2., als dat bekend is hoef je niet meer naar oplossing 3. te kijken.

[Grijze Vos]

Euhm, Dusty. 5 Normaalvormen zei je? Als zijn oude oplossing de eerste normaalvorm is (1 tabel met 150 kolommen), dan telt deze nieuwe oplossing van hem dus echt wel als nulde normaalvorm hoor.

Verder, kogels, wees koppig, doe het op je eigen manier, optimaliseer lekker. Tot over een half jaar, als je je zooi een tikkie wil/moet uitbreiden, en het toch niet zo lekker loopt.

Kijk, je kunt een paar plankjes aan elkaar vast slaan, en als kast neerzetten, of een goede degelijke kast bouwen (a la Ikea, of wat ook). Zo kun je ook een mooie uitgenormaliseerde database in elkaar klussen, of jouw prutpakketje in nulde of eerste normaalvorm. Tuurlijk, het doet het, maar zodra je er te zware boeken op legt, stort je plankenkastje in elkaar, en blijft de Ikea-kast overeind.

Verder is voor mij persoonlijk het best belangrijk om een mooi, verantwoord stuk software te bouwen (zeker als het niet voor de baas is), daar passen een paar speed-hacks niet echt bij. Maar goed, als jij voldoening haalt uit je ranzige code, moet je dat zelf weten. Bovendien denk ik niet dat die 2 ms wat je wint per page je echt iets gaan opleveren, of heb je meer dan 10.000 page views per dag? 10.000 pageviews zou je bij een 2ms snelheidswinst namelijk 20 seconden op een dag schelen, poeh hee, daar doe ik het voor. Nee, geef mij maar een schaalbaar, uitbreidbaar, mooi datamodel.

[whoami]

Anoniem: 97422 schreef op 21 juni 2004 @ 20:33:
[...]

Je spreekt je zelf tegen. Je vind de stelling dat oplossing .2 sneller is dan oplossing .3 onjuist. Maar je geeft aan dat oplossing 3. overhead heeft. Zoals eerder gezegd het gaat hier om performance. Dus je zegt eigenlijk dat oplossing 3. langzamer is dan oplossing 2., wat weer inhoud dat oplossing 2. sneller is dan oplossing 3. En dat was de orginele stelling.

Ik spreek mezelf niet tegen. Ik zeg dat er overhead is, maar dat deze miniem is en niet opweegt tegen jouw systeem waarin je 150 kolommen, of 2 kolommen maar met evenveel data in het geheugen gaat lezen, terwijl je waarschijnlijk meerdere gegevens niet nodig hebt.

Daarbij is MySQL geoptimaliseerd om met joins te werken; k kan me niet voorstellen dat MySQL geoptimaliseerd is om met grote tabellen (in de breedte) te werken.

Ik heb ze niet in de wind geslagen, lees de reacties maar. Alleen is het mij bekend dat oplossing 3. langzamer is dan oplossing 2., als dat bekend is hoef je niet meer naar oplossing 3. te kijken.

Je slaat ze wel in de wind, want je test ze niet.

[glashio]

* glashio wacht totdat TS uit z'n bed gebeld word door de Storingsdienst
Melding : Applicatie,Database-crash... kom je ff fixen ( human redunanty ).

[dusty]

Grijze Vos schreef op 21 juni 2004 @ 20:34:
Euhm, Dusty. 5 Normaalvormen zei je? Als zijn oude oplossing de eerste normaalvorm is (1 tabel met 150 kolommen), dan telt deze nieuwe oplossing van hem dus echt wel als nulde normaalvorm hoor.

Kom op, niemand werkt met de nulde normaal vorm als ze een database gebruiken

[whoami]

dusty schreef op 21 juni 2004 @ 20:44:
[...]
Kom op, niemand werkt met de nulde normaal vorm als ze een database gebruiken

Niet?
* whoami kijkt naar de topicstarter.

[ Voor 4% gewijzigd door whoami op 21-06-2004 20:47 ]

[slm]

Heh.. ik ben ook niet de grootste normalisatie freak, zeker niet omdat mysql 4.x inderdaad vrij traag is met joinen, maar een tabel met 150 velden, of een tabel met 2 velden waarvan 1 veld bestaat uit 150 aparte varchars gaat zelfs mij te ver

Als je het zo hoog op hebt met alleen de technische optimalisatie kijk dan eerst eens naar andere (en misschien wel betere?) mogelijkheden voordat je een database systeem echt volledig verkracht:
(- datamodel zoveel mogelijk normaliseren om vervolgens:)
- de JOIN results te cachen in temporary text/htm/xml files. Dit is met name interessant als je veel joins over een mysql 4 server moet doen en/of grote resultsets terug krijgt en als de data niet iedere seconde wijzigt.
Daarnaast (en eventueel onafhankelijk van bovenstaande):
- gebruikmaken van geschiktere veldtypes
- gebruik maken van statische rijgroottes, dus gebruik maken van chars ipv varchars en texts waardoor de seektime van elke rij behoorlijk wordt verkort.
- betere indexen
- mysql verplichten deze indexen te gebruiken door USE INDEX() te gebruiken

Voordelen:
- overzichtelijker
- makkelijker en veiliger te onderhouden
- sneller

Nadelen:
- niet mogelijk met data die per seconde wijzigt tenzij je een geavanceerd lock mechanisme gebruikt.

NB
Overigens vraag ik me wel af hoe je die snelheidstesten hebt uitgevoerd. Heb je ook nadat je x maal 2 verschillende queries hebt uitgevoerd, ook eens de queries in volgorde omgedraaid? Tussendoor enkele andere queries gedaan?

[Ralluph]

glashio schreef op 21 juni 2004 @ 20:39:
* glashio wacht totdat TS uit z'n bed gebeld word door de Storingsdienst
Melding : Applicatie,Database-crash... kom je ff fixen ( human redunanty ).

Nee, dat gebeurt niet, want TS heeft hierboven al aangegeven dat het slechts een hobbyprojectje is. Zoals sommigen hierboven ook ook al vermoeden verwacht de TS tienduizenden requests per dag, maar wil dat wel ergens goedkoop hosten, een hobby mag immers geen, of hoogstens weinig geld kosten. Zoals ook al eerder is opgemerkt, onder andere door Grijze Vos en mijzelf, zal het procentenwerk waar deze hele optimalisatieaktie hem om te doen is nauwelijks snelheidswinst opleveren in de beleving vanuit de client.

Het kost hem in ieder geval een hoop energie om zijn speculatieve stellingname tegenover een handjevol experts te blijven volhouden. Als hij die energie had besteed aan het uitwerken van drie eenvoudige testcases/benchmarks dan had iedereen er nog wat van kunnen leren. Maarja, een hobbyprojectje doe je in je eigen tijd en die is schaars of kost toch geld, want de TS (die hoogstwaarschijnlijk per pageview betaald krijgt) is klaarblijkelijk te beroerd om dat te doen. Om een lang verhaal kort te maken: ik, en met mij waarschijnlijk vele anderen, zouden graag wat meer achtergrondinfo lezen over waarin deze ranzige constructie moet worden ingebed. Wellicht dat dit wat duidelijkheid schept in de grote vraag die iedereen bezighoudt: waarom deze koppigheid?

offtopic:
Of is het soms zo dat de TS in zijn dromen wordt geplaagd door een boze demoon die hem de gruwelijkste dingen belooft als hij niet snel de performance maximaliseert.

[ Voor 4% gewijzigd door Ralluph op 21-06-2004 21:02 ]

[Anoniem: 90394]

deze tip had ik nog niet hier gezien :
voorwaarde: je id moet uniek zijn in de tabel

plaats eens LIMIT 1 achter je SQL-query(je krijgt dan dus altijd maar 1 row terug), dan zoekt de DB niet verder naar volgende matches en hoeft hij dus niet elke keer de hele tabel door te lopen.

dit doorlopen is nogal arbeids intensief omdat je rows dynamisch van lengte zijn als je varchar gebruikt.
tip2:
voorwaarde: je tabel is van het MyIsam tabel type
row-size fixeeren, dan is het makkelijker(lees: sneller) voor de db om uit te rekenen waar de volgende row zich op de disk bevindt.
dit doe je door alle string-data-kolommen om te zetten naar char (en je mag ook geen blob/text columns hebben want dan wordt het alsnog een dynamische tabel en soms worden je char kolommen dan ook nog stiekum varchar kolommen)
te controleren met

SQL:

SHOW TABLE STATUS FROM `jouwDbNaam`; 

en dan controleren of de kolom Row_Format "Fixed" zegt.
voordeel van Fixed is ook gelijk dat bij een crash er minder kans is op data-corruptie vanwege de vaste record lengte. nadeel is het grotere ruimte gebruik maar dat weegt niet op tegen de voordelen.
SHOW TABLE STATUS docs
Waarom Fixed?

maar normaliseren is geiler...

[whoami]

Als je een index liggen hebt op de kolom waarop je zoekt, dan valt dat zowiezo wel mee. Als die index gebruikt wordt, dan moet er zowiezo geen table-scan gebeuren en weet het DBMS wel snel of er nog rows terug te geven zijn of niet.

[Anoniem: 90394]

offtopic:
@ whoami:
weet ik wel, maar alle beetjes helpen, en LIMIT 1 is altijd een goed idee als je maar 1 record terug wilt hebben

[Infinitive]

offtopic:
@ReSc: heeft ook nadelen: stel dat er per abuis meerdere resultaten mogelijk zijn. Dan zul je dat op deze manier niet detecteren. Via de standaard mysql functies die in php zitten, zal je zelf zo'n check niet zo snel plaatsen in je code, maar bijv. een db wrapper (bijv. speciale functie voor enkele resultaten) zou zoiets wel kunnen.

Daarnaast is LIMIT niet standaard...

[Anoniem: 90394]

offtopic:
@ Infinitive:
de echte programmeur maakt geen fouten en weet altijd wat ie terug krijgt

en dat LIMIT geen standaard is... tis een MySQL standaard en MySQL is opzichzelf al een redelijke standaard, dat is standaard genoeg voor mij, standaard-technisch gezien dan

random quote:
Vroegah had je geen databases.
Vroegah stuurde je de loopjongen het archief in en als die dan niet snel genoeg was, gaf je hem een schop onder z'n reet.

[ Voor 19% gewijzigd door Anoniem: 90394 op 21-06-2004 22:36 ]

[goalgetter]

Ik heb met verbazing alle replies hier gelezen, maar even een vraagje aan de TS... Waarom gebruik je uberhaupt een database?

Je stelt dat onderhoudbaarheid geen issue is als de performance in het geding komt.

Als die perfomance echt zo belangrijk is gebruik dan gewoon een flatfile, dan spaar je meteen je database overhead uit. Of sterker nog, aangezien alle 150 values bij elke page-load nodig zijn, trap ze gewoon hardcoded in je script, spaart niet alleen de database overhead uit, maar ook de enorme tijd die het kost om een file uit te lezen!

Daarnaast bespaar je je allemaal trage cpu-tijd vretende hacks als explode.

[ Voor 8% gewijzigd door goalgetter op 22-06-2004 16:11 ]

[Anoniem: 25556]

goalgetter schreef op 22 juni 2004 @ 16:10:
Daarnaast bespaar je je allemaal trage cpu-tijd vretende hacks als explode.

Het flatfile systeem was hem al voorgesteld, maar was geen optie..

[dusty]

Anoniem: 25556 schreef op 22 juni 2004 @ 19:25:
[...]
Het flatfile systeem was hem al voorgesteld, maar was geen optie..

Moet je natuurlijk ook aangeven waarom het geen optie was he

Anoniem: 97422 schreef op 21 juni 2004 @ 16:31:
[...]
Flatfile is hoogstwaarschijnlijk langzamer. Bovendien m'n script heeft al connectie naar db als ik de bovenstaande query uitvoer, de overhead van het connecten heb ik dus al achter mij liggen.