Java database benchmarking

[xinq]

Beste allemaal,

Voor mijn afstuderen heb ik gekozen om onderzoek te doen naar de verschillende database management systemen (DBMS) / databases die geschikt zijn voor het opslaan en beschikbaar maken van 'sociale data'.

Het idee is dus om te onderzoeken welke database infrastructuur geschikt is voor de volgende zaken:

• Het opslaan van grote hoeveelheden data verzameld - door crawlers - van verschillende social networks (Hyves, Facebook, Twitter, etc.)
• Het kunnen zoeken in de opgeslagen data op bijvoorbeeld iemands connecties (vrienden / folowers / etc.)

Dit is even globaal wat de verantwoordelijkheden van de database(s) zou zijn. Het idee is dat ik tijdens mijn afstuderen literatuuronderzoek doe naar geschikte DBMS-en en een tool ontwikkel in Java die de databases kan testen (benchmarken op bijv. read / write / update), op basis van literatuuronderzoek en de resultaten van het eigen onderzoek maak ik mijn conclusies.

Ik zit nu inmiddels in week 2 van mijn afstuderen en ben dus bezig met de analysefase. Ik heb al onderzoek gedaan naar verschillende mogelijkheden: relationele databases (MySQL) en bijv. NoSQL (Cassandra / CouchDB)

De vraag aan jullie is nu eigenlijk de volgende: hoe kan ik een slimme applicatie maken in Java die slim kan schakelen tussen de verschillende databases waardoor ik slim kan testen (Denk ook aan veschillende JPA's zoals Hibernate)?

Ik hoop dat iemand hier een goed idee heeft voor het testen - hoeft niet uitgebreid, een duwtje is genoeg;) - of een leuke suggestie heeft voor mijn onderzoek waardoor mijn afstuderen een groot succes wordt;)!

Schroom ook vooral niet om vragen te stellen, een discussie - waar dan ook over - is zeer welkom!

Mvg,

Nick

[YopY]

Hm. Voor RDBMSen op basis van SQL kun je via de JDBC abstractielaag alles benaderen, slechts één keer code schrijven (mits het SQL betreft die op alle RDBMSen werkt - je krijgt al problemen als je bijv. MySQL en MSSQL hebt, die hebben een andere notatie voor het ophalen van een X aantal resultaten (select top X versus limit X), en verder hoef je alleen de databaseconnectiestring en de te gebruiken JDBC driver aan te passen.

Je zou een abstractie bovenop JDBC kunnen gebruiken zoals Hibernate om om de problemen mbt SQL syntax heen te komen. Echter, hierdoor kan de performancemeting weer beïnvloed worden, afhankelijk van hoe Hibernate etc hun onderliggende database benaderen.

Hoe dan ook, wat je uiteindelijk zoekt is één interface om je data te benaderen, met meerdere implementaties die een ander onderliggend systeem gebruiken. Een DataSource interface met subclasses CassandraDataSource, HibernateDataSource, MySQLDataSource, CouchDBDataSource, etc. Die hebben allemaal wat methodes om hun gegevens op te halen, maar hun implementatie is telkens anders afhankelijk van het onderliggende systeem.

Een datasource hang je tenslotte in je 'benchmark' code en laat je lekker draaien.

Voorkauwen (slecht voorbeeld waarschijnlijk):

Java:

List<DataSource> dataSources = new ArrayList<DataSource>();
dataSources.add(new MySQLDataSource("connection string hiero"));
dataSources.add(new CassandraDataSource(param1, param2);
// etc
   StopWatch sw = new StopWatch(); // spring stopwatch oid.
for (DataSource dataSource : dataSource) {
  sw.start(dataSource.getName() + " doeIets");
   sw.doeIets();
  sw.stop();
  sw.start(dataSource.getName() + "doeIetsAnders");
  sw.stop();
}
System.out.println(sw.prettyPrint());

[xinq]

Bedankt voor je reactie YopY. De gegeven structuur zoals jij gaf zat ook ongeveer in mijn hoofd. Jij geeft het alleen nog iets abstracter als dat ik voor me zag dus dat is alleen maar goed:)!

Ik vraag me alleen wel af hoe ik een goede vergelijking kan gaan maken tussen relationele dbmsen, object georienteerde en bijv. NoSQL.

Het datamodel veranderd dan ook per DBMS en dus kan ik niet echt een heel eerlijke vergelijking maken naar mijn mening.

Of zie ik dit verkeerd?

[Standeman]

Het exacte datamodel maakt op zich niet zo veel uit. Waar je (denk ik) op moet concetreren is dat je vergelijkbare structuren test. Zolang multiplicity, aantal en omvang van data gelijk is kan je een redelijke vergelijking maken.

[The Eagle]

Java = Sun = Oracle
Ik geloof dat ik wel ongeveer weet waar je uit gaat komen - bij de marktleider dus
Bovendien draait het Oracle DBMS native java in het DBMS zelf vziw. En dat scheelt je een hele hoop

[YopY]

Je zou moeten benchmarken met een vaste set aan data en operaties daarop. De gegevens die je op moet slaan en dingen mee moet doen (dat zijn de requirements namelijk) veranderen niet als je het in een ander systeem opslaat. Het precieze hoe en wat wel natuurlijk, maar ook dat is een belangrijk onderdeel van je tests.

[EfBe]

Al naar TPC.org gekeken en hun test applicaties? Verder is benchmarken van databases feitelijk onbegonnen werk: er zijn altijd tweaks beschikbaar die jij als niet-specialist op die database over het hoofd ziet en waardoor je bv verkeerde conclusies trekt. Bv je denkt oracle te gaan testen en je weet niet wat een partitioned view is, zodat je queries met veel joins traag zijn. En dat terwijl veel databases veel tools in zich bergen om in allerlei situaties meer performance uit de database te halen, maar dit is vaak specialistenwerk.

Dus veel meer dan een theoretische studie kom je niet: op 'feiten' gebaseerde tests zijn altijd omver te halen met specialistische tuning op de database zelf. En die leveren veelal erg veel performance winst op, soms erg significant.

[xinq]

Jullie hebben gelijk ja, als de data maar gelijk is kan er redelijk 'gelijkwaardig' getest worden.

@EfBe:
Het is de bedoeling dat ik een eigen benchmarktool ontwikkel. Ik kan mijn tool natuurlijk wel baseren op andere tools, dus nuttig is het wel. Alleen, de, door jou genoemde, test applicaties vind ik niet terug op de website?

Ik weet natuurlijk ook dat ik geen echt reële resultaten kan produceren. Het gaat er alleen om om een globaal beeld te geven van de mogelijke DBMS-en met bijbehorende kenmerken waarvan een belangrijk deel de benchmarks zijn. Eigenlijk geef jij al een deel van de conclusie/aanbevelingen van het onderzoek:
"op 'feiten' gebaseerde tests zijn altijd omver te halen met specialistische tuning op de database zelf. En die leveren veelal erg veel performance winst op, soms erg significant."

Maar het is natuurlijk wel de bedoeling zo reëel mogelijke resultaten te behalen, dus tips in die richting zijn altijd welkom:)!

Ook moet ik straks een keuze maken voor de onderzoeksgrenzen, dus wat ik wel en wat ik niet ga onderzoeken. Uiteindelijk ga ik denk 10 DBMS-en echt geheel testen dus er moet een flinke voorselectie plaatsvinden.
Een punt daarbij is, er zijn ook veel commerciële DBMS-en en er zijn geen resources beschikbaar (geld..) om die te testen dus daar zit natuurlijk ook al een grote 'what if..'. Misschien een idee om de opensource kant op te gaan, of....?

[JaQ]

EfBe schreef op donderdag 27 januari 2011 @ 14:30:
Bv je denkt oracle te gaan testen en je weet niet wat een partitioned view is, zodat je queries met veel joins traag zijn.

Zelfs de Oracle handleiding weet niet wat een partitioned view is?

Is dit zo'n specialist feature die naast de go_fast parameter zit?

[ACM]

The Eagle schreef op donderdag 27 januari 2011 @ 11:39:
Java = Sun = Oracle
Ik geloof dat ik wel ongeveer weet waar je uit gaat komen - bij de marktleider dus
Bovendien draait het Oracle DBMS native java in het DBMS zelf vziw. En dat scheelt je een hele hoop

Dat de benchmark-omgeving in java ontwikkeld wordt is geen enkele garantie voor het winnen van Oracle's database. Sterker nog, de out-of -the-box performance van databases als PostgreSQL en MySQL zouden best beter kunnen zijn. En als je queries uitvoert die goed op MapReduce aansluiten, dan zou een multi-node Cassandra (of ander NoSQL-systeem) ook zomaar veel sneller kunnen zijn.
Of je data verder even veilig en even handig voor andere situaties te benaderen is, is dan uiteraard de vraag (bij NoSQL wordt over het algemeen de dataveiligheid en/of de flexibiliteit en kracht van de querytaal opgeofferd).

[The Eagle]

Vwb die commerciele DBMS'en: Oracle Enterprise Edition trek je zo van de website af. of dat voor de andere DBMS'en ook geldt weet ik niet, maar 9 van de 10 kansen als je een belletje pleegt naar de marketingafdeling en aangeeft dat het voor studie is, willen ze je over het algemeen best helpen

Verder: je wilt een benchmark in java schrijven. Prima. Als je echt onafhankelijk wilt testen, zul je er voor moeten zorgen dat je zoveel mogelijk onafhankelijk van andere factoren test. Dat betekent dus zelfde hardware, zelfde OS, zelfde java stack, etc etc. Alleen je DBMS is steeds anders. Maak een image van de PC waar je op test en ververs die keer op keer, dan weet je zeker dat je de zelfde hebt. Met een beetje mazzel kun je zelfs op elk DBMS dezelfde JDBC kopeling gebruiken.
Als ik jou was zou ik iig kiezen om de demo versie van een DBMS te installeren, inclusief database. Dan heb je die iig ook; alles out of the box. Verder overal een identiek schema aanmaken; overal de zelfde tabellen + koppelingen + inhoud, en daarop testen. Recursieve queries doen het iig altijd goed; full tablescans wil je vermijden en indexen doe je niet aan - dat kan namelijk de performance beinvloeden. Da's een leuke uitdaging dus
Tot slot: neem ook vooral tuningsparameters in je onderzoek. Zoals gezegd kunnen die een groot verschil maken. test met en zonder en vergelijk. Niet alleen interessant om te weten, maar ook mooi verdiepend qua onderzoek en je kijkt verder dan je neus lang is, vinden ze op school altijd fijn

[ACM]

The Eagle schreef op donderdag 27 januari 2011 @ 22:54:
Vwb die commerciele DBMS'en: Oracle Enterprise Edition trek je zo van de website af.

Met in de voorwaarden dat je hun toestemming moet hebben voor je benchmarkresultaten publiceert.

Verder: je wilt een benchmark in java schrijven. Prima. Als je echt onafhankelijk wilt testen, zul je er voor moeten zorgen dat je zoveel mogelijk onafhankelijk van andere factoren test. Dat betekent dus zelfde hardware, zelfde OS, zelfde java stack, etc etc. Alleen je DBMS is steeds anders. Maak een image van de PC waar je op test en ververs die keer op keer, dan weet je zeker dat je de zelfde hebt. Met een beetje mazzel kun je zelfs op elk DBMS dezelfde JDBC kopeling gebruiken.

Dit is een lastig punt. Het is niet ongebruikelijk dat de open source databases meer getuned zijn voor gebruik op Linux dan voor Windows. Als je dan de optimale prestaties van elke opslagomgeving wilt testen, dan zou je zo'n omgeving benadelen als je gedwongen bent alles onder Windows te doen (ivm MSSQL).

Verder overal een identiek schema aanmaken; overal de zelfde tabellen + koppelingen + inhoud, en daarop testen.

Dat is sowieso al onmogelijk als je nosql-databases erbij wilt halen
Sterker nog, zijn onderzoek is als het goed is met vrij grote hoeveelheden data. En dan is het juist handig om alles uit de kast van een database te trekken. Als een andere opslag efficienter is... waarom niet? Enkel de grootste gemene deler aan SQL testen geeft je geen goed beeld van de echte performance. Je wilt tenslotte een gedegen keuze maken en daarvoor mag je mijns inziens niet een testdatabase mankeren met de gezamelijke beperkingen van alle andere testdatabases.

't Nadeel is natuurlijk dat een gebrek aan kennis ook geen goed beeld geeft.

Recursieve queries doen het iig altijd goed; full tablescans wil je vermijden en indexen doe je niet aan - dat kan namelijk de performance beinvloeden. Da's een leuke uitdaging dus

full tablescans vermijden en niet aan indexen doen Je bedoelde vast wat anders, want effectief zeg je hier dat je geen data uit de database mag halen.
Als de database besluit dat het efficienter is om een full table scan te doen... laat 'm dat dan ook doen. En indexen wil je juist, want dat is tenslotte een potentiele differentiator van databases.

Tot slot: neem ook vooral tuningsparameters in je onderzoek. Zoals gezegd kunnen die een groot verschil maken. test met en zonder en vergelijk. Niet alleen interessant om te weten, maar ook mooi verdiepend qua onderzoek en je kijkt verder dan je neus lang is, vinden ze op school altijd fijn

Query tuning kan vaak nog meer performance opleveren dan efficienter geheugengebruik of een betere instelling van de disk-io. Dus staar je ook niet blind op het zoveel mogelijk gelijk houden van queries (kan toch al niet ivm je nosql-wensen).

[The Eagle]

@ACM: Ben het eens met wat je zegt, maar vergeet niet dat tuning nou juist net niet de insteek van zijn onderzoek is
Hij wil juist weten welke DBMS'en out of de box het best werken. Dan wil je dus zo weinig mogelijk extra zaken.
Ik weet ook wel dat indexen de boel sneller maken. Heck, Oracle maakt standard al een index aan op iedere PK. Alleen wil je voor zijn onderzoek iedere andere extra versnelling vermijden - anders kom je qua resultaten nooit eerlijk uit.
En wat ik met die full tablescans bedoelde is idd het zoveel mogelijk vermijden. Dat betekent dus goed naar je datasets kijken en zorgen dat je pinpoint queries maakt. Het gaat om sociale media, dus vaak om zaken die persoonsgebonden zijn. Dan wil je dus zo accuraat mogelijk (op de persoon / id) pinpointen
Als je daar een FTS voor nodig hebt is je query niet goed genoeg

[EfBe]

JaQ schreef op donderdag 27 januari 2011 @ 16:34:
[...]

Zelfs de Oracle handleiding weet niet wat een partitioned view is?
Is dit zo'n specialist feature die naast de go_fast parameter zit?

Beetje beter uit je ogen kijken mag best
http://download.oracle.co...r/doc/A48506/partview.htm. Tegenwoordig heten ze materialized views: http://download.oracle.co...r.920/a96567/repmview.htm

zelfde concept, je stored een query result op disk als table met indexes. Hiermee haal je hoge performance over vaak zeer zware queries. Bij DB optimalisatie zijn deze dingen onmisbaar (andere databases hebben soortgelijke constructies)

ACM schreef op donderdag 27 januari 2011 @ 22:21:
[...]
Dat de benchmark-omgeving in java ontwikkeld wordt is geen enkele garantie voor het winnen van Oracle's database. Sterker nog, de out-of -the-box performance van databases als PostgreSQL en MySQL zouden best beter kunnen zijn.

Daar geloof ik weinig van. Men zeurt altijd wel op Oracle, maar veelal komt dat gezeik uit de hoek van mensen die niet veel van databases af weten.

En als je queries uitvoert die goed op MapReduce aansluiten, dan zou een multi-node Cassandra (of ander NoSQL-systeem) ook zomaar veel sneller kunnen zijn.

NoSQL databases gebruiken indexes om data te vinden. MapReduce is een algorithme om die indexes te gebruiken of de data te indexeren. Of het sneller is is maar de vraag: ten eerste moet jouw query volledig door de index voldaan kunnen worden, wat lang niet altijd het geval is, en ten tweede is bij gebruik van indexes in RDBMS-s feitelijk hetzelfde aan de hand: je gebruikt ook daar een index om data op te halen. Wat is het verschil? Denk je nou echt dat de developers van de grote RDBMS-s (vergeet DB2 niet bv) zo dom zijn dat ze geen snelle index lookup / build code kunnen schrijven?

NoSql db's zijn in theorie wat sneller door het opslaan van denormalized data, en daar dan indices over maken. of ze sneller zijn dan materialized views / indexed views of hoe ze ook maar heten in de RDBMS naar keuze is niet gezegd: immers het mechanisme is feitelijk hetzelfde.

En nou komt ie: de data updaten is dan de grote bottleneck: denormalized data updaten kan een zeer langdurig proces zijn. Dus of het per saldo loont is maar zeer de vraag. De topicstarter zal dit in zn onderzoek dus moeten bekijken en daar een theoretische basis voor moeten vinden. Immers, constateren of te wel, kijken naar wat benchmarks, is geen onderzoek noch heb je er wat aan.

[ Voor 87% gewijzigd door EfBe op 30-01-2011 10:30 ]

[ACM]

EfBe schreef op zondag 30 januari 2011 @ 10:20:
Daar geloof ik weinig van. Men zeurt altijd wel op Oracle, maar veelal komt dat gezeik uit de hoek van mensen die niet veel van databases af weten.

Bij PostgreSQL zijn er ongeveer 3 configuratieparameters van belang voor goede performance - buiten de juiste tabelstructuur kiezen - bij MySQL ook zoiets. En de standaardwaarden laten je al vrij aardig bij de maximaal haalbare situatie komen. Is dat bij Oracle ook het geval?
Niet veel van databases weten is natuurlijk precies het scenario waarbij de defaults blijven voor wat ze zijn

Wat is het verschil?

Je las over 'multi-node' heen? Volgens mij voeren zowel (de standaardversies van) Oracle als DB2 hun queries nog steeds niet parallel uit over meerdere cpu's, laat staan meerdere nodes?

En nou komt ie: de data updaten is dan de grote bottleneck: denormalized data updaten kan een zeer langdurig proces zijn. Dus of het per saldo loont is maar zeer de vraag.

Het is absoluut waar dat nosql-databases doorgaans heel erg specifiek ingezet kunnen en moeten worden. En dat je ad-hoc queries door de manier van opslag soms uberhaupt niet uit kan voeren of op zijn minst ervoor moet programmeren. En de data denormalizen is inderdaad vooral nuttig om data triviaal op te zoeken of te schrijven, niet om meer afwijkende scenario's te proberen uit te voeren.

[The Eagle]

EfBe schreef op zondag 30 januari 2011 @ 10:20:
[...]

Beetje beter uit je ogen kijken mag best
http://download.oracle.co...r/doc/A48506/partview.htm. Tegenwoordig heten ze materialized views: http://download.oracle.co...r.920/a96567/repmview.htm

zelfde concept, je stored een query result op disk als table met indexes. Hiermee haal je hoge performance over vaak zeer zware queries. Bij DB optimalisatie zijn deze dingen onmisbaar (andere databases hebben soortgelijke constructies)

Ik weet niet wanneer jij voor het laatst met Oracle bezig bent geweest, maar je refereert hier aan een Oracle versie 7 (!) en 9i. Hoewel 9i sporadisch nog gebruikt wordt, is 10g inmiddels wijdverbreid en 11g al lang en breed de standaard voor nieuwe inplementaties. Ter info: 9i is minimaal een jaar of 9 oud, om over 7 maar te zwijgen

Bovendien: materialized view <> partitioned view. Bij een materialized view moet je je data periodiek verversen. Partitioning heeft daar geen last van maar slaat terug op de manier van logisch / fysiek opslaan van data.
Overigens weet JaQ wel waar ie over praat, hem kennende. Als er iemand op GoT een specialist op het gebied van Oracle is is hij het

[JaQ]

EfBe schreef op zondag 30 januari 2011 @ 10:20:
Beetje beter uit je ogen kijken mag best
http://download.oracle.co...r/doc/A48506/partview.htm. Tegenwoordig heten ze materialized views: http://download.oracle.co...r.920/a96567/repmview.htm

zelfde concept, je stored een query result op disk als table met indexes. Hiermee haal je hoge performance over vaak zeer zware queries. Bij DB optimalisatie zijn deze dingen onmisbaar (andere databases hebben soortgelijke constructies)

Je had toch niet echt verwacht dat ik die 7.3 optie niet gezien had? In 7.3 zijn heel kort partitioned views gebruikt, maar in 1995 is al gestopt met ontwikkelen aan partitioned views. Concreet betekent dit dat er al een aantal jaar geen support meer is voor een partitioned view. Bestaat het dan nog echt? Dodo's bestaan ook niet meer

Om te zeggen dat een materialized view de vervanger is, is overigens maar de helft van het verhaal. De andere helft is een techniek genaamd partitioning. Materialized views kunnen performance verhogend werkend, echter het gebruik van een materialized view is geenszins een garantie voor een hogere performance. Ik ken zelfs systemen die in zijn gestort omdat er per-se materialized views gebruikt werden (hint: on-commit je mviews bijwerken over een db-link in een remote-database heeft gevolgen voor je performance) Ook bestaan er zeer veel bugs in de cost based optimizer (die er in 7 nog niet was ) met materialized views, wat ook flinke gevolgen voor de performance van je selecties kan hebben.

Partitioning is ook niet per definitie een performance verhogende techniek, over het algemeen wordt partitioning ingezet voor administratie-gemak (precies daar waar het imho hoort). Je kan de performance van een systeem wel verhogen door partitioning te gebruiken, maar ook hier bestaat er zeker geen garantie (om nog maar even te zwijgen over de toegenomen licentiekosten van het geheel).

Kortom: ik vind dat jij boute uitspraken doet. Het "altijd waar" gehalte is iets te veel aanwezig, enige nuance lijkt mij op zijn plaats.

Al dit "kijk-mijn-piemel-eens-lang-zijn-gezeur" doet er natuurlijk allemaal niet toe voor de TS. Waar het wel om gaat is dat "even" een benchmark in elkaar klussen waarmee je vervolgens (R)DBMS-en gaat vergeleken een matige tot slecht gekozen afstudeeropdracht is, zelfs een club van specialisten kan hier geen eenduidig antwoord op geven. Ook tpc.org presteert het om vergelijkingen mank te laten gaan, bijvoorbeeld door gebruik van verschillende hardware. Out-of-the-box bestaat niet, want zelfs systeeminstellingen op het OS die niet relevant lijken op het eerste gezicht kunnen invloed hebben. Kortom: de "beste" database is over het algemeen de database waar je de meeste kennis van hebt. Als ik de TS was, zou ik snel de afstudeeropdracht terug geven en een minder breed, minder op buzz-woorden gebaseerde opdracht formuleren.

ACM schreef op zondag 30 januari 2011 @ 10:40:
Bij PostgreSQL zijn er ongeveer 3 configuratieparameters van belang voor goede performance - buiten de juiste tabelstructuur kiezen - bij MySQL ook zoiets. En de standaardwaarden laten je al vrij aardig bij de maximaal haalbare situatie komen. Is dat bij Oracle ook het geval?

Ik kop 'm in:
Bij Oracle is dat absoluut anders. De default set is "meestal" goed, echter er valt enorm veel te tweaken. Ik meen dat 11R1 al iets van 1600 verschillende parameters heeft. En dat zijn dan enkel de instance settings (dan hebben we het nog niet over storage clausules per tabel etc etc) Deze parameters hebben niet direct allemaal met performance te maken, maar combinaties kunnen toch grote invloed hebben.

Overigens: die 1600 verklaard wel waarom Oracle naar een self-managing database toe wil die vol zit met advisors en automatic-management tooling.

Aan de andere kant: bij exadata roept Oracle heel hard dat default al beter presteert dan een willekeurig door een dba getuned systeem. Toen ik zo'n 2 jaar geleden in het benchmarkcentrum van Oracle in Reading voor een klant met exadata aan het testen was kon ik direct deze claim bevestigen. De hoeveelheid rauwe I/O's die een database machine bied zijn echt fenomenaal (net zoals een aantal andere zeer coole features als query offloading etc etc). Out of the box is een database machine briljant snel, echter het is de vraag of dat het soort out of the box is dat de TS bedoelt

ACM schreef op zondag 30 januari 2011 @ 10:40:
Je las over 'multi-node' heen? Volgens mij voeren zowel (de standaardversies van) Oracle als DB2 hun queries nog steeds niet parallel uit over meerdere cpu's, laat staan meerdere nodes?

Voor een standard geldt dit inderdaad. Parallel query is pas vanaf enterprise edition een mogelijkheid (met licentiekosten tot gevolg). Zodra je echter een enterprise editie installeert wordt alles anders. Enkel door de hint "parallel" mee te geven aan een query, wordt deze parallel uitgevoerd (zonder dat je een systeeminstelling hebt aangeraakt). Je kan parallel-query niet uitschakelen als feature. In het geval van RAC wordt een query bij gebruik van de genoemde hint zelfs multi-node uitgevoerd (bij versies jonger dan 11R2. Vanaf 11R2 blijven queries default binnen 1 node). Uiteraard is RAC wel een optie die je apart moet aanzetten (met alle gevolgen van dien).

The Eagle schreef op zondag 30 januari 2011 @ 12:53:
Overigens weet JaQ wel waar ie over praat, hem kennende. Als er iemand op GoT een specialist op het gebied van Oracle is is hij het

Dank voor het vertrouwen (dit bedoel ik niet sarcastisch), maar ik kan me ook vergissen. Ben niet voor niets lid van de baag-party . Ik word erg vervelend van mensen die klakkeloos dingen van mij aannemen.

[ACM]

JaQ schreef op zondag 30 januari 2011 @ 19:15:
Ik kop 'm in:
Bij Oracle is dat absoluut anders. De default set is "meestal" goed, echter er valt enorm veel te tweaken. Ik meen dat 11R1 al iets van 1600 verschillende parameters heeft. En dat zijn dan enkel de instance settings (dan hebben we het nog niet over storage clausules per tabel etc etc) Deze parameters hebben niet direct allemaal met performance te maken, maar combinaties kunnen toch grote invloed hebben.

Oh, bij zowel PostgreSQL als MySQL zijn er nog wel wat meer parameters. En veel daarvan hebben ook wel invloed op de performance. Maar als je die belangrijkste paar (met name het geheugengebruik instellen) goed zet, dan heb je voor de meeste queries wel voldoende gedaan voor goede performance. De andere parameters zijn meer tunables die je eventueel op je specifieke gebruikssituatie kan afstemmen, maar waarvan de default meestal goed genoeg is.
Voor Oracle geldt zoiets vast ook wel. Ik kan me tenminste niet voorstellen dat zelfs bij de meer belastende oracle-opstellingen al die parameters allemaal bewust op een of andere waarde gezet (of gelaten) zijn

[JaQ]

ACM schreef op zondag 30 januari 2011 @ 20:15:
Oh, bij zowel PostgreSQL als MySQL zijn er nog wel wat meer parameters. En veel daarvan hebben ook wel invloed op de performance. Maar als je die belangrijkste paar (met name het geheugengebruik instellen) goed zet, dan heb je voor de meeste queries wel voldoende gedaan voor goede performance. De andere parameters zijn meer tunables die je eventueel op je specifieke gebruikssituatie kan afstemmen, maar waarvan de default meestal goed genoeg is.
Voor Oracle geldt zoiets vast ook wel. Ik kan me tenminste niet voorstellen dat zelfs bij de meer belastende oracle-opstellingen al die parameters allemaal bewust op een of andere waarde gezet (of gelaten) zijn

Ongetwijfeld bestaan er DBA's die je anders willen laten geloven, maar die nemen zichzelf veel te serieus. Ik ken misschien maar een handvol DBA's die daadwerkelijk begrijpen wat al die parameters doen, dat zegt denk ik wel genoeg (en ik hoor zelf niet tot dat selecte groepje )

[EfBe]

JaQ schreef op zondag 30 januari 2011 @ 19:15:
[...]
Je had toch niet echt verwacht dat ik die 7.3 optie niet gezien had? In 7.3 zijn heel kort partitioned views gebruikt, maar in 1995 is al gestopt met ontwikkelen aan partitioned views. Concreet betekent dit dat er al een aantal jaar geen support meer is voor een partitioned view. Bestaat het dan nog echt? Dodo's bestaan ook niet meer

Ik bedoelde materialized view, ik was met de naam in de war. Toen deed ik een google search (want ik werk voorn. met sql server, waar ze indexed views heten, vandaar) en keek niet goed wat 'partitioned views' waren. Ik had al gepost toen ik in mn ooghoek zag dat het over v7 ging, inderdaad erg oude troep. Anyway, ik bedoelde dus materialized views (indexed views op sql server) waar je een query result opslaat op disk. Was verder niet een 'kijk eens wat ik weet' opmerking, maar alleen een voorbeeld van db tuning wat gebruikt kan worden om een db sneller te maken, en die veelal niet bekend is bij mensen: benchmarking is daardoor erg lastig, omdat veelal niet alle tuning parameters bekend zijn bij de benchmarker en een database dus waarschijnlijk niet optimaal gebruikt wordt in de benchmark opstelling.

Om te zeggen dat een materialized view de vervanger is, is overigens maar de helft van het verhaal. De andere helft is een techniek genaamd partitioning. Materialized views kunnen performance verhogend werkend, echter het gebruik van een materialized view is geenszins een garantie voor een hogere performance. Ik ken zelfs systemen die in zijn gestort omdat er per-se materialized views gebruikt werden (hint: on-commit je mviews bijwerken over een db-link in een remote-database heeft gevolgen voor je performance) Ook bestaan er zeer veel bugs in de cost based optimizer (die er in 7 nog niet was ) met materialized views, wat ook flinke gevolgen voor de performance van je selecties kan hebben.

Tuurlijk hebben ze een prijs. Wanneer de data erg volatile is zal dat wellicht niet ten gunste komen van je materialized views. Wat heeft de optimizer trouwens hiermee te maken? Immers, een materialized view is steevast gebaseerd op een query die dermate lang duurt (relatief gezien) tov de query over de materialized view zelf dat ik me niet voor kan stellen dat de optimizer kan besluiten om de query zelf te runnen? Of bedoelde je dat niet?

Oracle heeft qua optimizer nog wel wat in te halen tov sql server btw, maar goed, dat is aan topicstarter om aan te tonen

Al dit "kijk-mijn-piemel-eens-lang-zijn-gezeur" doet er natuurlijk allemaal niet toe voor de TS. Waar het wel om gaat is dat "even" een benchmark in elkaar klussen waarmee je vervolgens (R)DBMS-en gaat vergeleken een matige tot slecht gekozen afstudeeropdracht is, zelfs een club van specialisten kan hier geen eenduidig antwoord op geven.

Dat was ook mijn punt

Ook tpc.org presteert het om vergelijkingen mank te laten gaan, bijvoorbeeld door gebruik van verschillende hardware.

tpc.org schrijft geen hw voor maar functionaliteit die geboden moet worden. Tuurlijk is het scheef, maar ieder die meedoet staat vrij om het optimale systeem te kiezen voor de beste resultaten. Je kunt redeneren dat dat 'niet eerlijk is' omdat de hardware en OS en transaction coordinator niet hetzelfde zijn, maar je kunt ook zeggen: het is juist eerlijker want alles is op elkaar afgestemd, dus je kunt niet zeggen: "jaaa, Oracle scoorde minder want ze moesten op Windows draaien".

Out-of-the-box bestaat niet, want zelfs systeeminstellingen op het OS die niet relevant lijken op het eerste gezicht kunnen invloed hebben. Kortom: de "beste" database is over het algemeen de database waar je de meeste kennis van hebt. Als ik de TS was, zou ik snel de afstudeeropdracht terug geven en een minder breed, minder op buzz-woorden gebaseerde opdracht formuleren.

Mee eens.

Voor een standard geldt dit inderdaad. Parallel query is pas vanaf enterprise edition een mogelijkheid (met licentiekosten tot gevolg). Zodra je echter een enterprise editie installeert wordt alles anders. Enkel door de hint "parallel" mee te geven aan een query, wordt deze parallel uitgevoerd (zonder dat je een systeeminstelling hebt aangeraakt). Je kan parallel-query niet uitschakelen als feature. In het geval van RAC wordt een query bij gebruik van de genoemde hint zelfs multi-node uitgevoerd (bij versies jonger dan 11R2. Vanaf 11R2 blijven queries default binnen 1 node). Uiteraard is RAC wel een optie die je apart moet aanzetten (met alle gevolgen van dien).

Raar dat je met query hints moet lopen kloten voor parallel execution van queries. Op sql server is dat gewoon een parameter op system level (enterprise edition, dat wel) en hij zoekt het zelf uit. Wanneer je een query schrijft weet je niet of parallel efficienter is of uberhaupt kan: dat weet je pas wanneer de query runt, en de optimizer kan dat prima zelf uitzoeken. Wellicht dat oracle's quest naar auto-managing hier verandering in gaat brengen

[xinq]

Bedankt voor alle reacties. Het topic heeft nogal een discussie opgeroepen, wat natuurlijk alleen maar goed is!

Ik begrijp idd dat de geformuleerde opdracht nog te algemeen is aangezien ik natuurlijk nooit een compleet overzicht kan krijgen met volledig betrouwbare resultaten. Ik moet dan ook nog de precieze grenzen van het onderzoek bepalen.

Na het lezen van alle reacties ben ik me, meer dan ooit, bewust van de vaagheid/incompleetheid van de geformuleerde opdracht.. Ik ga hier nog even heel goed over nadenken hoe ik het onderzoek het beste kan gaan uitvoeren / grenzen aan stellen. De afstudeeropdracht 'teruggeven' is echter geen optie, herformuleren is wel mogelijk: de opdrachtgever is flexibel en vind het het belangrijkst dat ik een goede afstudeeropdracht heb.

Mocht iemand een goede suggestie hebben voor het inperken van het onderzoek hoor ik dat uiteraard graag.
Nogmaals iedereen bedankt voor de goede, nuttige bijdrages tot zover!

[EfBe]

Voor wat voor opleiding is de afstudeeropdracht trouwens? Indien WO, is het wellicht beter de opdracht te herschrijven naar een onderzoek naar bv SQL executie pipelines binnen aantal databases en de theorie achter de optimalizaties die gedaan worden.

Immers, wat tabellen met stats, daar heeft niemand wat aan: inzicht in hoe SQL -> relational algebra -> execution plan geoptimaliseerd worden is wellicht nuttiger. Maar ik weet niet wat je opdrachtgever als bedoeling had met de opdracht, want je mag aannemen dat de opdracht zo geformuleerd is omdat men dat onderzocht wilde hebben en er een reden voor had.

[xinq]

Ik studeer Technische informatica (HBO). Vandaag nog met de opdrachtgever besproken over de invulling van het uit te voeren onderzoek. Hier is ongeveer het volgende uitgekomen:

Globale invulling

Het uit te voeren onderzoek zal grotendeels bestaan uit literatuuronderzoek op internet. De te ontwikkelen benchmarktool kan gebruikt worden om het literatuuronderzoek te onderbouwen / bevestigen.

Beschrijving invulling onderzoek enkele database
Dit wordt dan ongeveer de inhoud van het onderzoek naar een enkele database.

1. Beschrijving van de database
2. Kenmerken
3. Afwijkingen t.o.v. andere databases
4. Performance
5. Optimalisatie mogelijkheden beschrijven

Optimalisaties worden niet getest, tenzij simpel toe te passen. Wel worden de belangrijkste aanwezige optimalisaties toegelicht met uitleg wat dit kan betekenen in bepaalde situaties.

Doelstelling van de opdrachtgever is:
• Een betere database keuze kunnen maken voor project x.
• Een betere database keuze kunnen maken voor toekomstige projecten aan de hand van de informatie aanwezig in het onderzoeksrapport.

Waarbij project x gaat om:

1. Het ontwikkelen van crawlers die de gegevens van sociale netwerken verzamelen en onderling koppelen.
2. De implementatie van een database die de sociale data, geleverd via de crawlers (1), opslaat en beschikbaar stelt voor presentatie (3).
3. Het ontwikkelen van een applicatie die de grote hoeveelheden opgeslagen 'sociale data' op overzichtelijke wijze kan presenteren.

Echter is de opdrachtgever vrij flexibel qua invulling van de opdracht. De opdrachtgever vind het belangrijkst dat ik goed kan afstuderen met de opdracht. Concrete invulling van de opdracht is dan ook 'onderhandelbaar'..

[JaQ]

EfBe schreef op maandag 31 januari 2011 @ 08:34:
Oracle heeft qua optimizer nog wel wat in te halen tov sql server btw

Is dat zo? Ik weet lang niet voldoende over SQL-server om daar een gefundeerde uitspraak over te kunnen doen. Jonathan Lewis is een aardige reeks aan het schrijven waarin hij o.a. een en ander roept over de interne werking van SQL-server in vergelijking met Oracle. Ik krijg daar niet direct het idee dat SQL-server zoveel geavanceerder is (maar ik ben biast ).

EfBe schreef op maandag 31 januari 2011 @ 08:34:
Raar dat je met query hints moet lopen kloten voor parallel execution van queries. Op sql server is dat gewoon een parameter op system level (enterprise edition, dat wel) en hij zoekt het zelf uit. Wanneer je een query schrijft weet je niet of parallel efficienter is of uberhaupt kan: dat weet je pas wanneer de query runt, en de optimizer kan dat prima zelf uitzoeken. Wellicht dat oracle's quest naar auto-managing hier verandering in gaat brengen

Out of de box was de driver van mijn verhaal

Uiteraard kan je op database, instance, object en/of sessie niveau configureren of parallel query (PQ) gebruikt wordt, maar default is parallelism een optie die niet aan staat (want betaalde optie). Als vervolgens PQ "aan staat", bepaalt de CBO zelf of het "handig" is om PQ te gebruiken op basis van de aanwezige statistieken (indien geen statistieken aanwezig, dan wordt gesampeld).

[EfBe]

JaQ schreef op maandag 31 januari 2011 @ 15:15:
[...]
Is dat zo? Ik weet lang niet voldoende over SQL-server om daar een gefundeerde uitspraak over te kunnen doen. Jonathan Lewis is een aardige reeks aan het schrijven waarin hij o.a. een en ander roept over de interne werking van SQL-server in vergelijking met Oracle. Ik krijg daar niet direct het idee dat SQL-server zoveel geavanceerder is (maar ik ben biast ).

Nou die articles zijn behoorlijk tenenkrommend, eerlijk gezegd. Toegegeven, hij geeft zelf aan niets te weten van sql server wanneer hij begint, maar het rare is, hij denkt wel te kunnen oordelen hoe dingen werken in sql server. Verder veel data maar weinig informatie, en soms irritant dom gezever over irrelevante zaken, terwijl hij juist andere dingen negeert (bv sequentiele GUIDs in sqlserver). Maar goed, ik ben ook biased

Ik had het overigens over de optimizer. Bij dezelfde query (zonder hints) over hetzelfde schema op oracle vs. sqlserver zie je dat sql server veel vaker beter bij machte is om een optimaal execution plan te creeeren dan oracle, waar de plans nog wel eens overcomplex zijn zonder hulp van hints e.d. Het is nog niet zo erg als op DB2 waar je feitelijk zelf de query optimized.

Een optimizer die veelvuldig hints e.d. nodig heeft is IMHO dan ook niet op hetzelfde niveau. Dit was althans het geval een tijdje terug op 10g, geen idee of het veel verbeterd is op 11g. Ook weet ik niet of ze die rare OUTER JOIN rewrite naar FROM A, B WHERE A.FOO(+) = B.FOO er al uitgehaald hebben, immers je kunt daardoor minder goed joins optimizen wanneer je er meerdere hebt in 1 query plus loop je het risico bij meerdere LEFT JOINs dat de resultset niet klopt (omdat de (+) variant niet volledig het spectrum dekt van de outer join).

xinq schreef op maandag 31 januari 2011 @ 13:28:
Ik studeer Technische informatica (HBO). Vandaag nog met de opdrachtgever besproken over de invulling van het uit te voeren onderzoek. Hier is ongeveer het volgende uitgekomen:

Bij HBO afstudeeropdrachten gaat het feitelijk om het laten zien dat je de opdracht begrijpt, een ideale oplossing kunt verzinnen en die ook bouwen en dat bewijst mbv een verslag. Dus niet zozeer de theorie achter het gebeuren, maar meer een verslag welke afwegingen je hebt gemaakt, en waarom je A en niet B gekozen hebt.

Doelstelling van de opdrachtgever is:
• Een betere database keuze kunnen maken voor project x.
• Een betere database keuze kunnen maken voor toekomstige projecten aan de hand van de informatie aanwezig in het onderzoeksrapport.

Waarbij project x gaat om:

1. Het ontwikkelen van crawlers die de gegevens van sociale netwerken verzamelen en onderling koppelen.
2. De implementatie van een database die de sociale data, geleverd via de crawlers (1), opslaat en beschikbaar stelt voor presentatie (3).
3. Het ontwikkelen van een applicatie die de grote hoeveelheden opgeslagen 'sociale data' op overzichtelijke wijze kan presenteren.
Echter is de opdrachtgever vrij flexibel qua invulling van de opdracht. De opdrachtgever vind het belangrijkst dat ik goed kan afstuderen met de opdracht. Concrete invulling van de opdracht is dan ook 'onderhandelbaar'..

Je opdracht luidt dus specifiek voor 1 bepaald project. Je verslag zal dat dan ook moeten aangeven, dat de gebruikte conclusies niet kunnen worden toegepast op andere projecten, aangezien benchmarking feitelijk nonsense is als je denkt het algemeen te kunnen toepassen.

Je data is feitelijk non-volatile, dus het is louter inserts en selects, zonder transactions. Hier zijn NoSQL databases sneller in, alhoewel bij een groter entity model je wellicht meerdere overzichten wilt hebben / dwarsdoorsneden op de data, en dan loop je tegen limitaties aan door de starheid van een NoSQL DB's interne opslagstructuur. En aangezien ik 17 jaar geleden al ben afgestudeerd mag jij het nu fijn zelf verder doen

[ Voor 38% gewijzigd door EfBe op 01-02-2011 09:48 ]

[JaQ]

EfBe schreef op dinsdag 01 februari 2011 @ 09:39:
Maar goed, ik ben ook biased

En niet erg genuanceerd

EfBe schreef op dinsdag 01 februari 2011 @ 09:39:
Ik had het overigens over de optimizer. Bij dezelfde query (zonder hints) over hetzelfde schema op oracle vs. sqlserver zie je dat sql server veel vaker beter bij machte is om een optimaal execution plan te creeeren dan oracle, waar de plans nog wel eens overcomplex zijn zonder hulp van hints e.d.

Een optimizer die veelvuldig hints e.d. nodig heeft is IMHO dan ook niet op hetzelfde niveau. Dit was althans het geval een tijdje terug op 10g, geen idee of het veel verbeterd is op 11g.

Leuk thema voor een apart topic, deze uitspraken ondersteunen met feiten zal erg lastig blijken. Uiteraard kan je een specifieke case aantonen, maar een grootschalige test waarin je je gelijk haalt is niet zo gemakkelijk als het lijkt.

EfBe schreef op dinsdag 01 februari 2011 @ 09:39:
Ook weet ik niet of ze die rare OUTER JOIN rewrite naar FROM A, B WHERE A.FOO(+) = B.FOO er al uitgehaald hebben, immers je kunt daardoor minder goed joins optimizen wanneer je er meerdere hebt in 1 query plus loop je het risico bij meerdere LEFT JOINs dat de resultset niet klopt (omdat de (+) variant niet volledig het spectrum dekt van de outer join).

Ehhm? 10g, of zelfs 9R2 ?

nu weet ik dat er nog een aantal bugs op 9R2 en 10 waren met ansi joins, nested loops en verkeerde resultaten in specifieke conditities, maar daar gaat het nu niet om. sql-server is ongetwijfeld ook niet bug-vrij

Volgens mij is de documentatie vrij duidelijk over wat een outer join (de Oracle variant) wel of niet doet in Oracle. Als de resultaten niet overeenkomen met wat jij verwacht had, dan kunnen een paar situaties aan de hand zijn:
1. De resultaten kloppen echt niet
2. De resultaten komen overeen met wat jij verwacht had

Die tweede variant hoeft niet perse een bug in Oracle te zijn, dat kan ook een probleem met je resultaat-verwachting zijn. Ook mag je er niet vanuit gaan dat functienamen die gelijke namen dragen in verschillende databases ook dezelfde functionaliteit bieden. Zoals je zelf al zegt: je werkt voornamelijk met sql-server

Maar goed, ik hou op met dit topic te kapen. Dit voegt niets toe aan de vraag van de TS.

xinq schreef op maandag 31 januari 2011 @ 13:28:
Doelstelling van de opdrachtgever is:
• Een betere database keuze kunnen maken voor project x.
• Een betere database keuze kunnen maken voor toekomstige projecten aan de hand van de informatie aanwezig in het onderzoeksrapport.

Zou aanwezige kennis van de geteste database geen onderdeel van je onderzoek? Stel je kiest voor MongoDB, maar er is geen technische kennis en ervaring met Mongo aanwezig: is dat dan een verstandige keuze?

[ Voor 9% gewijzigd door JaQ op 01-02-2011 13:54 ]

[barfieldmv]

Mij lijkt het dat het bijhouden welke database het makkelijkst was op te zette/gebruiken en hoe lang je bezig was om een standaard test voor database X te implementeren ook interessante informatie is.

Misschien nog wel interessanter dan een niet database specifieke sql query in een niet 'goed' ingerichte database.

[EfBe]

JaQ schreef op dinsdag 01 februari 2011 @ 13:52:
[...]
En niet erg genuanceerd

Waarom moet ik genuanceerd doen over een serie artikelen die behalve veel feitjes weinig bijdragen?

[...]
Ehhm? 10g, of zelfs 9R2 ?

nu weet ik dat er nog een aantal bugs op 9R2 en 10 waren met ansi joins, nested loops en verkeerde resultaten in specifieke conditities, maar daar gaat het nu niet om. sql-server is ongetwijfeld ook niet bug-vrij

Hey, mijn dagelijks werk omvat het schrijven van O/R mappers, ik weet welke Oracle versie ansi joins ondersteunt etc. Dat was mijn punt niet.

Ik doelde op de optimizer die ansi joins omschrijft in oracle operator joins:
http://blogs.oracle.com/o...outerjoins_in_oracle.html
Ipv het doen van hash lookups zoals bij sql server doen ze een where clause based join.

Ik zeg niet dat de ansi joins van oracle niet de juiste resultaten opleveren, dat doen ze wel, maar dat het execution plan minder efficient kan zijn: als je 3 sets joins met daarin 2 met een miljoen rows en 1 met 4 rows, dan moet je beginnen met die met 4 rows, maar daar kom je bij een where based join systeem pas achter wanneer je ze alle 3 geprocessed hebt. (laten we stellen dat er geen FK's beschikbaar zijn tussen de tables)

Volgens mij is de documentatie vrij duidelijk over wat een outer join (de Oracle variant) wel of niet doet in Oracle. Als de resultaten niet overeenkomen met wat jij verwacht had, dan kunnen een paar situaties aan de hand zijn:
1. De resultaten kloppen echt niet
2. De resultaten komen overeen met wat jij verwacht had

Die tweede variant hoeft niet perse een bug in Oracle te zijn, dat kan ook een probleem met je resultaat-verwachting zijn. Ook mag je er niet vanuit gaan dat functienamen die gelijke namen dragen in verschillende databases ook dezelfde functionaliteit bieden. Zoals je zelf al zegt: je werkt voornamelijk met sql-server

Maar goed, ik hou op met dit topic te kapen. Dit voegt niets toe aan de vraag van de TS.

Je leest niet goed, ik doelde op de (+) oracle left joins die niet kloppen soms, dat is niet Oracle's schuld, iedere query syntaxis die FROM A, B WHERE <predicate> en in de predicate een vorm van join directie aangeeft dmv een character (bv *= in sqlserver) is niet bij machte alle queries goed te doorstaan bij meerdere left joins (omdat bij ansi left joins de 1e null values de volgende left join set kleiner maken, maar bij een where clause based join dat niet het geval is)

[ Voor 9% gewijzigd door EfBe op 01-02-2011 20:31 ]

[xinq]

Bedankt allemaal voor jullie inhoudelijke reacties. Is erg behulpzaam:)!

[voodooless]

ACM schreef op zondag 30 januari 2011 @ 10:40:
Bij PostgreSQL zijn er ongeveer 3 configuratieparameters van belang voor goede performance ... En de standaardwaarden laten je al vrij aardig bij de maximaal haalbare situatie komen.

Ehm... niet echt. De default waardes waren misschien 5 tot 10 jaar geleden best oke, maar tegenwoordig krijg je echt een brakke default config. Een en ander is ook wel afhankelijk van wat je doet natuurlijk, maar voor serieus grote databases moet je echt wel behoorlijk wat sleutelen.

Verder moet je nog een afweging maken tussen data integrity en performance. Bij de meeste DB's kun je hier wel een keuze in maken waar je meestal het een voor het ander moet inleveren.

Verder lijkt het me niet zo lastig om de diverse SQL databases met elkaar te vergelijken, maar ook daar heb je per db weer diverse tips en tricks om dingen optimaal te doen. Ga je echter ook kijken naar no-SQL spul, dan wordt het een ander verhaal. Die hebben een heel andere benadering en dat moet je dus ook heel anders aanpakken.

Ik zou gewoon een high-level interface definieeren, waaronder je diverse implementaties kan hangen, die je voor zover mogelijk optimaal kunt implementeren voor de onderliggende database.

[ACM]

voodooless schreef op donderdag 17 februari 2011 @ 17:59:
Ehm... niet echt. De default waardes waren misschien 5 tot 10 jaar geleden best oke, maar tegenwoordig krijg je echt een brakke default config. Een en ander is ook wel afhankelijk van wat je doet natuurlijk, maar voor serieus grote databases moet je echt wel behoorlijk wat sleutelen.

Voor serieus grote databases moet je altijd meer moeite doen ja... Dat geldt vziw voor elk database-systeem. Maar van de parameters die invloed op de performance hebben staat het meeste wel op een vrij bruikbare default die doorgaans wel dataveiligheid boven performance stelt.

Met name shared_buffers en effective_cache_size moet je aanpassen. De rest is vooral optioneel en afhankelijk van je type belasting. En het is daarbij uiteraard wel zo dat dat optionele karakter wel steeds verder verdwijnt naar mate je de database zwaarder belast of je een specifiek pijnpunt aanraakt met je belasting.

Zie ook dit overzicht, met name ook de wijzigingen die in 8.4 en later in 9.1 aangepast zijn.