Databaseserver en -software vergelijking
Conclusie
Hoewel dit artikel zeker niet bedoeld is om het laatste en volledige antwoord te geven op de vraag wat nou de beste databasesoftware en -hardware is, willen we met deze test wel een fundering leggen voor een serie van toekomstige artikelen die over hetzelfde onderwerp gaan. Er staat een aantal interessante nieuwe ontwikkelingen te gebeuren dit jaar, waaronder de introductie van Intels Xeon 'Dempsey', de Socket F Opteron van AMD met DDR2-geheugen en natuurlijk ook Intels Woodcrest.
Hoewel we van AMD dit jaar geen grote verbeteringen meer verwachten, ligt de lat voor Intel hoger - het bedrijf heeft dan ook aardig wat achterstand om in te halen. De roadmaps geven aan dat de situatie zoals die er nu ligt aan het einde van het jaar drastisch anders zal zijn: een van de redenen waarom de dualcore Xeon in deze test niet harder wilde gaan dan zijn singlecore broertje is zijn beperkte bandbreedte: met vier cores op één 6,4GB/s bus werken is duidelijk geen pretje. Binnenkort verschijnt er echter een nieuwe chipset met een dubbele FSB en vier kanalen FB-DIMM, waardoor de beschikbare bandbreedte meer dan verdubbelt naar 17GB/s. De 65nm Xeon-processors die daarbij horen laten zich bovendien een heel stuk hoger klokken: we hebben hier een 2,8GHz Paxville onder de loep genomen, maar Dempsey zal beschikbaar zijn tot en met 3,73GHz.
Binnen een half jaar na Dempsey verschijnt Woodcrest, die de bandbreedte nog eens extra opvoert naar 21,3GB/s. Bovendien is deze chip gebaseerd op de volledig nieuwe architectuur die ook in Conroe en Merom terug te vinden zal zijn. Eén van de belangrijkste dingen die hiermee wordt aangepakt is het stroomverbruik van de Xeons: Dempsey krijgt nog een TDP van 150 watt mee, wat vergeleken met de 95 watt Opterons erg veel is. Woodcrest zal het verbruik naar verluidt bijna halveren (naar 80 watt), terwijl het tegelijkertijd betere prestaties belooft. Dat Intel ons aan het einde van het jaar een veel beter product zal kunnen bieden dat we nu getest hebben lijkt zo ongeveer vast te staan, maar de grote vraag is natuurlijk hoeveel beter, en of het ook genoeg is om de Opteron van de troon te stoten. Merom en Conroe mogen in vroege tests dan wel indrukwekkende resultaten neerzetten tegenover de Athlon 64 X2, maar een serverconfiguratie waarin twee processors moeten samenwerken is toch andere koek dan de een chip die op zichzelf goed werkt.
Omdat we hier feitelijk maar één soort toepassing hebben getest kunnen we in dit artikel geen definitieve conclusies trekken over welke processor of databasepakket nou 'het beste' is, maar we zijn duidelijk onder de indruk van de prestaties van de dualcore Opteron, en ook MySQL 5.0 was voor ons een positieve verrassing. Intels Xeons zouden het in andere taken misschien beter kunnen doen, maar in ons geval stellen ze teleur: vooral de dualcore-versie lijkt zijn geld niet waard te zijn. Hoewel dat later in het jaar weer helemaal kan veranderen, moeten we op dit moment concluderen dat we nog steeds liever voor AMD gaan.
Dankwoord
Tweakers.net wil Robin Kuepers (Dell), Alex Vellinga (Melrow), Matty Bakkeren (Intel) en Winnie Silvertand (Whizpr / AMD) bedanken voor hun medewerking aan dit artikel. Verder dank aan onze eigen Femme, Kees, ACM en moto-moi voor het opzetten en uitvoeren van de tests en hun waardevolle inzichten voor het schrijven van dit artikel.
Inhoudsopgave
Reacties (46)
Ik ben bang dat AMD niet zo gek veel in het vat heeft komend jaar. Dit is tenminste de tendens in de berichtgeving op diverse sites.
Op single core werkt het wel (Heb ik al eens eerder vergeleken en op 2 test (van de 15) na kwam met Ht er beter uit)
Alleen net iets lagere geheugenlees en schrijfsnelheid (0,1% of zo)
Maar met meerdere cores is het dus BS om Ht aan te zetten gewoon niet doen dus.
In deze test worden de pagina dus 'niet echt' gegenereerd?!
Ik zat namelijk vandaag te knoeien om de resultaten van een querie netjes op het scherm te drukken maar de opbouw van de pagina heeft ook nog eens veel impact op de totale load
De database server maakt het niet veel uit hoe en wanneer hij queries ontvangt!
Het genereren van de pagaina, de opbouw e.d. kost inderdaad veel rekenkracht ook, en de webservers hebben het daar ook wel zwaar mee, maar dat is niet aan de database gerelateerde load, dus die konden we voor deze test weglaten. Als we webserversoftware zouden testen dan was het inderdaad een kwestie van de pagina compleet genereren en 'laten zien', maar nu het puur om de queries gaat is dat niet gebeurd.
eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Het is zeker de bedoeling om dit vaker te gaan doen, dus wie weetvraag me hier dus wel heel erg af, wat de geintergreerde geheugen controler voor de nieuwe Amd64 x2 chipjes zal opleveren, zou in ieder gevaal zeer benieuwd zijn naar een zelfde soort onderzoek tegen die tijd.
.Het probleem daarbij is dat de code van Tweakers.net zwaar geoptimaliseerd is voor MySQL en zich dus niet zo makkelijk laat overzetten naar een andere database. Zelfs als het in een keer zou werken zou je weer hele andere trucs moeten gaan toepassen om de optimale prestaties te krijgen, en dat kost veel tijd. Nu dat gezegd is kan ik verklappen dat we hebben geprobeerd om Tweakers.net op PostgreSQL te testen, maar dat is om verschillende redenen fout gelopen en het resultaat daarvan hebben we dus achterwege gelaten. Wellicht komt dat echter nog terug in een toekomstig artikel.eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
Heel de frontpage van de site draait op één database. Query cache staat automatisch aan voor alle tabellen, maar degene waarin veel geschreven wordt profiteren er minder van.wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking) is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Puur uit interesse, wat valt er aan MySQL zo specifiek zwaar te optimaliseren waardoor het dan ook nog eens voor SQL code zorgt die niet meer portabel is naar andere engines ?Het probleem daarbij is dat de code van Tweakers.net zwaar geoptimaliseerd is voor MySQL en zich dus niet zo makkelijk laat overzetten naar een andere database.
Op die manier vervalt heel het voordeel van SQL als 'structured query language' IMHO...
Om je toch niet met een kluitje in het riet te sturen:
MySQL kan pas subqueries sinds 4.1, dus daarvoor moest je truckjes uithalen om hetzelfde effect te bereiken door de queries niet erg optimaal te herschrijven of door ze op te splitsen en de resultaten van "sub"queries eerst apart te verwerken in je applicatie.
MySQL gebruikte tot voor 4.1 de functie "concat" om iets vergelijkbaars als || te doen, maar niet het helemaal hetzelfde. Evenzo voor diverse andere functies, ze zijn/waren vaak net anders genoemd en/of werkten net even anders dan de standaardfunctionaliteit.
MySQL laat het toe dat je een langere select list hebt dan je group by list en dan heb ik het niet over de aggregations in de SL.
En zo zijn er nog heel wat meer. Veel van de queries konden overigens met redelijk beperkte aanpassingen toch werken in PostgreSQL. Maar aangezien PostgreSQL relatief tov MySQL slecht presteert met hele lichte queries was het nuttig en bijna noodzakelijk om met name die opsplitsingen van queries terug te draaien.
Ondanks die "terugdraaiingen" zijn er nog zat andere stukken code die kunnen profiteren van het opnieuw doordenken van de structuur en/of de queries.
Op zich heb je gelijk dat dat interessant is. Zoals Wouter al zegt, we hebben wel PostgreSQL in eerste instantie ook gebenchmarked. In de optimalisatie van de queries ging echter behoorlijk wat tijd zitten en juist daardoor gingen we enerzijds meer fouten introduceren en werden anderzijds de resultaten minder goed vergelijkbaar. Een redelijk belangrijke conclusie die ik je er nog wel over kan geven is dat ondanks de niet vergelijkbare resultaten (met mysql), gaven de cijfers ook bij PostgreSQL hetzelfde beeld als MySQL doet. Zowel voor HT als de dual-coreoplossingeneigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
Nee, dat gaat niet zo maar. Veel van de queries combineren diverse tabellen weer met elkaar (bijvoorbeeld de username bij de reacties). Sterker nog, in de praktijk zijn er maar een paar waar relatief veel in geschreven wordt en een vrij groot aantal waar relatief weinig in geschreven wordt. Maar zelfs voor de reactietabel moet je niet vergeten dat er hooguit een paar nieuwe reacties per minuut bijkomen, terwijl er in dezelfde tijd misschien wel 10x zoveel views op reacties zijn geweest.wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Het is daarom ook "minder effectief" niet gelijk totaal zinloos bij de meeste van onze queries
Dit artikel heeft een beperkte strekking, namelijk die van een webdatabase-server. MySQL wordt vanwege de lage kosten, afdoende mogelijkheden en goede prestaties veel gebruikt voor webdatabases. Oracle wordt gebruikt voor hele andere toepassingen waarvoor wij geen simulatie voorhanden hebben die is gebaseerd op omgeving uit de echte wereld.eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
MS SQL zou wel een mooie toevoeging zijn omdat het veel wordt gebruikt voor websites die op Windows-systemen draaien.
Over het algemeen geldt dat alle tabellen in de Tweakers.net-database een hoge verhouding reads hebben ten opzichte van writes, behalve de tabellen waar vrijwel uitsluitend in geschreven wordt (met name statistieken). Dit zal voor veel webdatabases het geval zijn. Ik denk dat wij zelfs aan de hoge kant wat betreft writes zitten ivm de veelvuldig voorkomende mutaties in de Pricewatch, de reactietabellen en user/sessietabellen door het toevoegen of wijzigen van prijzen en user moderaties. Desondanks worden er toch veel meer views gedaan dan mutaties.wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Op de statstabellen heeft de query cache weinig overhead omdat er nauwelijks SELECT's op die tabellen gedaan worden en er dus ook weinig in de cache getrashed kan worden.
) dat de singlecore Xeon simpelweg als eerste is getest en dat het niet de moeite waard was om die later nog een keer opnieuw te doen (gezien de lage I/O-activiteit).De dual 3.8 Ghz hing tegen die tijd echter al in ons rack en konden we niet meer opnieuw testen. Voor de performance maakte het verder geloof ik niks uit en anders een heel klein beetje. De oplettende bezoeker zal misschien herkend hebben dat de 3.8Ghz configuratie precies overeenkomt met die van de forum-searchserver Aphrodite en de 3.4Ghz met de fileserver Atlas
Ik hou het op een combinatie van factoren, want ook bij de relatief snelle bus (tov aantal cpu's en snelheid ervan) bij de Dual Opteron 254 zaten de cpu's niet vol.
is misschien goed om te weten voor degenen met een relatief kleine dataset dat zou de keuze voor een grote array of meer ram makkelijker kunnen maken(als er een compromis gemaakt moet worden, en we blijven natuurlijk nederlanders he).
In deze test wordt daarnaast minder in de database geschreven dan in onze productieomgeving. Dat zorgt er dus voor dat de data in de caches van de database en de diskcache van het OS minder snel verouderen en er dus ook om die reden minder diskactiviteit nodig is.
Maar ik denk dat je doorgaans met meer ram meer bereikt dan een versnelde I/O. Met name omdat ram tot op zekere hoogte relatief goedkoop is, terwijl I/O al vrij snel behoorlijk prijzig kan worden.
Desalniettemin moet je natuurlijk ook weer uitkijken met een onderbemeten I/O-systeem, want dan kan het zijn dat het wachten op writes zo lang duurt dat je alsnog daar problemen door ondervindt.
In veel gevallen kun je beter je geld in meer geheugen en snellere disks steken, dan snellere cpu's overigens. Tenzij je een kleine actieve dataset hebt (die dus volledig in het geheugen past) en je daar veel rekenintensieve queries op los wilt laten, uiteraard.
Maar een buffer is natuurlijk wel handig om wat sneller te zijn. En met een Raidset heb je meerdere schijfbuffers die veel sneller werken als het echte schijfoppervlak.
edit: - En wat hierboven al staat er zit ook nog RAM geheugen voor dus is de RAID-set niet echt nodig.
Transfer rate is (zeker in dit geval) niet de juiste manier om te meten hoe druk een HDD het heeft. Helaas geven alle/veel niet aan welk gedeelte van de tijd een HDD bezig of idle is.Er stond 600 kb/s dus het ligt dus duidelijk niet aan de harde schijven dan zou zelfs een eeuwenoude harddisk uit 1995 genoeg zijn die haalde ook al makelijk 4MB/s.
Ik vind het deel van mySql 4.x en 5.0 erg interessant.
Hebben jullie bij de test gebruik gemaakt van een PHP script?
Daar heb je op dit moment namelijk ook het verschil van de mysql en mysqli library.
De mysqli staat voor mysql Improved en zou veiligheid en snelheids verbeteringen met zich mee moeten brengen.
Hebben jullie hier al wat mee getest toevallig? Voor- en/of na-delen van gevonden?
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
