Database keuze i.v.m. performance

[vmsw]

Afgesplitst van Database keuze

Zou ik dit topic nog iets mogen verdiepen op het gebied van performance? Wat is jullie mening over MySQL (InnoDB en/of MyISAM) en MSSQL op het gebied van snelheid?
En dat op een SSD-schijf, waardoor random inlezen niet heel veel uitmaakt (immers sorteert InnoDB, welk voordeel hierdoor deels vervalt).

Hiervoor reeds veel gezocht via Google, echter weinig recente/volledige informatie.

Of moet ik hiervoor een nieuw topic maken?

[ Voor 6% gewijzigd door Creepy op 13-09-2010 15:21 ]

[RobIII]

vmsw schreef op maandag 13 september 2010 @ 09:55:
Zou ik dit topic nog iets mogen verdiepen op het gebied van performance? Wat is jullie mening over MySQL (InnoDB en/of MyISAM) en MSSQL op het gebied van snelheid?
En dat op een SSD-schijf, waardoor random inlezen niet heel veel uitmaakt (immers sorteert InnoDB, welk voordeel hierdoor deels vervalt).

Meten = weten. Vaak is het allemaal nogal afhankelijk van omstandigheden. Mijn (subjectieve!) mening is dat MSSQL anyday MySQL eruit performed maar daar zou ik niet op af gaan. Ik zou als ik jou was gewoon eens een representatieve DB opzetten in beide en dan gewoon benchen. Maar laten we wel wezen; het zal gemiddeld genomen hooguit een paar procent schelen en met wat dikkere hardware los je dat dan wel weer op. Verwacht je nu al performance issues?

[Hydra]

vmsw schreef op maandag 13 september 2010 @ 09:55:
Zou ik dit topic nog iets mogen verdiepen op het gebied van performance? Wat is jullie mening over MySQL (InnoDB en/of MyISAM) en MSSQL op het gebied van snelheid?
En dat op een SSD-schijf, waardoor random inlezen niet heel veel uitmaakt (immers sorteert InnoDB, welk voordeel hierdoor deels vervalt).

Snelheid van wat? Schrijven? Lezen? Wat je performance gaat zijn is nogal afhankelijk van je type operaties. MyISAM is snel als je vooral selects doet, maar als er veel deletes in de mix zitten dan gaan die table-locks je in de weg zitten. Je kunt niet zeggen dat DB A 1000 trx/sec kan doen, en DB B slechts 900 trx/sec. Je kunt alleen vaststellen of voor jouw situatie een DB beter performt dan een andere, en daarvoor zul je zelf tests moeten bedenken.

[PolarBear]

Wolfboy schreef op dinsdag 31 augustus 2010 @ 18:08:
[...]
Een automatische optimizer (al ben ik zelf nogal huiverig voor dergelijke tools).

Je moet nog steeds je verstand gebruiken, maar ik vind het maar wat handig dat SQL 2008 laat zien als hij indexen mist.

[P_de_B]

vmsw schreef op maandag 13 september 2010 @ 09:55:
Zou ik dit topic nog iets mogen verdiepen op het gebied van performance? Wat is jullie mening over MySQL (InnoDB en/of MyISAM) en MSSQL op het gebied van snelheid?
En dat op een SSD-schijf, waardoor random inlezen niet heel veel uitmaakt (immers sorteert InnoDB, welk voordeel hierdoor deels vervalt).

Hiervoor reeds veel gezocht via Google, echter weinig recente/volledige informatie.

Of moet ik hiervoor een nieuw topic maken?

Have fun: http://www.tpc.org/

En nee, dit is niet écht een antwoord op je vraag. De juiste antwoorden zijn al door RobIII en Hydra gegeven, waarbij ik rustig durf te stellen dat áls je deze vraag hier moet stellen het antwoord waarschijnlijk niet relevant is voor je.

[HansvDr]

Wolfboy schreef op dinsdag 31 augustus 2010 @ 18:08:
[...]
MSSQL bied ook wel wat meerwaarde voor die duizenden. Een mooie grafische ontwikkelomgeving voor queries, tabellen en meer. Een automatische optimizer (al ben ik zelf nogal huiverig voor dergelijke tools). Of het de prijs verantwoord weet ik niet, maar er is iets voor te zeggen

Ook met de gratis express versie heb je vele tools tot je beschikking en voor heel veel applicaties en sites is de express versie ruim voldoende.

[vmsw]

Gaat vooral om selects, en inderdaad heb ik nu al last van performance. Vooral omdat ik bijv. de relaties als objecten behandel, en een relatie meerdere subobjecten heeft, zoals contactpersonen (die weer telefoonnummers en adressen heeft).

Relatie
- Contactpersoon (1..*)
-- Telefoonnummer (0..*)
-- E-mailadres (0..*)
- Adres (1..*)
- Studentgegevens (1..*)
-- Studiegegevens (1..*)

Optioneel:
- lidgegevens (0..1)
- bedrijfsgegevens (0..1)
- lidmaatschappen (0..*)

Als je dan een ledenlijst maakt, waar de naam + adres + telefoonnummergegevens op staan, levert dit meerdere selects per lid op, en met 4000 leden krijg je wel een performanceprobleem. Voornamelijk ook omdat het vrij veel selects zijn (immers moet je per lid de adressen & contactpersonen & telefoonnummers etc. apart opvragen, immers kunnen dit er meerdere zijn.

En ik ben er niet over uit of het beter is om bedrijfsgegevens en lidgegevens in een apart tabel te zetten, of gewoon het relatie-tabel uit te breiden met deze velden, die afhankelijk van of het een bedrijf óf lid is wel of geen gegevens bevatten... Maar dat terzijde.

[P_de_B]

Als je met deze hoeveelheden een performanceprobleem hebt ligt dat écht in jou code/inrichting en niet in de performance van de database. Wat voor queries gebruik je, welke indexen heb je gedefinieerd?

Je weet wat een join is?

[ Voor 20% gewijzigd door P_de_B op 13-09-2010 14:59 ]

[RobIII]

vmsw schreef op maandag 13 september 2010 @ 14:57:
Als je dan een ledenlijst maakt [...] levert dit meerdere selects per lid op [...] 4000 leden

Dus een ledenlijst uitdraaien kost je ruim 10.000 selects? Dan zou ik daar eens mee beginnen iets aan te doen

[edit]
Wat P_de_B dus zegt.

[ Voor 4% gewijzigd door RobIII op 13-09-2010 15:02 ]

[cariolive23]

vmsw schreef op maandag 13 september 2010 @ 14:57: en met 4000 leden krijg je wel een performanceprobleem.

Oh, dat is nieuw, mijn databases zijn nog niet op de hoogte van deze nieuwe "eisen", gaan als een speer op datasets die nog een heel stuk groter zijn. En nee, dat is geen bijzondere hardware.

Voornamelijk ook omdat het vrij veel selects zijn (immers moet je per lid de adressen & contactpersonen & telefoonnummers etc. apart opvragen, immers kunnen dit er meerdere zijn.

Ah, een beroerde applicatie die denkt dat 'ie slimmer is dan een DBMS. Dan is het logisch dat je een probleem hebt, je vecht nu tegen jouw database. En dat ga je verliezen, sterker nog, je hebt blijkbaar al verloren.

Zet de database voor jou aan het werk, gooi eens wat slimme queries die kant op en zie de performance ineens een factor 100 verbeteren. Met een paar leden en wat adresjes mag je nooit problemen krijgen, dit moet gewoon vlot kunnen werken. Databases zijn uitgevonden voor het werken met miljoenen records, 4000 leden en hun adressen zullen dan echt geen probleem zijn.

[Creepy]

vmsw schreef op maandag 13 september 2010 @ 09:55:
Zou ik dit topic nog iets mogen verdiepen op het gebied van performance? Wat is jullie mening over MySQL (InnoDB en/of MyISAM) en MSSQL op het gebied van snelheid?
En dat op een SSD-schijf, waardoor random inlezen niet heel veel uitmaakt (immers sorteert InnoDB, welk voordeel hierdoor deels vervalt).

Hiervoor reeds veel gezocht via Google, echter weinig recente/volledige informatie.

Of moet ik hiervoor een nieuw topic maken?

Als je het niet zeker weet: vraag het even aan 1 van de mods. In dit geval was een los topic echt beter.

Mocht het nog niet duidelijk zijn: verdiep je in JOINS. Als je voor 4000 personen 10.000 of meer queries moet stellen om alle gegevens op te halen dan doe je iets verkeerd. Het kan in totaal met 1 query.

[remco_k]

Ik kan het alleen maar eens zijn met al het bovenstaande.
Met een database-je waar 4000 contactjes inzitten behoor je met geen enkel type server (MySQL/MSSQL/Whatever) een performance probleem te hebben.
Zelfs niet op sterk verouderde hardware uit het jaar 1920. Hoe groot is die database nou eenmaal in totaal? Kleiner of in de buurt van 50 MB?

Het zal echt voornamelijk om optimalisatie gaan aan de client kant, je applicatie dus die de queries doet. Zoals gezegd, als je die goed maakt, zou je zelfs kunnen spreken van nog maar 1 query met een performance vooruitgang factor heel erg hoog.
Geen enkele nieuwe database server cq nieuwe snellere hardware gaat die vooruitgang evenaren of daarvan in de buurt komen.

[ Voor 6% gewijzigd door remco_k op 13-09-2010 17:00 ]

[Hydra]

Heh. Ik heb WAY back bij een webdesignbedrijfje gewerkt als bijbaantje tijdens m'n studie waar de 'baas' ook zat te klagen over de zoekperformance van het searchdeel van hun in-house ontwikkelde CMS. Na wat graven kwam ik tot m'n schok tot de ontdekking dat er een select * where bla=$invoer gedaan werd, waarvan alleen de IDs in een "Item" object gefrut werd, waarna voor al die items een voor een nog eens een select gedaan werd. Dus voor een resultaat van een search met N resultaten werden altijd N+1 selects gedaan.

[Wolfboy]

Hydra schreef op maandag 13 september 2010 @ 17:47:
Heh. Ik heb WAY back bij een webdesignbedrijfje gewerkt als bijbaantje tijdens m'n studie waar de 'baas' ook zat te klagen over de zoekperformance van het searchdeel van hun in-house ontwikkelde CMS. Na wat graven kwam ik tot m'n schok tot de ontdekking dat er een select * where bla=$invoer gedaan werd, waarvan alleen de IDs in een "Item" object gefrut werd, waarna voor al die items een voor een nog eens een select gedaan werd. Dus voor een resultaat van een search met N resultaten werden altijd N+1 selects gedaan.

Het zal je verbazen hoeveel websites het met dergelijke queries doen doordat ORM systemen alles pas tijdens het parsen van de pagina opvragen.

Pak je gemiddelde ORM systeem, voer het een resultset en spreek een foreign key aan... yes, dat is per rij een extra query

@TS: probeer alles in 1 of eventueel een paar queries te doen als het niet in 1 query past. Als je duizenden queries per pagina doet dan gaat een andere database ook weinig helpen.

[cariolive23]

ORM: Object Relationele Mismatch. Een grotere garantie op performanceproblemen bestaat er niet.

Met een klein beetje SQL-ervaring en een snufje boerenverstand, haal je ORM links en rechts in. Grappig voor een prototype of een toepassing die weinig performance eisen stelt, een drama wanneer je meer nodig hebt. Gelukkig staan de meeste ORM-tools wel toe dat je eigen SQL schrijft, maar wat is dan nog de toegevoegde waarde van de ORM? Simpele SQL kun je zelf wel schrijven en lastige SQL is te moeilijk voor ORM en moet je dus ook zelf schrijven... Er zijn zelfs leveranciers die hier geld voor durven te vragen.

[yade]

Ik ben het eens met dat 4000 records er niet veel zijn en welke database ook daar geen moeite mee zou moeten hebben.

Een SSD gaat je meer helpen met schrijven dan met lezen. De pages met de data worden waarschijnlijk al netjes in het geheugen ge-cachet.

Zoek het in je query's en indexen.

@Wolfboy

Bij een beetje fatsoenlijke ORM tool kun je lazy loading uitzetten, als je het al niet expliciet aan moet zetten, en de ORM tool zal dan proberen het aantal roundtrips naar de database te beperken.

[cariolive23]

En dan vliegen de LEFT JOIN's je weer om de oren, ook wanneer ze niet nodig zijn. PostgreSQL heeft met versie 9.0 (die volgende week wordt vrijgegeven) een mechanisme gemaakt om dit soort kansloze JOIN's te optimaliseren en gewoon te negeren wanneer dat kan. En dat werkt goed kan ik je vertellen. Toch jammer dat zoiets nodig is om foute SQL weg te werken.

Een ander pijnpunt zijn cascading deletes die de ORM graag wil uitvoeren, terwijl de database dit veel sneller kan. Of bv. een 100.000 records verwijderen op basis van het id, die één voor één met een eigen query worden verwijderd of met één groot IN() statement grandioos gaan mislukken (technisch mislukt, de IN wordt te groot). Gewoon een temp table met de id's dan even join-en, dat is niet iets wat de ORM kan bedenken.

Geavanceerde mogelijkheden zoals windowing functions of recursieve queries, daar hoef je het al helemaal niet over te hebben.

Performance en ORM, geen goed koppel.

[B-Man]

Om meteen te roepen dat performance en ORM geen goed koppel zijn vind ik te kort door de bocht. Je kunt met vrijwel ieder ORM eenvoudig instellen dat bijvoorbeeld via een subselect alle gerelateerde child-rows opgehaald worden. Of, mocht je dat interessanter vinden: batch fetching (middels de PK X records per keer).

Slecht gebruik maken van een ORM leidt tot slechte performance; maar dat is met iedere tool zo. Een aantal posts in dit topic laten maar weer zien dat je met het zelf schrijven van SQL ook heel eenvoudig slechte performance kunt hebben.

Een zichzelf respecterend ORM kan cascading deletes ook door de database laten uitvoeren, geen argument tegen het gebruik van een ORM dus.

Je voorbeeld (100.000 records verwijderen) is een uitzondering, en uitzonderingen vereisen altijd een menselijke blik. Precies zoals je voorstelt dat je zelf een temp table moet aanmaken via SQL zul je, als je een ORM gebruikt, hier ook wat trucs voor moeten gebruiken.

Verder zijn ook complexere zaken als recursieve queries via een ORM af te vangen. De vraag is of je dat ook wil, maar dat terzijde. Je kunt er altijd voor kiezen om een VIEW aan te maken (complexe query door een DBA laten bouwen), en die middels een ORM te queryen.

Kort gezegd: use the right tool for the right job. Weet je niet wat je doet, dan moet je er vanaf blijven; Iemand die weinig kaas gegeten heeft van databases zal een ORM mogelijk slecht inzetten, maar kan ook geen fatsoenlijke queries schrijven. Iemand die goed thuis is in SQL kan zeer waarschijnlijk prima uit de voeten met een ORM, en waar nodig finetunen en queries overriden.

Het blijft me een raadsel waarom zoveel mensen "tegen" ORMs zijn. Ja, het is makkelijk om er apps mee te bouwen die out-of-the box slechte performance hebben, maar dat is ook eenvoudig te doen als je direct met SQL aan de slag gaat.

ontopic: zoals reeds door anderen gezegd: "performance" van een database is afhankelijk van veel factoren. Meten = weten. Verder is het belangrijk om van te voren vast te stellen wat "goed genoeg" is.

[ Voor 5% gewijzigd door B-Man op 13-09-2010 23:21 ]

[Wolfboy]

yade schreef op maandag 13 september 2010 @ 18:28:
Ik ben het eens met dat 4000 records er niet veel zijn en welke database ook daar geen moeite mee zou moeten hebben.

Een SSD gaat je meer helpen met schrijven dan met lezen. De pages met de data worden waarschijnlijk al netjes in het geheugen ge-cachet.

Zoek het in je query's en indexen.

@Wolfboy

Bij een beetje fatsoenlijke ORM tool kun je lazy loading uitzetten, als je het al niet expliciet aan moet zetten, en de ORM tool zal dan proberen het aantal roundtrips naar de database te beperken.

Dat weet ik. Maar als je daarmee per rij 10 andere rijen ophaalt en dat doe je met 10-20 verschillende eigenschappen dan krijg je opeens een gigantische resultset.

In veel gevallen is mijn ervaring dat je bij een orm 2 opties hebt.
1. lazy loading (i.e. veel queries)
2. relaties preloaden (zeer complexe queries met enorme resultsets)

Het zou fijn zijn als ORM's een 3e optie aan zouden bieden hiervoor, in plaats van een LEFT JOIN een aparte select voor alles uit die tabel (als het een 1-to-many relatie is dan). Ik heb in ieder geval al eens gehad dat het ophalen van zo'n 25 rijen uit de database zo'n 2000 rijen teruggaf doordat het ORM systeem alles erbij probeerde te joinen. In dat geval werken zelfs de losse selects nog een stuk beter.

[Hydra]

B-Man schreef op maandag 13 september 2010 @ 23:20:
Het blijft me een raadsel waarom zoveel mensen "tegen" ORMs zijn. Ja, het is makkelijk om er apps mee te bouwen die out-of-the box slechte performance hebben, maar dat is ook eenvoudig te doen als je direct met SQL aan de slag gaat.

Inderdaad. Dat voorbeeld wat ik aandroeg was ook puur 'met de hand' geprogrammeerd. Ook leuk trouwens: in dat CMS bestond alles uit items met verschillende types. Pagina's, plaatjes, alineas, tekst, etc. waren allemaal items met parent-child related. Voordat ik er mee aan de slag mocht, werd als een pagina verwijderd werd alleen de parent-pagina verwijderd, alles wat er onder hing bleef lekker in de DB zitten en werd ook gevonden als je ze zocht, maar omdat hun parent niet gevonden kon worden werden ze gewoon niet getoond.

[EfBe]

cariolive23 schreef op maandag 13 september 2010 @ 18:22:
ORM: Object Relationele Mismatch. Een grotere garantie op performanceproblemen bestaat er niet.

Volgens mij begrijp je er weinig van.

Met een klein beetje SQL-ervaring en een snufje boerenverstand, haal je ORM links en rechts in.

Trust me, dat lijkt me uitgesloten. Wat jij in deze thread loopt te roepen is niet echt veel meer dan wat luid gebral zonder feiten. Wat je aanhaalt is het SELECT N+1 probleem. Maar dat is niet een resultaat van het gebruik van een O/R mapper, maar van het slecht gebruiken van functionaliteit, en je kunt SELECT N+1 bv ook krijgen bij een functionele DAL met procs.

Grappig voor een prototype of een toepassing die weinig performance eisen stelt, een drama wanneer je meer nodig hebt. Gelukkig staan de meeste ORM-tools wel toe dat je eigen SQL schrijft, maar wat is dan nog de toegevoegde waarde van de ORM? Simpele SQL kun je zelf wel schrijven en lastige SQL is te moeilijk voor ORM en moet je dus ook zelf schrijven... Er zijn zelfs leveranciers die hier geld voor durven te vragen.

*maakt kromme tenen weer recht*

Je hoeft helemaal niet je eigen SQL te schrijven om goede performance uit een O/R mapper te halen, je moet alleen de features goed gebruiken. Het SELECT N+1 probleem is de grootste, en ook de makkelijkste om te rekening mee te houden. Je wint bv veel performance door eager loading queries die met een betere O/R mapper ook nog voorzien kunnen worden van filters etc., daar kan jouw hand-geschreven SQL niet tegenop, want die queries zijn per subgraph elke keer totaal anders, plus moet je dan zelf de graph-merging schrijven buiten de SQL om. Oh wacht, jij wilt dat natuurlijk gaan doen met joins, want je denkt slim te zijn.

cariolive23 schreef op maandag 13 september 2010 @ 18:48:
En dan vliegen de LEFT JOIN's je weer om de oren, ook wanneer ze niet nodig zijn. PostgreSQL heeft met versie 9.0 (die volgende week wordt vrijgegeven) een mechanisme gemaakt om dit soort kansloze JOIN's te optimaliseren en gewoon te negeren wanneer dat kan. En dat werkt goed kan ik je vertellen. Toch jammer dat zoiets nodig is om foute SQL weg te werken.

Optimalizaties van queries heeft niets te maken met het niet uitvoeren van bepaalde outer joins, maar allezins met het bv sorteren van joins (4 inner joins zijn sneller als je eerst de kleinste sets joint). De optimizer van PostgreSql liep echt mijlen achter bij bv Sql server en minder op Oracle, dus dat ze dat hebben verbeterd is prima, maar ik snap niet echt wat dat te maken heeft met het topic.

Een ander pijnpunt zijn cascading deletes die de ORM graag wil uitvoeren, terwijl de database dit veel sneller kan. Of bv. een 100.000 records verwijderen op basis van het id, die één voor één met een eigen query worden verwijderd of met één groot IN() statement grandioos gaan mislukken (technisch mislukt, de IN wordt te groot). Gewoon een temp table met de id's dan even join-en, dat is niet iets wat de ORM kan bedenken.

Zucht...
Iedere zelfrespecterende O/R mapper heeft bulk query support, zodat je typed queries kunt uitvoeren in je code die in 1 statement worden uitgevoerd, bv DELETE FROM Foo WHERE X=@p. Cascading deletes zijn dingen die niet altijd kunnen en ook eigenlijk onwenselijk zijn in veel gevallen. Bv in multi-path graphs in je model kunnen cascading deletes al niet, en eigenlijk moet je ze ook zelf uitvoeren ipv dat door de DB laten doen (want niet altijd lukt het).

Ik weet niet naar werke crap O/R mappers jij hebt zitten kijken, maar ik zit al jaren in die tak van sport en de O/R mappers die tegenwoordig nog over zijn op volwassen platforms zijn echt niet zo brak als jij schetst (integendeel).

Geavanceerde mogelijkheden zoals windowing functions of recursieve queries, daar hoef je het al helemaal niet over te hebben.

ah, recursieve queries... En jij had het over performance? Wanneer heb je die nodig, meneer de wizard? Wanneer je een tree wilt ophalen? Maar kun je die niet veel beter anders opslaan zodat je met een normale, non-recursive query de tree kunt ophalen, waardoor CUD sneller is en simpeler?

Windowing functions zijn idd lastig, maar niet onmogelijk. Verder zijn ze veelal alleen in kleine secties van de applicatie in gebruik, waardoor je bv een deel van de query met handmatige SQL schrijft (bv door een mapping te definieren in de O/R mapper waardoor je typed queries kunt blijven schrijven en toch gebruik kunt maken van de DB functionaliteit)

Performance en ORM, geen goed koppel.

Tja, wij hebben bv veel gebruikers met inmense databases (vele miljoenen rows in honderden, soms duizenden tables) en die zijn heel tevreden over de performance. Je moet nl. weten hoe je de tool gebruikt. Jij met je handgeschreven SQL mag dan wel denken dat je snelle code kunt schrijven maar je zit aan de verkeerde kant van het hek: wat jij schrijft is een fixed api, maar de SQL die on-the-fly gegenereerd wordt is juist aangepast aan de data. Bv eager loading queries voor child nodes die zichzelf tweakt op basis van de parent set grootte. Of update queries die alleen de velden updaten die gewijzigd zijn. In hand-geschreven SQL moet je OF daar 1 query voor schrijven met COALESCE en nullable parameters, OF je moet altijd alle velden updaten. Dat is onvoordelig (data roundtripping) en je moet verder zorgen dat je geen update queries doet van rows die hetzelfde zijn, waardoor je timestamps onnodig wijzigen.

[ Voor 51% gewijzigd door EfBe op 14-09-2010 09:13 ]

[cariolive23]

EfBe schreef op dinsdag 14 september 2010 @ 08:58:
[...]

Volgens mij begrijp je er weinig van.

Dat zou best wel eens kunnen, ik heb hier pas een jaar 10 mee te maken, dus nauwelijks ervaring.

[...]

Trust me, dat lijkt me uitgesloten. Wat jij in deze thread loopt te roepen is niet echt veel meer dan wat luid gebral zonder feiten. Wat je aanhaalt is het SELECT N+1 probleem. Maar dat is niet een resultaat van het gebruik van een O/R mapper, maar van het slecht gebruiken van functionaliteit, en je kunt SELECT N+1 bv ook krijgen bij een functionele DAL met procs.

Ik ben minstens 1 dag per week programmeurs aan het uitleggen waar hun code gruwelijk de mist in gaat en waarom de performance zo slecht is. Met wat simpele queries (hooguit een paar JOINs) laat ik hen vervolgens zien hoe het ook kan, hoeveel sneller dat is, waarom het sneller is en vervolgens mogen zij dan gaan proberen om deze performance ook met hun code te bereiken. Er zijn nog nooit queries door ORM aangemaakt die sneller zijn dan mijn queries, af en toe weet men het te evenaren. Meestal door hardcoded SQL in de code op te nemen en dus eigenlijk de ORM te negeren.

[...]

*maakt kromme tenen weer recht*

Je hoeft helemaal niet je eigen SQL te schrijven om goede performance uit een O/R mapper te halen, je moet alleen de features goed gebruiken.

ORM maakt de SQL, het wordt nu alleen de kunst om de boel zo te tunen dat er bruikbare SQL uitkomt. Dit gevecht kost je alleen veel tijd. SQL schud ik zo uit de mouw, de ORM zo instellen dat er vergelijkbare SQL uitkomt, kost vele malen meer tijd.

Het SELECT N+1 probleem is de grootste, en ook de makkelijkste om te rekening mee te houden. Je wint bv veel performance door eager loading queries die met een betere O/R mapper ook nog voorzien kunnen worden van filters etc., daar kan jouw hand-geschreven SQL niet tegenop, want die queries zijn per subgraph elke keer totaal anders, plus moet je dan zelf de graph-merging schrijven buiten de SQL om. Oh wacht, jij wilt dat natuurlijk gaan doen met joins, want je denkt slim te zijn.

Voor een JOIN hoef je niet slim te zijn, zonder JOIN's is jouw database volkomen kansloos wanneer het aankomt op performance. Een database wordt direct gedegradeerd tot een bak met bytes waarbij je alle optimalisaties t.b.v. relationele databases van de afgelopen 40 jaar weggooit. Het gebruik van joins is de basis en zonder deze basis kan een RDBMS niet fatsoenlijk functioneren. Je kiest dan zelf voor beperkte performance. Dat kan een keuze zijn, maar ga dan niet klagen dat de database te langzaam is.

Handgeschreven SQL is altijd sneller of net zo snel wanneer dezelfde SQL wordt geproduceerd. ORM heeft geen kennis over de data, een programmeur/dba heeft dat wel. Hierdoor kun je met handgeschreven SQL de juiste aanpak kiezen, ORM kan dit en doet dit niet. Dat is geen fout van ORM, ORM is hier nooit voor bedacht. ORM houdt er bv. geen enkele rekening mee dat de ene tabel hooguit enkele records zal bevatten en de andere tabel wellicht miljoenen records, zal bv. niet uit zichzelf een cursor gaan gebruiken.

ORM heeft zijn pluspunten maar op het gebied van performance voldoet het absoluut niet, het is nog lang niet volwassen.

Edit: EfBe, ben je als verkoper van ORM wel helemaal objectief? Ik bekijk de boel als DBA, dat is mijn vak, en ik kan volledig meetbaar maken wat sneller is en EXPLAIN kan laten zien waarom een bepaalde aanpak sneller is.

[ Voor 3% gewijzigd door cariolive23 op 14-09-2010 09:36 . Reden: Vraagje aan EfBe ]

[EfBe]

Ook maar even antwoord geven op de topicstarter ...

vmsw schreef op maandag 13 september 2010 @ 14:57:
Gaat vooral om selects, en inderdaad heb ik nu al last van performance. Vooral omdat ik bijv. de relaties als objecten behandel, en een relatie meerdere subobjecten heeft, zoals contactpersonen (die weer telefoonnummers en adressen heeft).

Relatie
- Contactpersoon (1..*)
-- Telefoonnummer (0..*)
-- E-mailadres (0..*)
- Adres (1..*)
- Studentgegevens (1..*)
-- Studiegegevens (1..*)

Optioneel:
- lidgegevens (0..1)
- bedrijfsgegevens (0..1)
- lidmaatschappen (0..*)

Ik denk dat je model (wat ik niet echt wijs uit kan worden hierboven,) niet helemaal goed is. Om te beginnen moet je niet doorschieten met tabellen maken. Tabellen zijn in feite fysieke definities van een abstracte entity definitie (net als je code class dat is). Die maak je door eerst na te denken over wat zijn nou je entities in je problem domain. Je hebt alles in tabellen gestopt maar is dat wel goed? Bv, een telefoonnr is niet een entity, maar een 'attribute' (veld). Waarom de mogelijkheid nemen om 10 telefoonnrs op te slaan wanneer dat altijd maar 3 zijn (max): vaste lijn + mobiel + werk. Ik zeg niet dat je het meteen moet denormaliseren tot 1 tabel, maar wel dat je er over na moet denken om het aantal tabellen terug te brengen.

Als je dan een ledenlijst maakt, waar de naam + adres + telefoonnummergegevens op staan, levert dit meerdere selects per lid op, en met 4000 leden krijg je wel een performanceprobleem. Voornamelijk ook omdat het vrij veel selects zijn (immers moet je per lid de adressen & contactpersonen & telefoonnummers etc. apart opvragen, immers kunnen dit er meerdere zijn.

'Adres', is veelal niet een entity, omdat je het niet hergebruikt (de 'instance' oftewel de data), waardoor er een 1:1 relatie bestaat tussen adres instnce en lid instance. Ook hier moet je nadenken of je wilt modelleren dat een lid 12 adressen zou kunnen opgeven of maar 1.

En ik ben er niet over uit of het beter is om bedrijfsgegevens en lidgegevens in een apart tabel te zetten, of gewoon het relatie-tabel uit te breiden met deze velden, die afhankelijk van of het een bedrijf óf lid is wel of geen gegevens bevatten... Maar dat terzijde.

1:1 pk-pk relaties kun je altijd samenvoegen in de pk side table, tenzij je wilt dat die gegevens optioneel zijn.

Ik weet niet welke o/r mapper je gebruikt, maar je moet idd kijken naar joins, en verder projecties. Ook eager loading kan helpen (prefetching). 'meerdere selects per lid' geeft aan dat je een SELECT N+1 probleem hebt: voor iedere root row ga je nieuwe queries runnen. Bv wanneer je alle customers uit X ophaalt en hun orders: doe je dat in 2 queries (goed) met eager loading functionaliteit (dus 1 query op de O/R mapper die 2 queries uitvoert) of doe je dat met 1 query voor de customers en voor elke customer 1 query voor de orders (SELECT N+1)

[cariolive23]

Ps. Uit de release notes van PostgreSQL 9.0:

Multiple performance enhancements for specific types of queries, including elimination of unnecessary joins. This helps optimize some automatically-generated queries, such as those produced by object-relational mappers (ORMs).

Zet de querylogger van jouw database eens aan en laat de queries met LEFT JOIN's eens explainen, dan zie je de verschillen tussen PostgreSQL 9.0 en andere/oudere databases. En deze optimalisaties zijn niet gemaakt omdat ze niet nodig zijn...

[EfBe]

cariolive23 schreef op dinsdag 14 september 2010 @ 09:24:
[...]
Dat zou best wel eens kunnen, ik heb hier pas een jaar 10 mee te maken, dus nauwelijks ervaring.

Ach, ik maar een jaar of 15, 16. Heb ik nou gewonnen?

[...]
Ik ben minstens 1 dag per week programmeurs aan het uitleggen waar hun code gruwelijk de mist in gaat en waarom de performance zo slecht is. Met wat simpele queries (hooguit een paar JOINs) laat ik hen vervolgens zien hoe het ook kan, hoeveel sneller dat is, waarom het sneller is en vervolgens mogen zij dan gaan proberen om deze performance ook met hun code te bereiken. Er zijn nog nooit queries door ORM aangemaakt die sneller zijn dan mijn queries, af en toe weet men het te evenaren. Meestal door hardcoded SQL in de code op te nemen en dus eigenlijk de ORM te negeren.

Welke O/R mapper is nou lastig mbt joins? Heb je ook namen voor me? Ik kan het me niet echt voorstellen. Ok, Entity framework genereert brakke SQL, maar niemand dwingt je ertoe dat te gebruiken.

Je hoeft overigens niet zo te patsen, het is nl. heel simpel jou SQL te verbeteren met een O/R mapper query. Ik geef je 2 voorbeelden.
1) eager loading van een multi-path graph (Order -> Customer, en Order -> Employee en Order -> OrderDetails. Een O/R mapper laat je dit schrijven in 1 query en voert deze uit in 4 queries. Deze 4 queries zijn de meest optimale voor de situatie en maken OF gebruik van een subquery voor fk filtering OF voor een IN clause al naargelang de grootte van de parent set. Onmogelijk deze met de hand te schrijven. Je kunt dom doen en het met een join proberen (1 projectie op een set van alle tables gejoind). Dit gaat echter mis, omdat je dan problemen krijgt met de multiple paths in je graph: data duplicatie: voor iedere orderdetail row krijg je alle andere data ook dubbel. Employee heeft een BLOB en een CLOB field. Bye bye snelheid, want je hebt door de dataduplicatie veel traagheid in het datatransport.

2) updates op rows in table met 10 velden. Niet alle velden wijzigen: soms maar 1, soms 4, soms 7 etc. De O/R mapper maakt de update query aan die past bij de gewijzigde data. Jij kunt dat niet, want bij 10 velden moet je inmens veel queries schrijven om alle situaties aan te kunnen, dus verval je tot nullable parameters. Die kun je alleen gebruiken wanneer je null tests in je updates inbouwt. Dit is echter trager. Verder zou je alle data naar de db terug kunnen sturen, maar dit is ook trager, ivm data transport.

[...]
ORM maakt de SQL, het wordt nu alleen de kunst om de boel zo te tunen dat er bruikbare SQL uitkomt. Dit gevecht kost je alleen veel tijd. SQL schud ik zo uit de mouw, de ORM zo instellen dat er vergelijkbare SQL uitkomt, kost vele malen meer tijd.

Ik snap dit gelul niet echt. Het kost helemaal geen tijd om de queries te tunen, nl. je schrijft gewoon de O/R mapper query en that's it. Tenzij de programmeur een SELECT N+1 probleem creeert, maar dat is lang niet altijd het geval.

[...]
Voor een JOIN hoef je niet slim te zijn, zonder JOIN's is jouw database volkomen kansloos wanneer het aankomt op performance. Een database wordt direct gedegradeerd tot een bak met bytes waarbij je alle optimalisaties t.b.v. relationele databases van de afgelopen 40 jaar weggooit. Het gebruik van joins is de basis en zonder deze basis kan een RDBMS niet fatsoenlijk functioneren. Je kiest dan zelf voor beperkte performance. Dat kan een keuze zijn, maar ga dan niet klagen dat de database te langzaam is.

JOIN is zeker nuttig, maar niet altijd, zie boven. Daarom noemde ik het ook. Zoals ik al zei, je snapt er niet veel van.

Handgeschreven SQL is altijd sneller of net zo snel wanneer dezelfde SQL wordt geproduceerd. ORM heeft geen kennis over de data, een programmeur/dba heeft dat wel. Hierdoor kun je met handgeschreven SQL de juiste aanpak kiezen, ORM kan dit en doet dit niet. Dat is geen fout van ORM, ORM is hier nooit voor bedacht. ORM houdt er bv. geen enkele rekening mee dat de ene tabel hooguit enkele records zal bevatten en de andere tabel wellicht miljoenen records, zal bv. niet uit zichzelf een cursor gaan gebruiken.

Ach, een cursor. Cursors in SQL zijn een teken dat men niet snapt hoe set-based languages werken. Cursors zijn nl. puur imperatief, maar SQL werkt niet imperatief, maar set based. Verder is een cursor gewoon een temptable, dus waarom gebruik je die niet?

Een O/R mapper genereert overigens de SQL die jij het vertelt te genereren (voor selects dan). Waarom zou dan hand-geschreven sql beter zijn? Omdat je dan tijdens het schrijven van die query de hoeveelheid data weet? Yeah right. De DBA weet helemaal niet hoeveel rows een table heeft wanneer hij de query schrijft. Of erger: hoeveel data over het lijntje moet naar de client applicatie en hoe vaak. Dat ziet de DBA alleen door te meten. De programmeur ziet dat overigens ook niet, daarom moet de DBA de programmeur voorzien van die info, want de DBA kan bij die info, de programmeur niet.

Dat houdt niet in dat de programmeur een domme ezel is, de tool crap en de DBA een god: het houdt alleen in dat wanneer het niet zo gaat, men dom bezig is.

ORM heeft zijn pluspunten maar op het gebied van performance voldoet het absoluut niet, het is nog lang niet volwassen.

Tja...

[cariolive23]

EfBe schreef op dinsdag 14 september 2010 @ 09:50:
Dat houdt niet in dat de programmeur een domme ezel is, de tool crap en de DBA een god: het houdt alleen in dat wanneer het niet zo gaat, men dom bezig is.

Einde discussie.

Wanneer jij programmeurs als domme ezels en DBA's als god begint af te schilderen, houdt het op. Dit gaat nergens meer over, zo werk ik in elk geval niet samen met mijn collega's.

[EfBe]

cariolive23 schreef op dinsdag 14 september 2010 @ 09:32:
Ps. Uit de release notes van PostgreSQL 9.0:
[...]
Zet de querylogger van jouw database eens aan en laat de queries met LEFT JOIN's eens explainen, dan zie je de verschillen tussen PostgreSQL 9.0 en andere/oudere databases. En deze optimalisaties zijn niet gemaakt omdat ze niet nodig zijn...

Tja, fijn dat postgresql vindt dat sommige joins onnodig zijn, maar ik kan me maar een paar situaties indenken waarbij deze joins plaatsvinden:
1) inheritance: polymorphic queries waarbij in TPE scenarios de subtypes aan de supertype table worden gejoind. Deze joins kunnen weg indien er geen subtypes zijn.
2) eager fetching op mapping niveau. (N)Hibernate doet dat bv, je kunt dan bv zeggen 'voor iedere order, laadt altijd de orderdetails' en die worden dan middels joins ingeladen.

Beide zijn 'overbodig' indien er geen data in de tables staan en de left joins dus weg kunnen. Maar dat is bij iedere query zo. Iedere stored proc is een fixed query die geschreven is op een bepaald moment. Het kan dus voorkomen dat sommige tables in een join niet nuttig zijn omdat ze geen data bevatten _op dat moment_. Dat zegt niets over het tijdstip +10 minuten. Of morgen.

Ook kunnen left-joins weg wanneer ze niets toevoegen aan de projection. Echter welke O/R mapper voegt een left join toe zonder daar iets mee te doen in de projection? Ik zou het niet weten. Jij noemt ook nog steeds geen namen.

cariolive23 schreef op dinsdag 14 september 2010 @ 09:55:
[...]
Einde discussie.
Wanneer jij programmeurs als domme ezels en DBA's als god begint af te schilderen, houdt het op. Dit gaat nergens meer over, zo werk ik in elk geval niet samen met mijn collega's.

Ik zei: Dat houdt dus NIET IN.... lezen!

Ik zei dat juist omdat jij IMHO wel de programmeur als een kleun wegzet, jij moet nl. 1 keer per week de mensen uitleggen hoe het wel moet en ze redden met handgeschreven sql.

[ Voor 14% gewijzigd door EfBe op 14-09-2010 10:03 ]

[Hydra]

cariolive23 schreef op dinsdag 14 september 2010 @ 09:55:
Einde discussie.

Wanneer jij programmeurs als domme ezels en DBA's als god begint af te schilderen, houdt het op. Dit gaat nergens meer over, zo werk ik in elk geval niet samen met mijn collega's.

Misschien moet je ff een tandje terugschakelen en z'n reactie even goed lezen?

Anywho; mijns inziens is een ORM slechts een tool, en er zijn in ons vak genoeg programmeurs die een hamer gebruiken om een schroef in een stuk hout te krijgen. Een goeie programmeur is zowel lui als perfectionistisch, slechte programmeurs zijn vaak alleen lui. Ook met een ORM, die je een hoop werk uit handen kan nemen, zul je altijd nog moeten controleren wat hij precies aan queries afschiet. Onze in-house ETL tool die we gebruiken om data uit RDBMSen over te hevelen heeft ook precies die functionaliteit: hij bedenkt de SQL zelf, maar we verwachten wel dat de developer checkt of hij het niet zelf beter kan.

[B-Man]

EfBe schreef op dinsdag 14 september 2010 @ 10:00:
[...]
Ik zei dat juist omdat jij IMHO wel de programmeur als een kleun wegzet, jij moet nl. 1 keer per week de mensen uitleggen hoe het wel moet en ze redden met handgeschreven sql.

Ach, er zijn gewoon nog heel erg veel mensen die wel eens met een ORM gewerkt hebben (of code van anderen gezien hebben) die traag was. Dat levert dan dit soort gevoelens op ("ORM = crap").
Verder is het vrij logisch dat een DBA predikt dat zelfgeschreven SQL beter is. Voor specifieke, complexe situaties is dat mogelijk ook zo, maar aangezien het gros van de queries relatief simpel (maar wel dynamisch) is, besteed ik het genereren daarvan liever uit aan een ORM. Op die manier kan ik als programmeur tenminste bezig zijn met de relevante code in een app.

Het zal nog wel een tijdje duren voordat het stigma rond ORMs verdwijnt, als het al ooit verdwijnt...

[Hydra]

B-Man schreef op dinsdag 14 september 2010 @ 10:18:
Ach, er zijn gewoon nog heel erg veel mensen die wel eens met een ORM gewerkt hebben (of code van anderen gezien hebben) die traag was. Dat levert dan dit soort gevoelens op ("ORM = crap").

Ik heb retetrage code van een collega van me gezien, dat was een .Net webapp. Volgens die redenatie zou ik kunnen stellen dat .Net crap is

B-Man schreef op dinsdag 14 september 2010 @ 10:18:
Het zal nog wel een tijdje duren voordat het stigma rond ORMs verdwijnt, als het al ooit verdwijnt...

Ach, waar veel developers niet erg goed in zijn is het probleem bij zichzelf te zoeken in plaats van bij de tools die ze gebruiken, laat staan dat ze zelf eens gaan nadenken of wat ze doen niet eigenlijk enorm inefficient is.

[ Voor 33% gewijzigd door Hydra op 14-09-2010 10:24 ]

[Janoz]

Hydra schreef op dinsdag 14 september 2010 @ 10:23:
Ik heb retetrage code van een collega van me gezien, dat was een .Net webapp. Volgens die redenatie zou ik kunnen stellen dat .Net crap is

Je zegt het met een , maar dit is precies wat Java nog steeds vaak overkomt .

[raptorix]

Wanneer performance een probleem is ligt dit veelal aan verkeerde indices dan wel slechte queries, ik heb zelf jarenlang aan funda gewerk en dus veel te maken gehad met zware queries, wat wij vaak deden was de queryanalyzer mee laten lopen, en op die manier monitoren welke queries voor bottlenecks zorgen. Het goed kunnen lezen van een execution plan helpt hierbij ook enorm.

[Verwijderd]

EfBe schreef op dinsdag 14 september 2010 @ 09:50:
[...]
Welke O/R mapper is nou lastig mbt joins? Heb je ook namen voor me? Ik kan het me niet echt voorstellen. Ok, Entity framework genereert brakke SQL, maar niemand dwingt je ertoe dat te gebruiken.

Even ertussen door, ben nog niet zo bezig met ORM wil het wel gaan gebruiken voor een bepaald project als test (dus in de toekomst meer). Zijn er metingen oid die de verschillen tussen de verschillende ORM's aantonen? (denk dan aan performance etc). ?
Dus waarom zou ik kiezen tussen jouw/jullie ORM of microsofts EF?
(puur interesse, ik kraak orm niet af, als developer zie ik veel voordeel van een orm).

MIsschien dat er wederom een afsplitsing kan komen van topic?
"Databases: To ORM or not to ORM"

[ Voor 6% gewijzigd door Verwijderd op 14-09-2010 10:54 ]

[Hydra]

raptorix schreef op dinsdag 14 september 2010 @ 10:38:
Wanneer performance een probleem is ligt dit veelal aan verkeerde indices dan wel slechte queries, ik heb zelf jarenlang aan funda gewerk en dus veel te maken gehad met zware queries, wat wij vaak deden was de queryanalyzer mee laten lopen, en op die manier monitoren welke queries voor bottlenecks zorgen. Het goed kunnen lezen van een execution plan helpt hierbij ook enorm.

Ik heb zelf meegewerkt aan een grote app van een bekend reisbureau (over hoeveelheden queries gesproken) en wat daar een issue was is dat ze alles in de backend (Oracle) wilden doen, vooral op aanraden van de Oracle DBA's, freelancers met de "daar bouw ik wel een stored proc voor" mentaliteit. Dit terwijl een hoop van die queries data ophaalden die prima in de appservers te cachen was. Maargoed, de oude app was sowieso bagger, van threadpooling hadden ze ook nooit gehoord.

Janoz schreef op dinsdag 14 september 2010 @ 10:33:
Je zegt het met een , maar dit is precies wat Java nog steeds vaak overkomt .

I know, terwijl de meeste van onze grote klanten (en dan heb ik het over overheden e.d.) toch gewoon hun hele backend op Java spullen hebben draaien. Ik moet wel zeggen dat ik voor frontend spul toch voor .Net zou gaan, en voor backend spul voor Java. Java is in dat laatste meer volwassen maar kwa frontend zijn er gewoon te veel keuzes die allemaal net een beetje overgecompliceerd zijn, en niet bijster snel.

[ Voor 23% gewijzigd door Hydra op 14-09-2010 10:50 ]

[EfBe]

Verwijderd schreef op dinsdag 14 september 2010 @ 10:47:
[...]
Even ertussen door, ben nog niet zo bezig met ORM wil het wel gaan gebruiken voor een bepaald project als test (dus in de toekomst meer). Zijn er metingen oid die de verschillen tussen de verschillende ORM's aantonen? (denk dan aan performance etc). ?

Performance van een ORM != performance van een query. Een SQL query runnen in een RDBMS is maar een deel van het verhaal: de data moet naar de query toe, de data die de query oplevert moet naar de client toe, daar geconsumeerd worden, omgezet worden in bv objects of datastructures en dan verder verwerkt worden. Dan pas praat je over wat het kost om een ORM iets te laten doen. Het is dus zo dat een ORM met de minste features, dus een wrapper om een datareader, de snelste is. Dwz, als hij ook de beste SQL genereert, wat meestal niet het geval is. Hoe meer features je er in stopt, hoe meer overhead je meekrijgt en dus dat je daar iets voor betaalt qua performance. In de meeste gevallen is dat echter in de marge, want een database query is trager dan de code die die features kosten plus de code loopt op de client en je moet die code toch ergens plaatsen.

Het vergelijken van een ORM die bv wel authorizatie heeft met een die het niet heeft is dan al niet meer mogelijk: de ORM die wel authorizatie heeft kan geen objects batchen, maar kan wel authoriseren op field/object niveau. De ORM die geen authorisatie heeft kan dat niet maar kan wel objects batchen voor een query en 'lijkt' dan sneller. Echter dat is maar schijn: het inbouwen van de authorisatie bv bovenop die andere ORM is lastig en levert dan weer tragere queries op/code op, waardoor het totaal plaatje er eigenlijk anders uit ziet.

Er zijn wel wat brakke tests tussen ORMs maar die lopen spaak op precies hetgeen ik hierboven schets.

Dus waarom zou ik kiezen tussen jouw/jullie ORM of microsofts EF?
(puur interesse, ik kraak orm niet af, als developer zie ik veel voordeel van een orm).
MIsschien dat er wederom een afsplitsing kan komen van topic?
"Databases: To ORM or not to ORM"

Het EF maakt brakke queries omdat het een SQL pipeline gebruikt die moeilijk te optimaliseren is: het converteert de Linq queries naar command sets en per provider (bv de sqlserver provider) moeten die dan naar sql worden omgezet, maar je staat erg ver van SQL af met die command sets, en het kost je veel tijd om die te optimizen. (verder zijn de command sets erg bloated vaak). ze zullen dit wel verbeteren in de volgende versie (over x jaar) maar op dit moment is het karig. Linq to Sql is veel beter wat dat betreft.

Als je denkt om een ORM te gebruiken, moet je kijken naar wat je wilt 'outsourcen' aan de ORM en of de ORMs die dat kunnen dat laten doen door flexibele api's. Dus welk 'gemak' biedt de ORM en welke mogelijkheden zijn er om, wanneer de situatie zich voordoet, er zelf andere queries van de maken. Bv iets als 'Linq' genereert per definitie minder efficiente SQL in veel gevallen omdat het niet 1:1 mapt op SQL, en niet alles kan verwoorden wat je in SQL kunt. Dit levert dus soms queries op die je had kunnen verbeteren als je een query systeem had gehad die je dat had laten doen. Veel ORMs hebben meerdere query systemen, behalve die van MS, die kunnen alleen Linq (alhoewel EF ook 'Entity sql' kan, maar dat is volgens mij al dead en is erg beperkt), zodat je queries kunt omschrijven naar een betere query mocht dat wenselijk zijn, zonder dat je naar SQL hoeft.

[Verwijderd]

EfBe schreef op dinsdag 14 september 2010 @ 11:20:
[...]
Performance van een ORM != performance van een query.
.........

Begrijpelijk, maar er zou getest kunnen worden op basis features, schaalbaarheid etc.

Het vergelijken van een ORM die bv wel authorizatie heeft met een die het niet heeft is dan al niet meer mogelijk: de ORM die wel authorizatie heeft kan geen objects batchen, maar kan wel authoriseren op field/object niveau.

Wist niet eens dat er ORMs bestaan die dat kunnen. Dit is vaak met gewone code/queries al een hekel punt.

Als je denkt om een ORM te gebruiken, moet je kijken naar wat je wilt 'outsourcen' aan de ORM en of de ORMs die dat kunnen dat laten doen door flexibele api's. Dus welk 'gemak' biedt de ORM en welke mogelijkheden zijn er om, wanneer de situatie zich voordoet, er zelf andere queries van de maken.

Na, ik wou gewoon eens beginnen met een simpele vertaalslag van eenvoudige objecten naar de DB. Speciale zaken kunnen later. Ben een "luie" ontwikkelaar, zaken die ik maar 1x hoef te maken maak ik het liefst maar 1x. Gebieden waar performance echt van toepassing en/of een probleem is kunnen altijd apart genomen worden. Ik zie het als de 80% (of 20% hoe je het ziet) regel. En als voor de 80% van het werk een ORM veel werk uit handen van ontwikkelaars haalt (en ik denk dan niet alleen aan initieel ontwikkelen maar ook onderhoud, debuggen, nieuwe zaken etc. etc) zal het vaak al de moeite zijn om een ORM in te zetten. Zit nu vaak zelf nog op de oldschool way m'n objecten (ik doe nu voornamelijk Delphi, klein beetje C# -wat eigenlijk al meer had moeten zijn-, voorheen ook Progress). Vanuit m;n appcode van en naar de db te projecteren, is vaak gewoon zonde tijd.

[raptorix]

Hydra schreef op dinsdag 14 september 2010 @ 10:48:
[...]


Ik heb zelf meegewerkt aan een grote app van een bekend reisbureau (over hoeveelheden queries gesproken) en wat daar een issue was is dat ze alles in de backend (Oracle) wilden doen, vooral op aanraden van de Oracle DBA's, freelancers met de "daar bouw ik wel een stored proc voor" mentaliteit. Dit terwijl een hoop van die queries data ophaalden die prima in de appservers te cachen was. Maargoed, de oude app was sowieso bagger, van threadpooling hadden ze ook nooit gehoord.

Ja voor Funda hebben we destijds een aparte database voor frontend gebouwd in combinatie met nHibernate.

[vmsw]

Het performanceprobleem ligt hoofdzakelijk bij het uitvoeren van al die query's. Waarschijnlijk dus nog eerder bij de connectie tussen het php en mysql proces. Dat besef ik inderdaad; maar zijlings vond ik het wel fijn om in ieder geval alvast de snelste database te gaan nemen. Vooral omdat ik net een nieuwe SSD-server heb, en beide versies tot m'n beschikking heb.

Ik heb uit jullie antwoorden begrepen dat het beter is om zo min mogelijk tabellen te gebruiken, indien het niet nodig is. Dus bijv. de velden die alleen voor bedrijven van toepassing zijn, kan ik beter toevoegen aan het algemene relatiegedeelte, alleen gewoon niet gebruiken in het geval van een consument bijv.

Verder, ik wil wel gebruik blijven maken van losse tabellen voor bijv. adressen & telefoonnummers; dit zijn er gemiddeld 2 respectievelijk 3 per lid. Maar er zijn ook uitzonderingen, en het lijkt me gewoon netjes dit te ondersteunen.

JOINS ken ik, en gebruik ik. Indien er een tabelrelatie is met maximaal 1 link, dan gebruik ik een JOIN. Zodra ik een relatie ophaal, worden bijv. de tabellen met lidgegevens/bedrijfsgegevens direct meeingeladen.
Maar als er bijv. meerdere adressen per lid kunnen zijn, zoals het geval is, dan kan dit niet zomaar met een JOIN gedaan worden. Immers is die resultset dan langer. Vandaar laat ik m'n script dat opzoeken zodra het opgevraagd wordt.

PHP:

<?php
$relatie = opslag::geef(entiteit_relatie, 1); 
/*haalt relatie met id 1 uit database*/

echo $relatie->geef('relatieeigenschap');
/*print de relatieeigenschap. deze eigenschap is al ingeladen, dus er wordt geen sql uitgevoerd*/

echo $relatie->geef(entiteit_contactpersoon, HOOFDVERMELDING)->geefVolledigeNaam(); 
/*print de volledige naam van de default contactpersoon van deze relatie. Hiervoor voert hij automatisch een nieuwe query uit, die direct alle contactpersonen inlaad (omdat er toch al een query uitgevoerd moet worden om de hoofdvermelding op te halen..)*/
?>

[ Voor 6% gewijzigd door vmsw op 17-09-2010 11:46 ]

[P_de_B]

vmsw schreef op vrijdag 17 september 2010 @ 11:40:

Maar als er bijv. meerdere adressen per lid kunnen zijn, zoals het geval is, dan kan dit niet zomaar met een JOIN gedaan worden. Immers is die resultset dan langer. Vandaar laat ik m'n script dat opzoeken zodra het opgevraagd wordt.

Natuurlijk kan dat wel! Je moet dan alleen in je clientcode zorgen dat je de juiste gegevens toont.

[Janoz]

vmsw schreef op vrijdag 17 september 2010 @ 11:40:
Ik heb uit jullie antwoorden begrepen dat het beter is om zo min mogelijk tabellen te gebruiken, indien het niet nodig is.

Nee, wat men hier zegt is niet minder tabellen, maar minder queries

JOINS ken ik, en gebruik ik. Indien er een tabelrelatie is met maximaal 1 link, dan gebruik ik een JOIN. Zodra ik een relatie ophaal, worden bijv. de tabellen met lidgegevens/bedrijfsgegevens direct meeingeladen.
Maar als er bijv. meerdere adressen per lid kunnen zijn, zoals het geval is, dan kan dit niet zomaar met een JOIN gedaan worden. Immers is die resultset dan langer. Vandaar laat ik m'n script dat opzoeken zodra het opgevraagd wordt.

Als er maximaal 1 link is, dan moet je dat niet met een join oplossen, maar horen het uberhaupt geen twee tabellen te zijn. Daarnaast is de overhead van meerdere queries een stuk duurder dan de resultset die misschien ietsje groter wordt. Probeer het zelf maar eens. Je zult zien dat die dikke join query met enorme resultset ontiegelijk veel sneller is dan het N+1 select anti pattern wat je nu gebruikt.

[tss68nl]

Die (0..1) links die je hebt in je overzicht kan je vaak (let op: niet altijd) beter gewoon velden maken in het hoofdrecord en die nullable (mogen leeg gelaten worden) zetten. Het kost je wat opslag (wie treurt daar tegenwoordig nog om), maar zorgt wel voor minder joins in je query.

Dan over het maken van joins...dit wordt in deze thread wel heel erg zwaar aangezet. Een goede database met goede indexen op de tabellen, zal geen enkele moeite hebben met joins. Vooral MSSQL is hier erg sterk in (beter dan Oracle en veel beter dan MySQL), en het resultaat is dat je met een beetje tuning kennis rustig 10 joins kan hebben met daarin enkele tabellen van 40.000.000 records, en nog je resultaat binnen een seconde op het scherm. Het gaat daarbij allemaal om een goed database ontwerp, goede indexen, optioneel goede partitionering, en uiteraard snelle opslag.

Qua vergelijk:
Ik heb wel eens een complete telefoonboek database ingelezen in zowel MySQL als MSSQL. MySQL is bloedsnel bij het inlezen van de gegevens, MSSQL heeft daarvoor iets teveel bagage maar is met tuning ook niet onverdienstelijk. Echter, het bevragen van de MySQL database met goede indexen duurde een factor 5 tot 20 langer afhankelijk van het soort bevraging vergeleken met MSSQL. Inlezen van een complete database doe je eenmalig...maar het bevragen herhaaldelijk. In dat geval was de keus erg makkelijk gemaakt.

Algemene keuze:
Persoonlijk zou ik voor MSSQL (Express) kiezen zolang de applicatie en omgeving dat toelaten. MySQL zou ik alleen voor kiezen als je bijvoorbeeld een website moet hosten, waarbij een PHP/MySQL host in de regel vele malen goedkoper is dan een ASP/MSSQL host. MSSQL is de laatste jaren enorm vooruit gegaan, en ik durf er mijn hand voor in het vuur te steken dat het altijd de betere keus is boven MySQL mits het project het toelaat.

Ik zou je vooral gaan focussen op een goed database ontwerp (derde normaalvorm is niet overal heilig), en wat (index) tuning / algemene database kennis.

Succes met je project!

[joppybt]

tss68nl schreef op vrijdag 17 september 2010 @ 12:15:
Een goede database met goede indexen op de tabellen, zal geen enkele moeite hebben met joins.
Vooral MSSQL is hier erg sterk in (beter dan Oracle en veel beter dan MySQL)

Heb je hier ook bewijs voor of is dit persoonlijke ervaring?
Ik durf te stellen dat (zonder tegenbewijs) een ervaren MSSQL- dan wel Oracle ontwikkelaar op beide databases nagenoeg identieke performance kan halen.

[tss68nl]

joppybt schreef op vrijdag 17 september 2010 @ 12:28:
[...]
Heb je hier ook bewijs voor of is dit persoonlijke ervaring?
Ik durf te stellen dat (zonder tegenbewijs) een ervaren MSSQL- dan wel Oracle ontwikkelaar op beide databases nagenoeg identieke performance kan halen.

Het is de vraag in hoeverre je zoiets kan bewijzen middels een forum. Dat zou je toch in een vergelijkingstest moeten vaststellen en dan het liefst nog met eigen ogen zien en wat mogelijkheden kunnen proberen om jezelf te overtuigen. Wel heb ik kort een directe vergelijking door mijzelf uitgevoerd beschreven in de reactie waar jij aan refereert, en dat is qua 'bewijs' toch alles wat ik zo snel middels een forum kan bieden.

Overigens ben ik jarenlang een ervaren MSSQL en Oracle ontwikkelaar geweest, gericht op Business Intelligence, en heb dus aardig wat gevoel mogen krijgen voor de mogelijkheden van verschillende databases. Ik zeg inderdaad 'geweest', aangezien ik sinds een aantal jaar project management heb opgepakt binnen hetzelfde vakgebied. Ik kom dus nog steeds in aanraking met dezelfde databases, maar geen hands-on ervaring meer.

Uit die ervaring kan ik met zekerheid stellen dat MSSQL beter is in recht-toe recht-aan query performance inclusief joins (Oracle heeft weer zijn eigen specifieke voordelen). Daarnaast steekt MSSQL met kop en schouders boven MySQL uit qua mogelijkheden en performance op grote databases, en zou je MySQL alleen moeten prefereren in een omgeving die daarom vraagt vanwege andere redenen dan performance (bijv. webhosting kosten zoals eerder genoemd).

[tss68nl]

Even een aparte post over het opvragen van data, en de 100.000 queries die TS daar voor nodig denkt te hebben. Er zijn meerdere mogelijkheden om dit te omzeilen:

1) Join het hoofdrecord en de benodigde adressen etc gewoon aan elkaar. Je krijgt dan wel een x-aantal keer het hoofdrecord geleverd, maar je zal alle informatie wel in één query kunnen ophalen. Het parsen van die gegevens is niet zo heel lastig in je programma. Je loopt hier tegen het probleem aan dat een database query in de regel maar een simpele matrix aan data kan teruggeven: rijen & kolommen.
2) Een betere methode die je met MSSQL Server 2008 Express kan gebruiken is de mogelijkheid om je query resultaten in XML te laten terug geven. De XML structuur kan een onregelmatige boom aan data bevatten, die voor alle contacten alle onderliggende informatie in 1x kan teruggeven aan je programma, zonder daarbij data dubbel over te sturen.

Mijns inzien is optie 2 de beste optie om een flink genormaliseerd database schema gemakkelijk te kunnen raadplegen vanuit je programma.

[lier]

tss68nl schreef op vrijdag 17 september 2010 @ 13:19:
Even een aparte post over het opvragen van data, en de 100.000 queries die TS daar voor nodig denkt te hebben. Er zijn meerdere mogelijkheden om dit te omzeilen:

1) Join het hoofdrecord en de benodigde adressen etc gewoon aan elkaar. Je krijgt dan wel een x-aantal keer het hoofdrecord geleverd, maar je zal alle informatie wel in één query kunnen ophalen. Het parsen van die gegevens is niet zo heel lastig in je programma. Je loopt hier tegen het probleem aan dat een database query in de regel maar een simpele matrix aan data kan teruggeven: rijen & kolommen.
2) Een betere methode die je met MSSQL Server 2008 Express kan gebruiken is de mogelijkheid om je query resultaten in XML te laten terug geven. De XML structuur kan een onregelmatige boom aan data bevatten, die voor alle contacten alle onderliggende informatie in 1x kan teruggeven aan je programma, zonder daarbij data dubbel over te sturen.

Mijns inzien is optie 2 de beste optie om een flink genormaliseerd database schema gemakkelijk te kunnen raadplegen vanuit je programma.

Maar...XML is nou niet echt gelijk het formaat dat je met performance in verband zou brengen...toch !?

Overigens begrijp ik ook niet helemaal de relatie van Database keuze en ORM. Verder ben ik van mening dat een ORM bedoeld is om het ontwikkel proces te versnellen. Mijn voorkeur zou het dan ook hebben om ORM alleen te gebruiken op de juiste plaatsen.

[Wolfboy]

tss68nl schreef op vrijdag 17 september 2010 @ 12:15:
Algemene keuze:
Persoonlijk zou ik voor MSSQL (Express) kiezen zolang de applicatie en omgeving dat toelaten. MySQL zou ik alleen voor kiezen als je bijvoorbeeld een website moet hosten, waarbij een PHP/MySQL host in de regel vele malen goedkoper is dan een ASP/MSSQL host. MSSQL is de laatste jaren enorm vooruit gegaan, en ik durf er mijn hand voor in het vuur te steken dat het altijd de betere keus is boven MySQL mits het project het toelaat.

Lijkt me eigenlijk toch geen handige keuze. MSSQL Express is leuk maar met maximaal 1 processor en 1GB geheugen kan ik het geval al niet eens fatsoenlijk draaien op m'n laptop. Maximaal 1GB geheugen is voor een database nu ook weer niet bijzonder veel, daar zit je zo aan met een beetje database.

Misschien voldoende voor dit specifieke doel, maar het is wel een serieuze beperking waar je goed rekening mee moet houden.

[tss68nl]

lier schreef op vrijdag 17 september 2010 @ 13:31:
[...]

Maar...XML is nou niet echt gelijk het formaat dat je met performance in verband zou brengen...toch !?

Overigens begrijp ik ook niet helemaal de relatie van Database keuze en ORM. Verder ben ik van mening dat een ORM bedoeld is om het ontwikkel proces te versnellen. Mijn voorkeur zou het dan ook hebben om ORM alleen te gebruiken op de juiste plaatsen.

Bij een hoofdrecord met bijvoorbeeld 10 1..n relaties (iets wat ik niet helemaal uit de omschrijving van TS kan opmaken, maar het neigt er wel naar), dan kan ik me voorstellen dat een platte recordset aardig wat redundantie met zich mee brengt. Het performt dan ook niet echt lekker om dat op de client allemaal te gaan lopen filteren, en al helemaal niet om voor iedere tabel een aparte query te gebruiken zoals hij nu doet.

Ik refereer ook niet aan XML als dataopslag, maar MSSQL kan eenvoudig iedere resultaten recordset slim in een XML formaat gieten door 'FOR XML' achter de originele query te plakken. Ik zie niet in hoe dat slecht zou performen, aangezien je op de client meteen de resultaten kan inlezen mits er een standaard XML object in zit waar je de verkregen XML in kan gooien. Meeste talen hebben daar een prima voorziening voor.

Overigens ben ik het met je eens over dat hele ORM verhaal. Volgens mij doet dat er helemaal niet toe in dit geval. TS wil weten welke database dat hij moet kiezen, en heeft duidelijk wat tips nodig hoe een database het beste te bevragen is.

[tss68nl]

Wolfboy schreef op vrijdag 17 september 2010 @ 13:48:
[...]
Lijkt me eigenlijk toch geen handige keuze. MSSQL Express is leuk maar met maximaal 1 processor en 1GB geheugen kan ik het geval al niet eens fatsoenlijk draaien op m'n laptop. Maximaal 1GB geheugen is voor een database nu ook weer niet bijzonder veel, daar zit je zo aan met een beetje database.

Misschien voldoende voor dit specifieke doel, maar het is wel een serieuze beperking waar je goed rekening mee moet houden.

Ik denk dat je toch een paar dingen door elkaar haalt

De beperking ligt op 1GB werkgeheugen wat de applicatie gebruikt. De mate waarin je werkgeheugen nodig hebt hangt af van complexiteit van queries, en mocht het geheugen niet toereikend zijn gebruikt MSSQL een temporary database waarin tussenresultaten worden gestreamed. Met fatsoenlijke snelle opslag geeft dat geen enkel probleem.

Die ene processor klinkt trouwens ook erger dan het is, want ze bedoelen daar één fysieke processor mee, die dus wel mag bestaan uit meerdere cores. Een dualcore processor voor thuis of voor een fatsoenlijke server een Xeon proc voldoet dus prima.

De limiet in Express voor de database omvang is 10GB, maar het staat je vrij om meerdere databases naast elkaar aan te maken mocht je echt veel meer data op willen slaan. Zo kan je in één Express installatie rustig 40 GB opslaan in 4 databases, al kom ik dat soort constructies weinig tegen.

Als ik je nu vertel dat er alleen in nederland al een stuk of 500 winkels zijn waar jij en ik met enige regelmaat te vinden zijn, die stuk voor stuk hun hele kassasysteem, backoffice, bestelsysteem en facturatie draaien op een MSSQL Express database zonder problemen? Dat Express niet performt op één specifieke laptop, zegt meer over de laptop, dan over MSSQL Express

[lier]

Dan wil ik ook nog SQL Compact Edition in overweging meegeven. Is misschien nog niet eens zo gek (en tijdens de TechEd (2008) gaf Steve Lasker een goed verhaal waarbij de performance nogal veel verbaasde reacties gaf. Een nadeel zou kunnen zijn dat Stored Procedures niet ondersteund worden...

Linkje voor de download en extra info.

[Wolfboy]

tss68nl schreef op vrijdag 17 september 2010 @ 14:15:
[...]


Ik denk dat je toch een paar dingen door elkaar haalt

De beperking ligt op 1GB werkgeheugen wat de applicatie gebruikt. De mate waarin je werkgeheugen nodig hebt hangt af van complexiteit van queries, en mocht het geheugen niet toereikend zijn gebruikt MSSQL een temporary database waarin tussenresultaten worden gestreamed. Met fatsoenlijke snelle opslag geeft dat geen enkel probleem.

Dat begrijp ik. Ik probeer alleen te zeggen dat je al snel tegen een maximum van 1GB geheugen aan loopt. Ja, je kan het prima doen zonder dat geheugen met temporary tabellen e.d. maar jij zal vast ook wel weten dat die oplossing vele malen trager is.

Voor kleine databases zal het dan ook wel voldoen, maar zodra het groeit naar een iets serieuzer systeem dan heb je er niet meer voldoende aan.

Ik weet in ieder geval wel dat de test databases die ik op mijn laptop heb draaien echt zeer beroerd performen met weinig (zeg, minder dan 2GB) geheugen. Nu kan ik die databases wel wat verkleinen omdat het een test omgeving is natuurlijk, maar de productie omgeving heeft nog een veel grotere database. En zo'n uitegebreide database is het nu ook weer niet

Als ik je nu vertel dat er alleen in nederland al een stuk of 500 winkels zijn waar jij en ik met enige regelmaat te vinden zijn, die stuk voor stuk hun hele kassasysteem, backoffice, bestelsysteem en facturatie draaien op een MSSQL Express database zonder problemen? Dat Express niet performt op één specifieke laptop, zegt meer over de laptop, dan over MSSQL Express

Ik heb nooit gezegd dat MSSQL Express niet performt op m'n laptop (ik heb zelfs nooit MSSQL gedraait op m'n laptop). Ik zeg alleen dat je al snel tegen de beperkingen aanloopt met MSSQL Express en dan mag je toch flink betalen voor een upgrade

Maar misschien zie ik het wat te pessimistisch in en is het voor de meeste doeleinden eigenlijk nog wel voldoende. Het hangt er natuurlijk helemaal vanaf over welke schaal je het hebt. Veel webshops in Nederland draaien OSCommerce op een webhost waar ze niet meer dan 256MB geheugen beschikbaar hebben. Het is dus wel heel erg afhankelijk van je doel.

[EfBe]

tss68nl schreef op vrijdag 17 september 2010 @ 13:54:
[...]
Overigens ben ik het met je eens over dat hele ORM verhaal. Volgens mij doet dat er helemaal niet toe in dit geval. TS wil weten welke database dat hij moet kiezen, en heeft duidelijk wat tips nodig hoe een database het beste te bevragen is.

Welke database hij moet kiezen doet juist niet ter zake, want wat hij doet is slecht op iedere database. Zoals ik hierboven al schetste heeft hij een SELECT N+1 probleem: bij het lezen van een set rows gaat hij dan sequentieel per row in die set een nieuwe set ophalen, wat dus veel queries oplevert. Dat moet topicstarter oplossen, al het andere is bullshit en niet ter zake doende: iedere database gaat door de knieen wanneer je er maar genoeg SELECT N+1 queries op los laat.

Of dat aan de gebruikte ORM ligt dat is vraag twee. Het zou topicstarter sieren wanneer hij zn focus van 'welke DB moet ik kiezen' afhaalt en echt gaat nadenken over wat hij aan het doen is. Er is al veel uitleg gegeven hier maar we komen geen ruk dichterbij.

[alt-92]

Wolfboy schreef op vrijdag 17 september 2010 @ 19:55:
[..OverMSSQLExpress..]
Dat begrijp ik. Ik probeer alleen te zeggen dat je al snel tegen een maximum van 1GB geheugen aan loopt. Ja, je kan het prima doen zonder dat geheugen met temporary tabellen e.d. maar jij zal vast ook wel weten dat die oplossing vele malen trager is.

Voor kleine databases zal het dan ook wel voldoen, maar zodra het groeit naar een iets serieuzer systeem dan heb je er niet meer voldoende aan.

Ik weet in ieder geval wel dat de test databases die ik op mijn laptop heb draaien echt zeer beroerd performen met weinig (zeg, minder dan 2GB) geheugen. Nu kan ik die databases wel wat verkleinen omdat het een test omgeving is natuurlijk, maar de productie omgeving heeft nog een veel grotere database. En zo'n uitegebreide database is het nu ook weer niet

offtopic:
Eigenlijk gebruik je dan ook niet de right tool for the job - in dat geval heb jij meer aan SQL2005/8 Developer Edition aangezien de featureset in MSSE ook niet bedoeld is voor wat je ermee doet.

[Wolfboy]

alt-92 schreef op zaterdag 18 september 2010 @ 17:33:
[...]

offtopic:
Eigenlijk gebruik je dan ook niet de right tool for the job - in dat geval heb jij meer aan SQL2005/8 Developer Edition aangezien de featureset in MSSE ook niet bedoeld is voor wat je ermee doet.

offtopic:
Dat is waar. Maar het zou toch vreemd zijn als je systeem later beter performed bij de developers als dat het doet in de productie omgeving

Kan natuurlijk, ik vind het alleen vreemd

[alt-92]

Ok, dan is het ook niet meer offtopic: als jij een dataset moet gebruiken in je produktieomgeving die de randen van de specs opzoeken (of er zelfs overheen gaan) van je DMBS dan lijkt het me duidelijk waar je probleem zit toch?