Ik mis SQLite als DB.
Verder is het misschien voor MySQL handiger verschil te maken tussen MySQL en MySQLi als verbindend component.
69 views
Frank: inderdaad, dat is een veelgequote benchmark. Maar het gaat over schaalgedrag, dus dat bij hogere loads mysql het moeilijk krijgt. Tweakers heeft echter heel weinig vrijgegeven over de testomgeving, en welke query's ze hebben gedaan. Ik vind het daarom lastig iets zinnigs over te zeggen, behalve dat het een aardig grafiekje lijkt ;) Ook staat er dat ze hun standaard omgeving waarmee ze werken voor mysql moesten ombouwen omdat er anders geen vergelijking was met postgresql (ik weet ook niet wat ik daar nu van moet vinden: "normaal gesproken is onze mysql veel sneller?")
Kortom: ik vind het een verwarrende test die niet perse als vergelijking tussen pgsql en mysql is bedoeld en wel door velen zo wordt aangehaald (ook de laatste dev versie van pgsql en een wat verouderde mysql versie, pietke apart).
Ik zie weinig benchmarks over postgresql vs mysql, en in de tests die er zijn lijkt het overduidelijk dat pgsql sinds de 8.0 serie er een stuk sneller op is geworden.
Voor mij zijn deze loads en snelheden niet een reden om voor postgresql te kiezen. Helderheid, duidelijkheid en functionaliteit (perl inbouwen in je eigen database, wat wil een mens nog meer?)
[Edit: Hee, mijn commentaar op de test ging over een vorige test, ik zie dat deze al uitgebreider gedocumenteerd is!]
Kortom: ik vind het een verwarrende test die niet perse als vergelijking tussen pgsql en mysql is bedoeld en wel door velen zo wordt aangehaald (ook de laatste dev versie van pgsql en een wat verouderde mysql versie, pietke apart).
Ik zie weinig benchmarks over postgresql vs mysql, en in de tests die er zijn lijkt het overduidelijk dat pgsql sinds de 8.0 serie er een stuk sneller op is geworden.
Voor mij zijn deze loads en snelheden niet een reden om voor postgresql te kiezen. Helderheid, duidelijkheid en functionaliteit (perl inbouwen in je eigen database, wat wil een mens nog meer?)
[Edit: Hee, mijn commentaar op de test ging over een vorige test, ik zie dat deze al uitgebreider gedocumenteerd is!]
Heb verder niet alles gelezen, maar ik meen me te herinneren dat InnoDB geen FULLTEXT search ondersteunt, maar MyISAM wel?
Zelf heb ik daar nog nooit last van gehad, en gebruik ik dus ook zoveel mogelijk InnoDB (Als ik het niet vergeet, heb hem nog niet standaard gezet..)
Zelf heb ik daar nog nooit last van gehad, en gebruik ik dus ook zoveel mogelijk InnoDB (Als ik het niet vergeet, heb hem nog niet standaard gezet..)
Arend, je hebt volkomen gelijkt, het blijft lastig om te benchmarken en om iets zinnigs te doen met de resultaten.
Je kunt pas écht vergelijken wanneer je voor beide omgevingen een voor jouw specifieke applicatie een zo optimaal mogelijk systeem hebt neergezet. Het resultaat is dan dat je weet welke database voor dat systeem de beste keuze is. Het zegt weinig tot niets over een totaal andere applicatie. Probleem is verder, wie gaat er nu 2x hetzelfde systeem bouwen voor 2 verschillende databases? Dat wordt redelijk kostbaar.
En daarnaast blijft er natuurlijk altijd de vraag of je gaat vergelijken met MyISAM of met InnoDB. Het is dus van belang om te weten welke risico's (uitgedrukt in tijd en/of geld) je loopt wanneer de database corrupt raakt wegens ontbrekende foreign keys. Naar mijn mening kun je MyISAM nooit vergelijken met PostgreSQL, je hebt namelijk al de keuze gemaakt dat FK's en andere dbms-functionaliteit voor jou niet van belang is.
Mijn (belangrijkste) redenen om PostgreSQL te gebruiken op een rijtje:
- Data-integriteit is gewaarborgd
- Houd zich aan de SQL-standaard (vinden dba's wel zo handig!)
- Database verzint geen niet-bestaande resultaten
- PL-programming (dus een eenvoudige interface voor de PHP of .NET prog.)
- Is goed te verkopen als 'de opensource Oracle-database' (marketing...)
- Rete snel met complexe queries (PL-functies) in de systemen die wij bouwen
De data-integriteit en de vergelijking met Oracle zijn voor ondernemers dé redenen om met ons (en dus PostgreSQL) in zee te gaan. De systemen die wij bouwen zijn redelijk complex, op dit moment zijn we bezig met een systeem dat bestaat uit zo'n 150 tabellen en 1300 PL-functies.
In MySQL zou dit niet, of zeer lastig, te bouwen zijn, het maakt geen gebruik van objecten en schema's. We zouden dan alles in PHP moeten bouwen, dat kan, maar dan kun je onmogelijk hetzelfde product ook in .NET of JSP aanbieden (tegen redelijke kosten). Nu is dat een fluitje van een cent. En mocht iemand t.z.t. willen overschakelen naar Oracle (geen idee waarom je dat zou willen), dan is dat mogelijk. PL/SQL van Oracle lijkt zeer sterk op PL/pgSQL wat je in PostgreSQL vindt.
Dat was het wel zo'n beetje!
Edit: Ik wil hierbij Bas Kregeler ook nog even bedanken voor het plaatsen van de poll. Dit onderwerp was namelijk mijn idee.
Je kunt pas écht vergelijken wanneer je voor beide omgevingen een voor jouw specifieke applicatie een zo optimaal mogelijk systeem hebt neergezet. Het resultaat is dan dat je weet welke database voor dat systeem de beste keuze is. Het zegt weinig tot niets over een totaal andere applicatie. Probleem is verder, wie gaat er nu 2x hetzelfde systeem bouwen voor 2 verschillende databases? Dat wordt redelijk kostbaar.
En daarnaast blijft er natuurlijk altijd de vraag of je gaat vergelijken met MyISAM of met InnoDB. Het is dus van belang om te weten welke risico's (uitgedrukt in tijd en/of geld) je loopt wanneer de database corrupt raakt wegens ontbrekende foreign keys. Naar mijn mening kun je MyISAM nooit vergelijken met PostgreSQL, je hebt namelijk al de keuze gemaakt dat FK's en andere dbms-functionaliteit voor jou niet van belang is.
Mijn (belangrijkste) redenen om PostgreSQL te gebruiken op een rijtje:
- Data-integriteit is gewaarborgd
- Houd zich aan de SQL-standaard (vinden dba's wel zo handig!)
- Database verzint geen niet-bestaande resultaten
- PL-programming (dus een eenvoudige interface voor de PHP of .NET prog.)
- Is goed te verkopen als 'de opensource Oracle-database' (marketing...)
- Rete snel met complexe queries (PL-functies) in de systemen die wij bouwen
De data-integriteit en de vergelijking met Oracle zijn voor ondernemers dé redenen om met ons (en dus PostgreSQL) in zee te gaan. De systemen die wij bouwen zijn redelijk complex, op dit moment zijn we bezig met een systeem dat bestaat uit zo'n 150 tabellen en 1300 PL-functies.
In MySQL zou dit niet, of zeer lastig, te bouwen zijn, het maakt geen gebruik van objecten en schema's. We zouden dan alles in PHP moeten bouwen, dat kan, maar dan kun je onmogelijk hetzelfde product ook in .NET of JSP aanbieden (tegen redelijke kosten). Nu is dat een fluitje van een cent. En mocht iemand t.z.t. willen overschakelen naar Oracle (geen idee waarom je dat zou willen), dan is dat mogelijk. PL/SQL van Oracle lijkt zeer sterk op PL/pgSQL wat je in PostgreSQL vindt.
Dat was het wel zo'n beetje!
Edit: Ik wil hierbij Bas Kregeler ook nog even bedanken voor het plaatsen van de poll. Dit onderwerp was namelijk mijn idee.
Frank:
Helaas heeft ook InnoDB nog flink wat typische MySQL problemen.
Heb het gelezen, ben er nogal van geschrokken. Ik heb geen onderzoek gedaan naar de betrouwbaarheid van MySQL en nu blijkt dit dus aan alle kanten te rammelen. Tijd om me eens te oriënteren op iets beters.
Bedankt voor de link!