[MYSQL] 150 kolommen of 2 kolommen?

[Anoniem: 97422]

Ik zit met een performance probleempje bij 1 van m'n script, dit script word aardig veel aangeroepen en haalt oa. 1 record uit een tabel met zo'n 150 kolommen. Het script heeft alle waarden in alle kolommen nodig, dus ik doe zoiets als:

select * from tabel where id=1
$waarden1=$row;

Maar zou het volgende sneller zijn?

Ik verklein de tabel tot 2 kolommen. En stop in de eerste kolom de 75 kolommen uit de oude tabel gescheiden door een pipe | teken. Voor de tweede kolom doe ik hetzelfde. Vervolgens haal ik m'n data op:

select kolom1, kolom2 from tabel where id=1
$waarden1=explode("|", $row["kolom1"]);
$waarden2=explode("|", $row["kolom2"]);

De waarden in de kolommen zijn alleen strings (vaak korte strings van maximaal 25 chars).

[Creepy]

En ID is uiteraard de primary key, of heeft een index?
Want een select met 1 veld in de where moet razendsnel gaan als er een index op dat veld zit of als dat veld de PK is.

[ Voor 53% gewijzigd door Creepy op 21-06-2004 14:28 ]

[Evilbee]

Maak een benchmark-scriptje in php oid. Dan zie je het snel genoeg

[THIJZEL]

het zou kunnen maar volgens mij is je database niet helemaal 100% genormaliseerd..

zie: http://burks.brighton.ac.uk/burks/foldoc/35/28.htm
of zoek : http://www.google.nl/sear...&q=database+normalisation


wat voor structuur heeft je database nu?

[ Voor 11% gewijzigd door THIJZEL op 21-06-2004 14:30 ]

[Anoniem: 60511]

Wat heet performance problemen? Brede tabellen klinkt al gauw als een niet goed opgezet db model; maar goed dat hoeft niet en aan zo'n opmerking heb je ook niet zo veel

Het ophalen van 1 record moet op zich snel zijn. Het hangt natuurlijk wel van af uit hoeveel records je tabel bestaat. Misschien kan je dat nog toevoegen... Mocht je veel records hebben zou je eens moeten gaan kijken of je indexes kan leggen. Daarnaast kan het reduceren van je aantal kolommen in je tabel ook wel wat tijdswinst opleveren... Maar of jou oplossing de beste is lijkt me niet...

[edit]
wordt tijd voor cursus megasneltypen

[ Voor 5% gewijzigd door Anoniem: 60511 op 21-06-2004 14:31 ]

[drm]

Het antwoord is: geen 150, geen 2 maar 3 kolommen. Zoals al geopperd wordt heb ik het vermoeden dat je model niet helemaal zuivere koffie is. Zoals jezelf al aangeeft zijn alle velden (ongeveer) dezelfde soort data, dus dat neigt (wat mij betreft) naar een volgend model:

fields
field_id
field_name

values
record_id
field_id
field_value

records
record_id
other_field_a
other_field_b ...

Waarbij ik dan even als voorbeeld een taaldatabaseje neem:

Inhoud van fields:

field_id	field_name
1	close_window
2	send_form

Inhoud van records

record_id	other_field
1	Nederlands
2	English

Inhoud van values

record_id	field_id	value
1	1	Sluit venster
1	2	Verzend formulier
2	1	Close window
2	2	Send form

Het idee is wel duidelijk denk ik Misschien dat je beter die kant op kan werken. Een groot voordeel hiervan is dat je makkelijk velden toe kan voegen en dat koppelingen die niet bestaan eenvoudig genegeerd kunnen worden mbv outer joins. Een groot nadeel is dat je in MySQL heel lastig de velden weer "horizontaal" kan benaderen (per record).

[Anoniem: 97422]

Ik probeer me zover mogelijk uit de buurt te blijven van joins omdat deze meestal de performance negatief beinvloeden. Het is wel mooi en goed te onder houden zo'n tabel structuur maar als performance een rol gaat spelen gaan meestal de goede bedoelingen overboord

Het is inderdaad een tabel waar taalstrings in staan, omdat ik maar 1 taal heb heb ik het lekker makkelijk gedaan en alles in 1 tabel gepropt. Met een simpel formuliertje kan de eindgebruiker de tabel muteren en zo zelf de taalstrings veranderen.

Ik heb even een test scrippie gemaakt:

code:

global $bm_page;
start_bench($bm_page);

//test is tabel met 150 cols
$sql="select * from test where id=8";
$rs_temp = mysql_query ($sql, $db);
if(!$rs_temp) fatal_error("SELECT");
$waarden = mysql_fetch_array ($rs_temp);

end_bench($bm_page);

start_bench($bm_page);

//textstrings kolom is kolom met 150 strings gescheiden door |
$sql="select textstrings from sites where id=7";
$rs_temp = mysql_query ($sql, $db);
if(!$rs_temp) fatal_error("SELECT");
$raw = mysql_result($rs_temp, 0, "textstrings");
$waarden=explode($DIV1, $raw);

end_bench($bm_page);

het blijkt dat 2 kolommen en vervolgens splitten met explode sneller is dan 150 kolommen in 1 tabel. Weer wat bijgeleerd vandaag

[edit] wat comments geadd.

[ Voor 8% gewijzigd door Anoniem: 97422 op 21-06-2004 14:55 ]

[Anoniem: 60511]

Dat lijkt me dus helemaal niet waar wat jij zegt over joins: je dbmodel: die geeft het vallen of staan aan van je performance... of je nu een twee, drie of vier voudige join moet doen; dat geeft over het algemeen niet de grootste bottleneck; ten minste: als ik mn eigenervaring hier neer mag gooien Je bent een soort van hack aan het bouwen in je db; wat heeft je hele db nu nog voor zin?

En kan je ook verklaren waarom het sneller is? Bij het bouwen van databases is het erg prettig als je weet hoe de engine werkt... dat kan nogal eens wat probelemen voorkomen...

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 14:50:
Ik probeer me zover mogelijk uit de buurt te blijven van joins omdat deze meestal de performance negatief beinvloeden.

Goed opgelet op school, alleen verkeerdom.

Een RDBMS is uitgevonden om joins te doen en daarvoor 100% uitgeoptimaliseerd. Nu is MySQL dan wel geen volwaardig RDBMS, maar dat is nog immer (net als performance) geen excuus om een tranentrekkend slecht datamodel te gebruiken.

[Anoniem: 97422]

Als je aan mysql/php gebonden bent dan kun je niet veel anders doen dan hacken.

mi kun je als mysql performance niet voldoet en je aan php/mysql gebonden bent zelf het beste alles uitvogelen, dus zelf een join doen, zelf splitten. Als het sneller is dan mysql, waarom zou je mysql het dan laten doen? Dat levert alleen performance verlies op terwijl dat in dit geval juist zo belangrijk is.

Dit geval is een goed voorbeeld, een hack blijkt sneller te zijn dan als je het door mysql laat doen.

[ Voor 13% gewijzigd door Anoniem: 97422 op 21-06-2004 15:14 ]

[Creepy]

Anoniem: 97422 schreef op 21 juni 2004 @ 15:13:
Als je aan mysql/php gebonden bent dan kun je niet veel anders doen dan hacken.

mi kun je als mysql performance niet voldoet en je aan php/mysql gebonden bent zelf het beste alles uitvogelen, dus zelf een join doen, zelf splitten. Als het sneller is dan mysql, waarom zou je mysql het dan laten doen? Dat levert alleen performance verlies op terwijl dat in dit geval juist zo belangrijk is.

Dit geval is een goed voorbeeld, een hack blijkt sneller te zijn dan als je het door mysql laat doen.

Ik vraag me dat toch echt af.

Geef eens meer info over je oorspronkelijke datamodel + de nodige indexen? Ik raag me namelijk sterk af of je uberhaupt wel indexen gebruikt.

Bij een goed opgezette DB zou het sneller moeten zijn om MySQL te laten joinen dan zelf in PHP de boel aan elkaar te plakken.

[Anoniem: 60511]

Nee, je had het model goed moeten opzetten, dat had de beste performance opgeleverd

Misschien als je eens bekijkt hoe de engine werkt van mysql; dan krijg je tenminste inzicht in wat je doet en hoe je, zeker voor mysql, je model het beste op kan zetten. Daarnaast zou ik toch wel eens willen weten ho jou structuur er uit ziet en hoeveel records in de tabel staan....

[edit]
weer te laat

[ Voor 4% gewijzigd door Anoniem: 60511 op 21-06-2004 15:23 ]

[Anoniem: 97422]

Het oude datamodel is makkelijk, het is 1 tabel met kolommen:
id (primary key) van type int
+ 150 kolommen van type varchar(255)

Het nieuwe snellere datamodel is nog makkelijker:
id (prim key) type int
1 kolom textstrings van type text

1.
select * from tabel where id=7

2.
select textstrings from tabel where id=7
explode()

2. is een sneller dan 1., wat inhoud zoals gezegd dat hack sneller is dan mysql. Het is gewoon een feit.

Het datamodel wat drm voorstelt is mooier maar vrijwel zeker langzamer dan 2.

[Infinitive]

Ik zie niet in waarom snelheid het probleem is? In plaats van 1 record met 150 kolommen, haal je 150 records op met een paar kolommen. Daar zit echt weinig verschil in. Bovendien zul je dit vaak doen, dus dat heeft grote kans om gecached te worden ook. Daarnaast is de tabel zelf ook nog eens klein, want zoveel talen heb je nu ook weer niet.

En wat is snelheid... wordt je totale script hierdoor 100x langszamer?

Het nadeel van je datamodel is, dat als je een woord wilt toevoegen - of nog erder: verwijderen), je een kolom zal moeten toevoegen/verwijderen... en daardoor dus ook je code zult moeten aanpassen.

[ Voor 33% gewijzigd door Infinitive op 21-06-2004 15:43 ]

[drm]

kogels:
2. is een sneller dan 1., wat inhoud zoals gezegd dat hack sneller is dan mysql. Het is gewoon een feit.

Het datamodel wat drm voorstelt is mooier maar vrijwel zeker langzamer dan 2.

"Vrijwel zeker" hebben we natuurlijk niks aan Zou je daar mijn model ook eens naast kunnen zetten en even wat (procentuele) performanceverschillen kunnen noemen? Daarnaast ook hoe groot het aandeel van die performanceverschillen is op de totale functionaliteit van je script/programma?

Overigens: zou e.e.a. niet kunnen liggen aan een verbinding met de databaseserver?

[Anoniem: 97422]

Het verschil qua snelheid is niet groot, bij 50 kolommen was ie een paar % van een milliseconden. Hoeveel dat bij 150 kolommen is weet ik niet, dat was me wat teveel type werk. Performance staat in dit geval boven onderhoudbaarheid. Dit klein beetje performance kan niet veel lijken, maar als je meerdere van die performance tunings doet krijg je mogelijk toch een betere performance en daar is het allemaal om te doen.

Drm, je data model ga ik niet implementeren, het is vrijwel zeker dat het langzamer is. Dus is zie het nut er niet helemaal van in, muv dat het wel leuk is om te kijken wat het verschil is. Maar dat laat ik over aan de individuele lezer die het leuk vind

Overigens: zou e.e.a. niet kunnen liggen aan een verbinding met de databaseserver?

Weet niet, ik neem aan dat bij beide queries hetzelfde over het lijntje gaat, misschien bij 1. iets meer omdat men onderscheid moet maken tussen de kolommen. Maar m'n lokale netwerk is wel snel genoeg (100mb)

[ Voor 19% gewijzigd door Anoniem: 97422 op 21-06-2004 16:09 ]

[Anoniem: 60511]

Je roept de hele tijd performance: over hoeveel milisecondes praten we en over hoeveel requests per seconde ga jij verwachten? Je bent stom als je niet drm's idee om gaat zetten naar jouw situatie

[Anoniem: 97422]

Anoniem: 60511 schreef op 21 juni 2004 @ 16:09:
Je roept de hele tijd performance: over hoeveel milisecondes praten we en over hoeveel requests per seconde ga jij verwachten? Je bent stom als je niet drm's idee om gaat zetten naar jouw situatie

Dan mag jij me uitleggen waarom een join op meerdere tabellen sneller zou zijn dan 1 select met 1 where statement?

[Anoniem: 60511]

Het gaat erom dat jij in je eerste datamodel uitging van een model met 150 kolomen. Die zou jij dan dus volgens het idee van DRM moeten uitsplisten in meerdere kolomen. Dan behaal jij een prima performance die absoluut jouw load aan kan die jij gaat verwachten... Dat weet ik zeker

Daarnaast heb je een schaalbaar model; geef me de nadelen

[whoami]

Ik heb niet alles gelezen, maar een RDBMS is gewoon geoptimaliseerd om JOINS uit te voeren.
De 'overhead' die daarmee gepaard gaat, is te verwaarlozen. Zeker als de query op niet meer dan 4 tabellen joined, en er geen OUTER joins in voorkomen.

Daarnaast is een goed datamodel zowiezo beter; zowel qua performance, onderhoudbaarheid en scalability.
De performance van een applicatie staat of valt met een goed datamodel. Door een goed genormaliseerd datamodel te gebruiken, kan je gewoon veel betere queries schrijven ipv domme hacks toe te passen die je performance naar beneden halen.

Anoniem: 97422 schreef op 21 juni 2004 @ 16:14:
[...]

Dan mag jij me uitleggen waarom een join op meerdere tabellen sneller zou zijn dan 1 select met 1 where statement?

Omdat je in jouw geval een hele hoop irrelevante data ophaalt.

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

[whoami]

Anoniem: 97422 schreef op 21 juni 2004 @ 15:38:
Het oude datamodel is makkelijk, het is 1 tabel met kolommen:
id (primary key) van type int
+ 150 kolommen van type varchar(255)

Het nieuwe snellere datamodel is nog makkelijker:
id (prim key) type int
1 kolom textstrings van type text

1.
select * from tabel where id=7

2.
select textstrings from tabel where id=7
explode()

2. is een sneller dan 1., wat inhoud zoals gezegd dat hack sneller is dan mysql. Het is gewoon een feit.

Het datamodel wat drm voorstelt is mooier maar vrijwel zeker langzamer dan 2.

Aargh, ik ben blij dat ik niet met jou hoef samen te werken....

[dusty]

Kogels: Zoals ik jouw stelling lees, kan jij beter met files gaan werken, in plaats van met een database. Aangezien jij de bel wel hebt horen luiden, maar nog niet eens een flauw idee hebt waar de klepel is (of zelfs waarvoor het dient).

Als je een database gaat misbruiken als een flatfile systeem, kan je gewoonweg beter meteen met een filesysteem werken en de database achterwege laten.

[RwD]

Tis misschien een loze opmerking, maar waarom moet het zo snel?

Als je veel gebruikers verwacht, dan is mySQL sowieso niet de database voor jou...
En aan mijn kant van het internet merk ik een tiende van een seconde niet eens

Maar goed, als je nou eens uitlegd wat je doel is, en waarom die performance zo belangrijk is, misschien komt dan wel iemand met de gouden tip

bovendien heeft dusty 100% gelijk, dat scheelt je 1 hele query!!

[ Voor 9% gewijzigd door RwD op 21-06-2004 16:24 ]

[Anoniem: 97422]

Anoniem: 60511 schreef op 21 juni 2004 @ 16:18:
Het gaat erom dat jij in je eerste datamodel uitging van een model met 150 kolomen. Die zou jij dan dus volgens het idee van DRM moeten uitsplisten in meerdere kolomen. Dan behaal jij een prima performance die absoluut jouw load aan kan die jij gaat verwachten... Dat weet ik zeker

Lees m'n orginele bericht nog maar eens goed door: "Het script heeft alle waarden in alle kolommen nodig". Wat zou sneller zijn: 1 record returnen of 150?

Daarnaast heb je een schaalbaar model; geef me de nadelen

Aargh lees m'n replies maar eens door (whoami en dusty ook )

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.

[Anoniem: 97422]

RwD schreef op 21 juni 2004 @ 16:23:
Als je veel gebruikers verwacht, dan is mySQL sowieso niet de database voor jou...

Als ik de keus had had ik het gewoon in C gedaan, maar je moet de systeembeheerders is horen als je een c programmatje wil installeren

[curry684]

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.

Waar dacht dat je mySQL z'n data laat?

Als je toch geen relationele of indexing eigenschappen gebruikt is een file per definitie tientallen tot honderden malen sneller dan een database.

[whoami]

Anoniem: 97422 schreef op 21 juni 2004 @ 16:31:
[...]


Aargh lees m'n replies maar eens door (whoami en dusty ook )

Ik durf wedden dat dusty en ik meer ervaring hebben met DBMS'en, en dus ook wel weten waar er performance winst te behalen is.
Heb je eigenlijk al eens gebenchmarked met een model zoals drm voorsteld?

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.

Dat denk ik niet, want zoals jij de DB nu gebruikt, creeër je gewoon overhead. Je gebruikt geen enkele van de features die een DB je biedt.

[Anoniem: 97422]

Ik mag hopen dat mysql gebruik maakt van een cache en niet elke keer alle tabellen uit het bestandssysteem leest Bovendien kleven er ook andere nadelen aan: locken van bestanden, limieten mbt filehandlers, enzovoorts.

[dusty]

hoogst waarschijnlijk?

Dus je weet het nog niet eens zeker?

Maar het ophalen van de index, de ophalen van de rijen moet ook gebeuren door de database, de database haalt dat ook uit een file hoor!

Nee, dat je de extra overhead van het aanleggen van de connectie niet nodig hebt verlost dat helemaal niet.

Jij begrijpt de essentie van een database gewoonweg niet.

Wat zou sneller zijn: 1 record returnen of 150?

1 record returnen van 150 kolommen? of 150 records met 3 kolommen, waarvan 2 integers zijn.. IK ga voor de tweede optie, 150 record returnen met 3 kolommen is sneller bij een goede database, Het is beter te onderhouden, de integriteit is beter te garanderen.

Je wilt niet luisteren naar advies, echter wil je toch je 150 kolommen behouden, of dus alles serializen, gebruik dan gewoon een flatfile dat is gegarandeerd sneller.

[Anoniem: 97422]

whoami schreef op 21 juni 2004 @ 16:37:
[...]

Ik durf wedden dat dusty en ik meer ervaring hebben met DBMS'en, en dus ook wel weten waar er performance winst te behalen is.
Heb je eigenlijk al eens gebenchmarked met een model zoals drm voorsteld?

Ach, laten we het niet op persoonlijk vlak gooien..

Waarom zou drm's model sneller zijn dan 1 simpele select statement die precies 1 record returnt? Als je dat kan uitleggen wil ik best drm's model is uitproberen.

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 16:38:
Bovendien kleven er ook andere nadelen aan:

Ha!, nu wordt het leuk!

locken van bestanden,

Locken van tables is er ook hoor, dat maakt verder geen donder uit immers gaat het hier over informatie ophalen, niet over het updaten of toevoegen. Immers was de onderhoudbaarheid geen probleem voor jou.

Je zegt hier in principe dat een peer beter is als een appel want een appel is een fruit.

limieten mbt filehandlers

En jij hebt geen limiet met het aantal connecties naar je database?

enzovoorts.

Geef die enzovoorts eens.. Ik wil namelijk nu wel eens weten hoever jouw kennis over databases gaat.

[Anoniem: 97422]

dusty schreef op 21 juni 2004 @ 16:39:
Je wilt niet luisteren naar advies, echter wil je toch je 150 kolommen behouden, of dus alles serializen, gebruik dan gewoon een flatfile dat is gegarandeerd sneller.

Zou je m'n replies eens door kunnen lezen? Als je dat gedaan had had je kunnen weten dat m'n optimalisatie maar 1 record met 2 kolommen returnt ipv 1 record met 150 kolommen.

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 16:38:
Ik mag hopen dat mysql gebruik maakt van een cache en niet elke keer alle tabellen uit het bestandssysteem leest Bovendien kleven er ook andere nadelen aan: locken van bestanden, limieten mbt filehandlers, enzovoorts.

Filesystems cachen ook, en gaan ook slim om met file locking. Ze doen het alleen op een lager (en dus sneller) niveau dan de database.

Ik begin dit topic eigenlijk wel een beetje zat te worden: je stelt een vraag over performance, waarop heel veel mensen met heel veel verstand van zaken je een hoop vertellen daarover, maar je blijft koppig volhouden dat je gelijk hebt.

Heb je wel eens de profielen opengeklikt van de mensen in deze thread wat ze bij 'Beroep' ingevuld hebben staan?

[drm]

Laten we ondanks de hevige discussie wel even voorkomen dat 't persoonlijk wordt, heren

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 16:45:
[...]
Zou je m'n replies eens door kunnen lezen? Als je dat gedaan had had je kunnen weten dat m'n optimalisatie maar 1 record met 2 kolommen returnt ipv 1 record met 150 kolommen.

Ja, dus je optimalisatie haalt de overhead van de kolom namen en interne id's weg, echter zet je daarvoor weer een extra vertraging in waar een taal de string uit elkaar moet gaan halen.

[Anoniem: 97422]

dusty schreef op 21 juni 2004 @ 16:43:

Locken van tables is er ook hoor, dat maakt verder geen donder uit immers gaat het hier over informatie ophalen, niet over het updaten of toevoegen. Immers was de onderhoudbaarheid geen probleem voor jou.

Lees m'n replies dan eens, je reactie is nu een beetje vreemd. Er is een formulier dat de eindgebruiker gebruikt om de waarden in die 150 kolommen te veranderen. Locken is dus wel nodig.

En jij hebt geen limiet met het aantal connecties naar je database?

4096, ik dacht dat filehandles op 250 stond.

[curry684]

Als we het trouwens over locks hebben: bij dermate brede tabellen escaleert een row lock linea recta naar een table lock zodra je aan het updaten gaat, omdat een page lock dan al niet meer past. Sgoed voor je performance

Gelukkig kent MySQL geen row-locks, en zal die dus meteen een table lock tevoorschijn trekken waarschijnlijk

[Anoniem: 97422]

dusty schreef op 21 juni 2004 @ 16:48:
[...]

Ja, dus je optimalisatie haalt de overhead van de kolom namen en interne id's weg, echter zet je daarvoor weer een extra vertraging in waar een taal de string uit elkaar moet gaan halen.

We komen er wel (zoals beschreven in m'n replies) explode schijnt sneller te zijn dan de overhead van kolomnamen.

[Anoniem: 60511]

De manier waarop je er nu mee omgaat kan gewoon niet; je bouwt sowieso te veel risico in met je 'slim' bedachte manier van het opslaan van 75 atttributes in 1 attribuut.... Nu moet je gaan afvangendat niemand een | invoert; anders gaat je hele zaakie onderuit; iemand gaat in de db hacken en wijzigd daar iets waardoor je hele array die je uit je explode haalt niet meer klopt oftewel: dit kan je gewoon niet doen!!!

Ik heb overigens nog steeds geen benchmark gezien die je explode ideetje goed maakt tegenover een correct databasemodel

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 16:50:
[...]

Lees m'n replies dan eens, je reactie is nu een beetje vreemd. Er is een formulier dat de eindgebruiker gebruikt om de waarden in die 150 kolommen te veranderen. Locken is dus wel nodig.

Zowel je filesystem als je database locken enkel met een Shared lock. Zodra er een update tussendoor komt zal deze een Intent Exclusive lock plaatsen om alle shared readers uit te pushen, maar de reads zijn wel degelijk simultaan. Ik vertrouw een gerenommeerd FS als ext2/3 of NTFS echter meer wat betreft dynamic lock promotion e.d. dan MySQL wederom

4096, ik dacht dat filehandles op 250 stond.

De meeste MySQL connecties onder Linux lopen via TCP, waarvan de sockets equivalent zijn aan filedescriptors en dus uit dezelfde process pool komen. Onder Win32 zijn zowel sockets als filehandles resource-limited.

[Anoniem: 97422]

curry684 schreef op 21 juni 2004 @ 16:45:
[...]
Ik begin dit topic eigenlijk wel een beetje zat te worden: je stelt een vraag over performance, waarop heel veel mensen met heel veel verstand van zaken je een hoop vertellen daarover, maar je blijft koppig volhouden dat je gelijk hebt.

Heb je wel eens de profielen opengeklikt van de mensen in deze thread wat ze bij 'Beroep' ingevuld hebben staan?

Het word hier nogal gauw persoonlijk?

Het is een feit dat ik gelijk heb, de benchmark geeft mij gewoon gelijk (zie mijn eerdere replies).

[dusty]

mm.. ff een quote uit jouw start:

en haalt oa. 1 record uit een tabel

Je gaat over het algemeen vaker informatie uit een tabel halen, dan muteren. ( althans dat neem ik aan) jij zegt dat de eind gebruiker de waardes mag gaan muteren, hoeveel eindgebruikers krijg je die allemaal tegelijk de tabel gaan muteren, hoe zorg jij ervoor dat de juiste mutatie erdoor heen komt? Hoe lost jij je concurrency probleem op met het veranderen van de waarden door meerdere personen tegelijkertijd?

4096 [...] 250

Als je de standaard limiet van filehandles gebruikt, gebruik dan ook de standaard limiet van MySQL.

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 16:56:
[...]

Het is een feit dat ik gelijk heb, de benchmark geeft mij gewoon gelijk

Open dan geen topic waarin je om suggesties vraagt als je ze toch niet wil lezen.

[Anoniem: 97422]

curry684 schreef op 21 juni 2004 @ 16:55:
De meeste MySQL connecties onder Linux lopen via TCP, waarvan de sockets equivalent zijn aan filedescriptors en dus uit dezelfde process pool komen. Onder Win32 zijn zowel sockets als filehandles resource-limited.

Mmm, dan zit ik op een vreemd systeem Vroeger had ik alles textfile based en toen begon de systeem beheerder te gillen dat dat toch niet meer ging. Toen had ik alles overgezet naar mysql en toen was hij helemaal tevreden. Kan het zijn dat de beheerder meer controleren heeft over sockets van mysql dan een filehandler die met bijvoorbeeld fopen word aangemaakt?

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 16:53:
[...]
We komen er wel (zoals beschreven in m'n replies) explode schijnt sneller te zijn dan de overhead van kolomnamen.

Jouw methode 2 is beter dan onze methode 3 omdat jouw methode 2 beter is dan jouw methode 1?

[Infinitive]

De mensen in dit topic hebben echt niet als doel je voor schut te zetten of in de grond te boren hoor TS, of om per sé hun gelijk te halen

Wat ze willen is dat je afziet van je datamodel. Je kiest voor een model alleen op grond van (twijfelachtige) performance. In de praktijk is gebleken dat zoiets niet handig is en dat er naast performance vele andere kwaliteitsaspekten zijn. Bijvoorbeeld onderhoudbaarheid, eenvoud en daarnaast speelt iets subjectiefs als smaak ook nog een rol.

Bekende slogans als "Premature optimalisation is the root of all evil" enzo.

[Anoniem: 97422]

curry684 schreef op 21 juni 2004 @ 17:00:
[...]

Open dan geen topic waarin je om suggesties vraagt als je ze toch niet wil lezen.

Ten tijde van openen had ik nog geen benchmark gedaan. Een benchmark was 1 van de suggesties, die heb ik opgevolgd. Daarna heb ik het resultaat gepost en toen sprongen jullie er allemaal op.

[Anoniem: 97422]

Infinitive schreef op 21 juni 2004 @ 17:03:
Bekende slogans als "Premature optimalisation is the root of all evil" enzo.

I know Maar het is ook bekend dat vele druppels een emmer kunnen vullen, maw als je geen grote optimalisaties meer kunt doen, kijk naar de kleintjes en met een beetje geluk vormen alle kleine optimalisaties toch weer een redelijke performance winst.

[Creepy]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:03:
[...]

Ten tijde van openen had ik nog geen benchmark gedaan. Een benchmark was 1 van de suggesties, die heb ik opgevolgd. Daarna heb ik het resultaat gepost en toen sprongen jullie er allemaal op.

En dat komt omdat je onze suggesties in je benchmark niet meeneemt, bijv. dat datamodel zoals DRM dat aangeeft

[Anoniem: 97422]

dusty schreef op 21 juni 2004 @ 17:03:
[...]

Jouw methode 2 is beter dan onze methode 3 omdat jouw methode 2 beter is dan jouw methode 1?

Dat is een combinatie van benchmark en gewoon logisch nadenken. Maar ik herhaal me wederom

[ Voor 8% gewijzigd door Anoniem: 97422 op 21-06-2004 17:08 ]

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:03:
[...]

Ten tijde van openen had ik nog geen benchmark gedaan. Een benchmark was 1 van de suggesties, die heb ik opgevolgd. Daarna heb ik het resultaat gepost en toen sprongen jullie er allemaal op.

En mag ik vragen hoe je gebenched hebt? Op een reallife productieserver met regelmatige updates en selects? Heb je indexen op kolommen liggen? Wat voor data gaat het uberhaupt over? Wordt de data ook nog voor OLAP of andere analytische vragen gebruikt? Groeien de tabellen regelmatig, worden ze groot, zijn er meer updates dan inserts etc. etc. etc.

Vertel eens wat over je datamodel, en overtuig ons aub van je gelijk. Met "uit test blijkt methode A 5% sneller dan methode B" kunnen we niets, we moeten toch op z'n minst weten wat je hoe gebenched hebt.

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:06:
[...]

I know Maar het is ook bekend dat vele druppels een emmer kunnen vullen, maw als je geen grote optimalisaties meer kunt doen, kijk naar de kleintjes en met een beetje geluk vormen alle kleine optimalisaties toch weer een redelijke performance winst.

Ik denk persoonlijk dat je goeie indexes veel meer winst kunt bereiken maja. Dat is afhankelijk van het gebruik van je database, en daar vertel je weinig over. Heb je er al eens een profiler overheen gehaald?

[Anoniem: 97422]

Zo diep ben ik er ook weer niet in gegaan, het gaat hier om een kleine performance winst, waarvan ik weet dat ik de goede beslissing heb genomen. Jullie kunnen jullie zelf overtuigen door m'n datamodel te pakken hem te vullen en alle 2 (of 3 inclusief drm's model) de methoden te benchmarken.

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:07:
[...]
Dat is een combinatie van benchmark en gewoon logisch nadenken. Maar ik herhaal me wederom

Ehh.. ff een wiskundige voorbeeld dan.

Ik heb 3 getallen in mijn hoofd... a,b en c.

Met een benchmark toon je aan dat b groter is dan a.

Wat kan je nu over c zeggen t.o.v. b?

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:12:
Zo diep ben ik er ook weer niet in gegaan, het gaat hier om een kleine performance winst, waarvan ik weet dat ik de goede beslissing heb genomen.

Ja doei je hebt op basis van gokwerk dus een beslissing genomen, weet zeker dat het de juiste is, en wil nu niet luisteren naar advies over hoe je normaliter een database optimaliseert

Stap 1 is normaal gesproken toch echt "analyseer welke queries hoe vaak op welke momenten plaatsvinden"

[edit]

Heb je ondertussen de filebased oplossing ook al gebenched trouwens? Die is namelijk gegarandeerd sneller dan allebei jouw versies.

[ Voor 12% gewijzigd door curry684 op 21-06-2004 17:17 ]

[Anoniem: 97422]

curry684 schreef op 21 juni 2004 @ 17:10:
[...]

Ik denk persoonlijk dat je goeie indexes veel meer winst kunt bereiken maja. Dat is afhankelijk van het gebruik van je database, en daar vertel je weinig over. Heb je er al eens een profiler overheen gehaald?

Het enigste wat hier van belang is is volgens mij het datamodel wat ik noemde (1 tabel, als je methode 1. pakt met 150 kolommen, bij methode 2. met 2 kolommen).

Natuurlijk zijn dit niet alle tabellen, maar het ging me echt om die tabel en om het feit of 150 kolommen sneller/langzamer zou zijn dan 2 kolommen in combinatie met explode.

[Anoniem: 97422]

curry684 schreef op 21 juni 2004 @ 17:15:
[...]

Ja doei je hebt op basis van gokwerk dus een beslissing genomen, weet zeker dat het de juiste is, en wil nu niet luisteren naar advies over hoe je normaliter een database optimaliseert

Stap 1 is normaal gesproken toch echt "analyseer welke queries hoe vaak op welke momenten plaatsvinden"

Ik weet hoe je een database optimaliseert, die stap ligt zoals gezegd al achter mij. Mijn interesse ging uit naar het verschil tussen 150 kol en explode (zie orginele post). Daar geef ik niet m'n totale datamodel aan, ik geef eigenlijk een simpel voorbeeld zonder al te veel poespas, juist om niet te vervallen in andere discussies.

[curry684]

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

Ik weet hoe je een database optimaliseert, die stap ligt zoals gezegd al achter mij.

Merk ik niet veel van. I repeat: heb je al een profiler gebruikt?

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:19:
[...]
Ik weet hoe je een database optimaliseert,
[..]

Mooi, in welke normaalvorm verkeert je database model nu?

[ Voor 2% gewijzigd door dusty op 21-06-2004 17:23 . Reden: nederlandsch :P ]

[Anoniem: 97422]

curry684 schreef op 21 juni 2004 @ 17:20:
[...]

Merk ik niet veel van. I repeat: heb je al een profiler gebruikt?

Nee, het datamodel is simpel genoeg om het mbv logisch nadenken in combinatie met ervaring te optimaliseren. (lees: weinig relaties, nauwelijks joins en de joins die er zijn daar heb ik zowat alle combinaties van getest).

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:24:
[...]

Nee, het datamodel is simpel genoeg om het mbv logisch nadenken in combinatie met ervaring te optimaliseren. (lees: weinig relaties, nauwelijks joins en de joins die er zijn daar heb ik zowat alle combinaties van getest).

Ergo je weet niets, maar dan ook niets, over hoe je database werkt en of je globaal gezien je database nu aan het remmen of versnellen bent.

[Ralluph]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:12:
Zo diep ben ik er ook weer niet in gegaan, het gaat hier om een kleine performance winst, waarvan ik weet dat ik de goede beslissing heb genomen. Jullie kunnen jullie zelf overtuigen door m'n datamodel te pakken hem te vullen en alle 2 (of 3 inclusief drm's model) de methoden te benchmarken.

De koppigheid van de TS is opmerkelijk.

Wellicht is het een goede nieuwe invalshoek van jouw probleem om eens te bedenken wat het je waard is om zulke rare fratsen (lees: jouw datamodel) uit de kast te trekken als je er maar hooguit een kleine performancewinst mee behaalt. Wanneer jij over een kleine performancewinst spreekt, dan denk ik aan enkele procenten tot tienden van procenten snelheidswinst per transactie (ervan uitgaande dat we performance puur in executiesnelheid meten) t.o.v. de huidige situatie. Is het dan niet veel gemakkelijker om te investeren in extra hardware? Dat scheelt je een hoop kopzorgen en als je applicatie echt bedrijfskritisch is dan kun je je opdrachtgevers best overtuigen van het belang hiervan. Als opdrachtgever zou ik daar sowieso meer vertrouwen in hebben dan wanneer mij ter ore zou komen dat je veel tijd besteedt aan het klussen van een dergelijke hack.

offtopic:
Bedenk eens hoeveel tijd er al in dit topic is gaan zitten. Dit is geenszins bedoeld als demotivatie, want de vermaakfactor voor de andere GoTters mag natuurlijk niet worden onderschat.

offtopic:
En als je dan toch bezig bent met upgraden, vergeet dan niet om ook het RDBMS mee te nemen in je overweging.

[ Voor 5% gewijzigd door Ralluph op 21-06-2004 17:30 ]

[Anoniem: 97422]

dusty schreef op 21 juni 2004 @ 17:22:
[...]

Mooi, in welke normaalvorm verkeert je database model nu?

Ik heb niet genormaliseerd, want ik ben meteen uitgegaan van een tabel structuur die geoptimaliseerd is voor performance. Duplicatie van data in verschillende tabellen is in dit geval toegelaten. Als je verder normaliseerd bestaat de kans dat de performance er onder leid en dat moet juist niet.

[curry684]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:29:
[...]

Ik heb niet genormaliseerd, want ik ben meteen uitgegaan van een tabel structuur die geoptimaliseerd is voor performance. Duplicatie van data in verschillende tabellen is in dit geval toegelaten. Als je verder normaliseerd bestaat de kans dat de performance er onder leid en dat moet juist niet.

Heb je wel eens van het verschil tussen OLTP en OLAP gehoord? En waarom OLTP-servers uitgenormaliseerd zijn en OLAP-servers 1 of meerdere keren per dag de data denormaliseren?

[Anoniem: 97422]

Ralluph schreef op 21 juni 2004 @ 17:28:
[...]

De koppigheid van de TS is opmerkelijk.

Wellicht is het een goede nieuwe invalshoek van jouw probleem om eens te bedenken wat het je waard is om zulke rare fratsen (lees: jouw datamodel) uit de kast te trekken als je er maar hooguit een kleine performancewinst mee behaalt. Wanneer jij over een kleine performancewinst spreekt, dan denk ik aan enkele procenten tot tienden van procenten snelheidswinst per transactie (ervan uitgaande dat we performance puur in executiesnelheid meten) t.o.v. de huidige situatie. Is het dan niet veel gemakkelijker om te investeren in extra hardware? Dat scheelt je een hoop kopzorgen en als je applicatie echt bedrijfskritisch is dan kun je je opdrachtgevers best overtuigen van het belang hiervan. Als opdrachtgever zou ik daar sowieso meer vertrouwen in hebben dan wanneer mij ter ore zou komen dat je veel tijd besteedt aan het klussen van een dergelijke hack.
[offtopic]Bedenk eens hoeveel tijd er al in dit topic is gaan zitten. Dit is geenszins bedoeld als demotivatie, want de vermaakfactor voor de andere GoTters mag natuurlijk niet worden onderschat.

Het is een persoonlijk projectje. Als ik het voor m'n werk had gedaan had ik het allang opgegeven en gevraagd om een snellere server. Maar zo'n server en de hosting kosten kan ik persoonlijk niet betalen. Dus ik ben wel aangewezen tot hacks.

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:29:
[...]
Ik heb niet genormaliseerd, want ik ben meteen uitgegaan van een tabel structuur die geoptimaliseerd is voor performance. Duplicatie van data in verschillende tabellen is in dit geval toegelaten. Als je verder normaliseerd bestaat de kans dat de performance er onder leid en dat moet juist niet.

Hoeveel normalisatievormen zijn er?

[Anoniem: 97422]

curry684 schreef op 21 juni 2004 @ 17:30:
[...]

Heb je wel eens van het verschil tussen OLTP en OLAP gehoord? En waarom OLTP-servers uitgenormaliseerd zijn en OLAP-servers 1 of meerdere keren per dag de data denormaliseren?

Gelukkig nooit van gehoord, want ik heb er nooit mee te maken gehad. Kan de kennis over OL*P handig zijn als je alleen beschikking hebt over PHP/mysql? Zo ja, dan verdiep ik me erin, zo niet dan niet.

[Anoniem: 97422]

dusty schreef op 21 juni 2004 @ 17:34:
[...]
Hoeveel normalisatievormen zijn er?

Hoeveel is 1+1? Is dit een soort test? Die tijd ligt al jaren achter mij. Dit is wel een erg laag niveau waarop je je bevind dusty. Maar zoals een moderator het zei, laten we niet op persoonlijk vlak houden.

[ Voor 12% gewijzigd door Anoniem: 97422 op 21-06-2004 17:40 ]

[curry684]

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

Het is een persoonlijk projectje. Als ik het voor m'n werk had gedaan had ik het allang opgegeven en gevraagd om een snellere server.

That's the true spirit: als het niet snel genoeg is hebben we snellere hardware nodig, want aan onze software kan het niet liggen! \o/

Van dat soort volk krijgt de hele IT-branche helaas een slechte naam

[Ralluph]

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

Het is een persoonlijk projectje. Als ik het voor m'n werk had gedaan had ik het allang opgegeven en gevraagd om een snellere server. Maar zo'n server en de hosting kosten kan ik persoonlijk niet betalen. Dus ik ben wel aangewezen tot hacks.

Tja, dan ligt het natuurlijk anders. Zou je mij dan kunnen uitleggen waarom het dan alsnog zo belangrijk is dat de transactietijd wordt geoptimaliseerd. Die paar milliseconden zullen toch niet echt merkbaar zijn op het totaal van een pagina-request. De totale roundtrip-tijd is immers van veel meer factoren afhankelijk, die veelal een veel grotere invloed hebben. Ik probeer maar te zeggen: houd het realistisch.
Bovendien, ik denk niet dat de MySQL-beheerder (de server wordt vast en zeker gedeeld met meerdere klanten) vrolijk wordt als jij full-pull aan de server lurkt.

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:38:
[...]
Hoeveel is 1+1? Is dit een soort test? Die tijd ligt al jaren achter mij. Dit is wel een erg laag niveau waarop je je bevind dusty. Maar zoals een moderator het zei, laten we niet op persoonlijk vlak houden.

Jij wilt niet luisteren naar advies, jij houd bij hoog en laag vol dat je gelijk hebt. En de enige methode die ik weet om anders aan te tonen is om jou wat simpele vragen te laten beantwoorden waardoor ik kan aantonen dat het niet correct is, immers als je de materie kent zou je dat ook toepassen. Jij doet dat hier niet maar je spreekt wel alsof je er verstand van hebt.

Om die illusie weg te nemen bij beginnende programmeurs die hier komen, en denken aan jou een voorbeeld te nemen.

Jij kan aantonen dat je gelijk hebt bij de vragen te beantwoorden ( dat was trouwens de laatste vraag die ik nodig hebt.. FYI )

Jij geeft te kennen de materie te kennen met het antwoord dat je geeft op hoeveel normalisatie vormen er zijn, en ik toon aan van de hand daarvan dat jij de materie niet kent. Lijkt me duidelijk zat.

[Ralluph]

curry684 schreef op 21 juni 2004 @ 17:42:
[...]

That's the true spirit: als het niet snel genoeg is hebben we snellere hardware nodig, want aan onze software kan het niet liggen! \o/

Van dat soort volk krijgt de hele IT-branche helaas een slechte naam

Dat is waar, maar de keuze tussen uren spenderen aan een smerige oplossing (die de onderhoudbaarheid en doorzichtigheid van de applicatie ondermijnt) of investeren in een geupgrade/extra/snellere doos lijkt mij vanuit het perspectief van een projectmanager niet zo lastig om te maken.

[Sybr_E-N]

Anoniem: 97422 schreef op 21 juni 2004 @ 17:38:
[...]

Hoeveel is 1+1? Is dit een soort test? Die tijd ligt al jaren achter mij. Dit is wel een erg laag niveau waarop je je bevind dusty. Maar zoals een moderator het zei, laten we niet op persoonlijk vlak houden.

Als jij het zo goed weet, waarom open je dan een topic met een vraag waarop je zelf het antwoord al weet? Er worden serieuze suggesties gedaan en op/aan-merkingen gemaakt over jouw standpunt. Waarom sla je die zomeer in de wind?

Als jij duidelijk en helder voor de geest kan halen hoe een relationele database in elkaar steekt kom je er al snel achter dat zowel '150 kolomen' als '2 a 3 kolomen met '|' gesplitte data' niet efficient is. Ja, wellicht als je er 10 rows in opslaat, maar hoe gaat het zich uitpakken wanneer er 600.000 of meer rows in je database staan? Hier kom je alleen maar achter door uitgebreide te gaan lopen testen en de verschillende opties met elkaar te gaan vergelijken.

Alleen ik snap niet hoe jij erbij komt dat joins juist langzamer zouden zijn? Totzover mij op school/ boeken/ internet is geleerd dat joins er juist voor zijn uitgevonden om data zo snel en effiecient mogelijk op te halen uit de database.

[bigbeng]

curry684 schreef op 21 juni 2004 @ 17:42:
[...]

That's the true spirit: als het niet snel genoeg is hebben we snellere hardware nodig, want aan onze software kan het niet liggen! \o/

Van dat soort volk krijgt de hele IT-branche helaas een slechte naam

offtopic:
tsk tsk Curry, je bent nu de TS bijna direct aan het beledigen.

Ralluph schreef op 21 juni 2004 @ 17:47:
[...]

Dat is waar, maar de keuze tussen uren spenderen aan een smerige oplossing (die de onderhoudbaarheid en doorzichtigheid van de applicatie ondermijnt) of investeren in een geupgrade/extra/snellere doos lijkt mij vanuit het perspectief van een projectmanager niet zo lastig om te maken.

Maar het gaat niet alleen om smerige oplossingen, er komen hier ook zinvolle optimalisatie suggesties voor die een upgrade naar een nieuwe machine kunnen uitstellen of zelfs overbodig maken. Dus zo makkelijk is de keus niet altijd.

[Anoniem: 25556]

Dusty en curry: let it go. Jullie zijn imo wel erg druk bezig jullie eigen gelijk te halen en willen persé aantonen dat TS geen verstand heeft van databases. De vraag 'hoeveel normaalvormen zijn er?' wordt alleen gesteld om aan te tonen dat TS er geen verstand van heeft, een bewijs waar niemand wat aan heeft.

Dan voor TS: Je zit hier niet met domme nitwits te praten. Je geeft zelf aan dat je aan het optimaliseren bent, en dat je in de fase van 'de kleine druppels' beland bent.

Als je dan hier komt vragen om advies vind ik het wel zo netjes om dat advies op z'n minst eens een kans te geven, of er op z'n minst geen uitspraken over te doen.

Je beweert dat jouw oplossing sneller is, zonder de geadviseerde oplossing zelfs maar getest te hebben, nogal logisch dat je daar opmerkingen over krijgt. 'Ja maar ik heb gebenched'; dat heb je dus niet. Althans niet de door DRM voorgestelde oplossing.

Zeg dan gewoon 'die oplossing wil ik niet, en daar heb ik geen goede redenen voor, basta'.

Needles to say dat de oplossing die je nu hebt meer is dan een hack; hij is gewoon extreem smerig, zo ongeveer het schoolvoorbeeld van 'meest foute actie om uit te halen'. Kan zo de boekjes in, nofi. Het ophalen van afzonderlijke kolommen is langzaam, weet je wat: we pleuren alles in 1 kolom.

Hoe gaat MySQL om met zulke brede velden? Wat voor datatype hangt hij daaraan, hoe leest hij dat in? Het zou me niets verbazen als het uitlezen van 1 kolom met 10000 tekens een stuk langzamer is dan 10 kolommmen met 1000 tekens, enz.

Maar dat weet je niet, want dat heb je niet getest.

//edit
als antwoord op de vraag: waarom zou dat sneller zijn? zou ik willen geven: 'omdat er hier mensen zijn die er echt verstand van hebben, en die zeggen dat'.

[ Voor 8% gewijzigd door Anoniem: 25556 op 21-06-2004 17:56 ]

[bigbeng]

Sybr_E-N schreef op 21 juni 2004 @ 17:50:
[...]
Alleen ik snap niet hoe jij erbij komt dat joins juist langzamer zouden zijn? Totzover mij op school/ boeken/ internet is geleerd dat joins er juist voor zijn uitgevonden om data zo snel en effiecient mogelijk op te halen uit de database.

Het openen van indexen op meerdere tabellen en het matchen van join voorwaarden brengen wel kosten in performance met zich mee. In de meeste gevallen valt dat te verwaarlozen, maar niet altijd. De precieze redenen weet ik niet meer, maar dit is wat een (voor zover ik weet goede) dba-er me eens vertelde.

[GlowMouse]

bigbeng schreef op 21 juni 2004 @ 17:55:
In de meeste gevallen valt dat te verwaarlozen, maar niet altijd. De precieze redenen weet ik niet meer

Op strings joinen is meestal een stuk trager. Op geïndexeerde integers joinen gaat snel.

[Anoniem: 97422]

curry684 schreef op 21 juni 2004 @ 17:42:
[...]

That's the true spirit: als het niet snel genoeg is hebben we snellere hardware nodig, want aan onze software kan het niet liggen! \o/

Van dat soort volk krijgt de hele IT-branche helaas een slechte naam

Als een team goede software maakt en men weet dat het evenwicht tussen onderhoudbaarheid en performance is bereikt, dan is het een stuk goedkoper en slimmer om na een extra evaluatie een extra server erbij te zetten dan te gaan sleutelen aan de code.

[Anoniem: 97422]

Anoniem: 25556 schreef op 21 juni 2004 @ 17:54:
Dusty en curry: let it go. Jullie zijn imo wel erg druk bezig jullie eigen gelijk te halen en willen persé aantonen dat TS geen verstand heeft van databases. De vraag 'hoeveel normaalvormen zijn er?' wordt alleen gesteld om aan te tonen dat TS er geen verstand van heeft, een bewijs waar niemand wat aan heeft.

Dan voor TS: Je zit hier niet met domme nitwits te praten. Je geeft zelf aan dat je aan het optimaliseren bent, en dat je in de fase van 'de kleine druppels' beland bent.

Als je dan hier komt vragen om advies vind ik het wel zo netjes om dat advies op z'n minst eens een kans te geven, of er op z'n minst geen uitspraken over te doen.

Je beweert dat jouw oplossing sneller is, zonder de geadviseerde oplossing zelfs maar getest te hebben, nogal logisch dat je daar opmerkingen over krijgt. 'Ja maar ik heb gebenched'; dat heb je dus niet. Althans niet de door DRM voorgestelde oplossing.

Zeg dan gewoon 'die oplossing wil ik niet, en daar heb ik geen goede redenen voor, basta'.

Needles to say dat de oplossing die je nu hebt meer is dan een hack; hij is gewoon extreem smerig, zo ongeveer het schoolvoorbeeld van 'meest foute actie om uit te halen'. Kan zo de boekjes in, nofi. Het ophalen van afzonderlijke kolommen is langzaam, weet je wat: we pleuren alles in 1 kolom.

Hoe gaat MySQL om met zulke brede velden? Wat voor datatype hangt hij daaraan, hoe leest hij dat in? Het zou me niets verbazen als het uitlezen van 1 kolom met 10000 tekens een stuk langzamer is dan 10 kolommmen met 1000 tekens, enz.

Maar dat weet je niet, want dat heb je niet getest.

//edit
als antwoord op de vraag: waarom zou dat sneller zijn? zou ik willen geven: 'omdat er hier mensen zijn die er echt verstand van hebben, en die zeggen dat'.

Dit is een mooi voorbeeld hoe je niet discussiert Wat je leert op school kan niet in alle gevallen toegepast worden en is in sommige gevallen zelfs verkeerd. Als je m'n replies leest kun je lezen dat ik redenen aangeef. DRM oplossing is logische wijze langzamer dan oplossing 2. , dat weet iedereen die net met databases begonnen is. Mag een OP niet op reacties die hij krijgt reageren?

[dusty]

Anoniem: 25556 schreef op 21 juni 2004 @ 17:54:
Dusty en curry: let it go. Jullie zijn imo wel erg druk bezig jullie eigen gelijk te halen en willen persé aantonen dat TS geen verstand heeft van databases. De vraag 'hoeveel normaalvormen zijn er?' wordt alleen gesteld om aan te tonen dat TS er geen verstand van heeft, een bewijs waar niemand wat aan heeft.

Ik heb reeds opgegeven om de gedachten van de TS te veranderen, wat ik wel kan doen is dat andere mensen die deze topic vinden niet dezelfde fout gaan maken en denken dat de TS gelijk heeft.

De vraag hoeveel normaalvormen er zijn is juist vanwege zijn verhaaltje dat hij niet heeft genormaliseerd en zijn reden qua snelheid. Vrijwel iedereen weet dat er 5 normalisatie vormen zijn, maar de meeste mensen gaan ook alleen maar normaliseren tot de 3e normaalvorm. Juist in die twee laatste normalisatie stappen komen dubbele waardes terug om het geheel sneller te maken waar dat nodig is. (denk aan het aantal topics in een sub-forum opslaan in de tabel waar de forum is gedefinieerd, immers wilt niemand de hele tijd alle topics gaan tellen.)

Zijn reden om dus niet te gaan normaliseren slaat nergens op, mocht hij niet weten dat er 5 normalisatie vormen zijn, kan ik begrijpen waarom hij die reden gaf, en had ik deze informatie aan hem kunnen geven, waardoor hij verder in normalisatie kan gaan kijken en meer snelheid winst kan behalen. Mocht hij wel weten dat er 5 normalisatie vormen waren dan zou hij zichzelf tegenspreken met zijn statement waarom hij niet heeft genormaliseerd. dus zou ik die vraag alleen maar stellen om aan te geven dat hij fout zat ( als hij het fout had beantwoord) was het inderdaad alleen maar geweest om te laten zien dat hij fout was, echter was dat niet mijn opzet, ik wou aantonen dat hij juist wel moet normaliseren, waardoor hij juist wel snelheid winst gaat maken. Juist vanwege dat antwoord zouden andere mensen er wel wat aan hebben, misschien de TS niet, immers verwacht(e) ik niet dat de TS zijn mening bij zou stellen.

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 18:15:
[...]
DRM oplossing is logische wijze langzamer dan oplossing 2. , dat weet iedereen die net met databases begonnen is.

Het is voor mij nogal een tijdje geleden dat ik met database's ben begonnen, zou jij mij dan die logische wijze kunnen uitleggen? want daar ben ik persoonlijk wel benieuwd naar.

[Anoniem: 97422]

Sybr_E-N schreef op 21 juni 2004 @ 17:50:
[...]


Als jij het zo goed weet, waarom open je dan een topic met een vraag waarop je zelf het antwoord al weet? Er worden serieuze suggesties gedaan en op/aan-merkingen gemaakt over jouw standpunt. Waarom sla je die zomeer in de wind?

Ik kon inderdaad beter bij phpbuilder.com m'n vraag kwijt, daar geven ze direct antwoord wat sneller is en wat niet :-) Maar al die suggesties en de discussie die er op volgt is ook best handig. Van OLAP had ik nooit gehoord, maar ik ga er toch eens naar kijken, misschien is het wel handig voor andere projecten. Wie weet.

Als jij duidelijk en helder voor de geest kan halen hoe een relationele database in elkaar steekt kom je er al snel achter dat zowel '150 kolomen' als '2 a 3 kolomen met '|' gesplitte data' niet efficient is. Ja, wellicht als je er 10 rows in opslaat, maar hoe gaat het zich uitpakken wanneer er 600.000 of meer rows in je database staan? Hier kom je alleen maar achter door uitgebreide te gaan lopen testen en de verschillende opties met elkaar te gaan vergelijken.

Ik heb m'n simpele benchmark gedaan om data zoals deze in de database stonden (wel een kopie gemaakt), dus dat zit wel snor.

[whoami]

Als je nu 150 kolommen hebt, of 2 kolommen waarin je al die velden concateneert, dat maakt niet uit.
Het is beiden niet efficiënt; al die (irrelevante) gegevens moeten in het geheugen geladen worden en over het netwerk verzonden worden.

Daarbij komt nog eens dat de integriteit van je data op die manier niet te bewaken is, dat je opzet innefficiënt is mbt UPDATE's / INSERT's / DELETE's.....

Maar goed, je kunt zo evengoed tegen een steenezel praten. Ik stop hier geen energie in.

[Anoniem: 97422]

dusty schreef op 21 juni 2004 @ 18:20:
[...]

Het is voor mij nogal een tijdje geleden dat ik met database's ben begonnen, zou jij mij dan die logische wijze kunnen uitleggen? want daar ben ik persoonlijk wel benieuwd naar.

Voor de laatste keer:
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. En daarvoor hoe je geen benchmark te maken dat kun je aanvoelen. (effecten van explode had ik wel gebenchmarkt, want dat is lastig aan te voelen)

[drm]

kogels:
En daarvoor hoe je geen benchmark te maken dat kun je aanvoelen. (effecten van explode had ik wel gebenchmarkt, want dat is lastig aan te voelen)

Ik kan wel aanvoelen dat dit nergens toe leidt.

Ik stel voor dat je of met harde feiten komt (en niet van die halfzachte intuitieve kletskoek) of dat we met z'n allen dit topic laten voor wat het is.

FTR: je komt hier om advies vragen en gaat vervolgens verdedigen dat je eigen methode toch eigenlijk wel beter is om dat dat nou eenmaal goed aanvoelt. Excuse my french, maar dat is echt bullcrap waar niemand iets mee opschiet. NOFI.

[Anoniem: 97422]

whoami schreef op 21 juni 2004 @ 18:26:
Als je nu 150 kolommen hebt, of 2 kolommen waarin je al die velden concateneert, dat maakt niet uit.
Het is beiden niet efficiënt; al die (irrelevante) gegevens moeten in het geheugen geladen worden en over het netwerk verzonden worden.

Daarbij komt nog eens dat de integriteit van je data op die manier niet te bewaken is, dat je opzet innefficiënt is mbt UPDATE's / INSERT's / DELETE's......

Als je m'n replies had gelezen had je kunnen weten dat performance erg belangrijk is, dus integriteit is niet belangrijk als het de performance negatief beinvloed. Hoe lang UPDATE's duren is toch niet belangrijk? De meeste queries zullen SELECT's zijn, dus daar moet je je op concentreren. Ik maak overigens nu van de 150 kolommen 1 kolom.

Dit is de beste (wbt performance) oplossing die bij mij bekend is.

[Anoniem: 97422]

drm schreef op 21 juni 2004 @ 18:33:
[...]
FTR: je komt hier om advies vragen en gaat vervolgens verdedigen dat je eigen methode toch eigenlijk wel beter is om dat dat nou eenmaal goed aanvoelt. Excuse my french, maar dat is echt bullcrap waar niemand iets mee opschiet. NOFI.

Dat is logisch nadenken. Laat ik het dan anders zeggen:

Wie vind het volgende niet waar?
--------------
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.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

[coubertin119]

Anoniem: 97422 schreef op 21 juni 2004 @ 18:35:
[...]

Dat is logisch nadenken. Laat ik het dan anders zeggen:

Wie vind het volgende niet waar?
--------------
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.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

Logica haalt het ook niet altijd. Kan jij verkiezingsuitslagen voorspellen, puur door na te denken welke partijen er zijn?

[drm]

kogels:
Wie vind het volgende niet waar?

Het is geen kwestie van vinden of logisch nadenken, het is een kwestie van weten waar je mee bezig bent. En om je vraag te beantwoorden: als je het topic even doorleest kom je o.a. dusty, whoami, curry en mijzelf tegen die het "niet waar vinden". Laten dat nou de mensen zijn die wel eens een keer een databaseje in elkaar gedraaid hebben en rekening hebben moeten houden met performance. En laten dat dan ook projecten geweest zijn die niet zomaar in één of ander obscuur huis-, tuin- en keukensfeertje hingen...

Je hebt toch zelf ook wel in de gaten dat dit een nietes/welles verhaal wordt? Op dit moment is het heel simpel: kom met steekhoudende argumenten of 't topic gaat dicht om een hoop ergernis te voorkomen. Je hebt nu een aantal keren de kans gekregen je punten te onderbouwen en komt elke keer weer terug met 1 of andere intuitie waar geen touw aan vast te knopen is. Sorry, maar dat is geen manier van discussieren, in ieder geval niet één die we hier graag zien.

[dusty]

Anoniem: 97422 schreef op 21 juni 2004 @ 18:35:
[...]
Wie vind het volgende niet waar?
[...]

De snelheid van 150 records van 3 kolommen kan je niet vergelijken met de snelheid van 1 record met 150 kolommen.

[ Voor 41% gewijzigd door dusty op 21-06-2004 18:46 . Reden: Kwoot verkleining ]

[Infinitive]

Anoniem: 97422 schreef op 21 juni 2004 @ 18:35:
Wie vind het volgende niet waar?
--------------
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.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

Je vergeet er nog bij te zeggen dat je geïnteresseerd bent in al de waarden die in alle kolommen staan. En dat je dit maar één keer per page load ophaald.

Op zich kan je er weinig over zeggen bij dit soort kleine aantallen. Je weet niet wat de query analyser doet. Of wat het effect is van het opslaan/ophalen van een grote string tegenover kleine strings. Om nog maar te zwijgen over caching en het opbouwen van de resultset. Waarschijnlijk moet die ene string van jouw eerst wel volledig in het geheugen ingelezen worden voordat die verzonden wordt. Als je kleine resultaten hebt, dan vliegen de eerste resultaten al over de socket voordat de laatste opgehaald is. Enz. Enz.

[ Voor 4% gewijzigd door Infinitive op 21-06-2004 18:50 ]

[Anoniem: 64834]

offtopic:
Als je 150 cols nodig hebt, lijkt het vrijwel zeker dat er een heleboel info dubbel opgeslagen wordt. Dit komt de performance ook niet tengoede, immers als er gezocht moet worden is volstaat een zoek opdracht naar 1 keer de betreffende info en niet N keer een zoek opdracht naar dezelfde info. Bovendien is de kans dan groter dat de betreffende info gecached wordt.

Kortom normaliseren naar tenminste de 4de normaalvorm... En vooral niet bokken met *h*-hacks, dat maakt de echte programmeurs kwaad.

[ Voor 9% gewijzigd door Anoniem: 64834 op 21-06-2004 18:51 ]

[Yoshi|IA2]

Anoniem: 97422 schreef op 21 juni 2004 @ 18:35:
[...]

Dat is logisch nadenken. Laat ik het dan anders zeggen:

Wie vind het volgende niet waar?
--------------
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.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

Ik ben ook nog maar pas met db's bezig (ttz: ik volgend 3e IK - DB op het LUC/tUL), en ik zou er niet aan denken om zo'n smerige boel op te zetten...
Als ik zoiets als project zou afgeven, dan ben ik zeker dat de prof. zegt dat ik volgend jaar mag terugkomen...

Wij gebruiken in projecten ook soms rip methodes omdat een db niet altijd vliegt, en we het soms wel kunnen laten vliegen met kleine hacks, maar tenminste verantwoorden wij de gemaakte keuzes met harde feiten.

[Anoniem: 97422]

coubertin119 schreef op 21 juni 2004 @ 18:38:
[...]
Logica haalt het ook niet altijd. Kan jij verkiezingsuitslagen voorspellen, puur door na te denken welke partijen er zijn?

Dus jij vind dat:
---------------------
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)

?

[Anoniem: 97422]

Anoniem: 64834 schreef op 21 juni 2004 @ 18:50:

offtopic:
Als je 150 cols nodig hebt, lijkt het vrijwel zeker dat er een heleboel info dubbel opgeslagen wordt. Dit komt de performance ook niet tengoede, immers als er gezocht moet worden is volstaat een zoek opdracht naar 1 keer de betreffende info en niet N keer een zoek opdracht naar dezelfde info. Bovendien is de kans dan groter dat de betreffende info gecached wordt.

Ik kan je het niet kwalijk nemen, maar ik heb in 1 van m'n replies gezegd waarvoor de tabel diende

[Anoniem: 97422]

Infinitive schreef op 21 juni 2004 @ 18:45:
[...]


Je vergeet er nog bij te zeggen dat je geïnteresseerd bent in al de waarden die in alle kolommen staan. En dat je dit maar één keer per page load ophaald.

Zie m'n orginele bericht:
"Het script heeft alle waarden in alle kolommen nodig"

Op zich kan je er weinig over zeggen bij dit soort kleine aantallen. Je weet niet wat de query analyser doet. Of wat het effect is van het opslaan/ophalen van een grote string tegenover kleine strings. Om nog maar te zwijgen over caching en het opbouwen van de resultset. Waarschijnlijk moet die ene string van jouw eerst wel volledig in het geheugen ingelezen worden voordat die verzonden wordt. Als je kleine resultaten hebt, dan vliegen de eerste resultaten al over de socket voordat de laatste opgehaald is. Enz. Enz.

Ik heb in m'n replies een aantal voorwaarden genoemt, zoals de gemiddelde lengte van de waarden. Maar dit heeft niet veel nut, omdat ik alle waarden moet hebben.

[Anoniem: 97422]

dusty schreef op 21 juni 2004 @ 18:45:
[...]

De snelheid van 150 records van 3 kolommen kan je niet vergelijken met de snelheid van 1 record met 150 kolommen.

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.

[Anoniem: 97422]

drm schreef op 21 juni 2004 @ 18:44:
[...]
Het is geen kwestie van vinden of logisch nadenken, het is een kwestie van weten waar je mee bezig bent. En om je vraag te beantwoorden: als je het topic even doorleest kom je o.a. dusty, whoami, curry en mijzelf tegen die het "niet waar vinden". Laten dat nou de mensen zijn die wel eens een keer een databaseje in elkaar gedraaid hebben en rekening hebben moeten houden met performance. En laten dat dan ook projecten geweest zijn die niet zomaar in één of ander obscuur huis-, tuin- en keukensfeertje hingen...

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.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

Mijn logische redenering blijkt dus correct te zijn. Als iemand het beter weet ben ik daar zeer geinteresseerd en kan ik m'n logische redenering aanpassen. Ik zal vanavond of morgen de bovenste stelling op wat andere boards posten en kijken of deze stelling onjuist is.

[GlowMouse]

Het leuke aan deze stelling is dat je hem makkelijk kunt testen. Hoeveel rijen heeft jouw huidige database/zal hij gaan hebben?

[Gomez12]

FF kijken hoor, welke van de 2 stellingen denk je dat gecached wordt??? De select / explode of de enkele select???

Bovendien snap ik niet helemaal waar de discussie over gaat, want volgens mij doe je deze query een keer per pagina. dus of je moet een paar duizend pageviews per seconde hebben of het is gewoon optimaliseren naar het niets toe ( als het al sneller is met echt benchen. )

En wat heb je nou precies gebencht??? Want ik zie hierboven wel een leuk scriptje staan wat een keer de eerste query daarna een keer de tweede query. Wauw goeie bench. Doe hem nog een keer en je krijgt er een ander resultaat. Zoek eens op testen / benchen.

btw curry: wat is een profiler???
Nog nooit van gehoord, maar zit over het algemeen dan ook alleen maar wat te spelen met mysql / access db's

curry684 schreef op 21 juni 2004 @ 17:20:
[...]

Merk ik niet veel van. I repeat: heb je al een profiler gebruikt?