PostgreSQL eller MySQL: Belastningen afgør, hvilken der er hurtigst

Hverken PostgreSQL eller MySQL er hurtigst til alle opgaver. Et system med mange ordreindsættelser kan få en anden vinder end et system, hvor store joins bestemmer svartiden. Valget afhænger derfor af, hvilke forespørgsler databasen skal udføre, hvor ofte de kører, og hvor længe brugerne kan vente.

I et offentliggjort benchmark af PostgreSQL 16.1 og MySQL 8.3.0 førte PostgreSQL ved simple opslag med 142.345 mod 138.921 forespørgsler i sekundet. MySQL førte ved ordreindsættelser med 87.234 mod 81.523 i sekundet og ved blandet OLTP med 12.845 mod 11.932 transaktioner i sekundet. En analytisk join tog derimod 3,42 sekunder i PostgreSQL mod 5,87 i MySQL. Det er resultater for de beskrevne konfigurationer og opgaver, ikke en samlet rangliste over databaserne.

Hvad testens opsætning betyder for resultatet

Benchmarkets server havde otte virtuelle processorer og 64 GB hukommelse. Datasættet rummede blandt andet brugere, ordrer, produkter og logposter, og begge databaser kørte med tilpassede hukommelsesindstillinger og hver sin forbindelsespulje. En måling af den art omfatter både databasemotor, skema, indeks, indstillinger og måden, klienterne opretter forbindelse på. Den isolerer ikke hastigheden af ét produkt under alle andre tænkelige forhold.

Antallet af samtidige forbindelser var heller ikke det samme i prøverne med opslag og indsættelser. Det er rimeligt at sammenligne PostgreSQL og MySQL inden for hver prøve, men et tal for opslag i sekundet kan ikke uden videre holdes op mod et tal for indsættelser. Operationerne udfører forskelligt arbejde og møder forskellige flaskehalse. En lille fordel ved et enkelt nøgleopslag kan desuden få mindre betydning, hvis applikationens ventetid primært ligger i større transaktioner.

MySQLs vejledning om benchmarking fremhæver, at en forskel på få procentpoint kan skifte fortegn i en anden opsætning. Det gælder især, når datamængde, indeks eller konfiguration ændres. En benchmarkplacering er mest brugbar, når forespørgsel, belastning og måleenhed ligner den opgave, man faktisk skal løse.

Opslag og skrivninger har flere former

Det simple opslag i testen hentede en brugerrække efter id. Sådan et opslag siger noget om korte forespørgsler med en kendt nøgle, men langt mindre om filtrering på flere felter, brede resultatsæt eller opslag, der kræver et join. Hvis sådanne søgninger fylder mest i en applikation, er det deres svartider, der bør veje tungest.

MySQLs forspring ved indsættelser gjaldt ordrer med testens konkrete skema og indeks. Skrivearbejde kan også være opdateringer af eksisterende rækker, indsættelser i portioner eller transaktioner, der ændrer flere tabeller. I samme offentliggjorte test førte PostgreSQL ved den særskilte opdatering af brugerrækker. Betegnelsen »skrivebelastning« er derfor for grov til at pege på en vinder: operationens form og de indeks, som skal vedligeholdes, ændrer arbejdet.

Et andet eksperiment viser, hvor meget opsætningen betyder. DoltHubs Sysbench-målinger gav PostgreSQL lavere median svartid end MySQL ved blandt andet enkeltstående indsættelser og blandede læse- og skriveopgaver, mens MySQL var hurtigere ved en bestemt indekseret join. Her blev PostgreSQL 15.5 og MySQL 8.0.35 kørt med standardindstillinger på en mindre server; tabellerne kunne ligge i hukommelsen, og prøverne målte korte enkeltforespørgsler uden samtidige klienter. Resultaterne modsiger ikke en måling af gennemløb under høj samtidighed: både metrik og arbejdsbelastning er anderledes.

Blandet OLTP og analytiske joins

MySQL førte i benchmarkets blandede OLTP-prøve, hvor korte transaktioner kombinerede læsninger og skrivninger. Resultatet er relevant for en tjeneste med en tilsvarende fordeling og tilsvarende transaktionsindhold. To systemer kan dog begge kalde noget en transaktion, selv om det ene udfører langt flere SQL-kommandoer end det andet. Transaktioner i sekundet giver først mening som sammenligning, når arbejdet pr. transaktion er sammenligneligt.

Den analytiske prøve stillede et andet krav: brugere og ordrer blev koblet, grupperet og sammenfattet. Her er det afgørende, hvilke rækker der vælges, hvordan tabellerne forbindes, og hvor meget data der skal aggregeres. PostgreSQLs kortere tid i netop den prøve er en grund til at give rapportforespørgsler selvstændig vægt, hvis de er vigtige for systemet. Højere gennemløb for korte transaktioner fortæller ikke, hvor hurtigt en tung rapport bliver færdig.

For en applikation med både daglig ordrebehandling og tidskrævende rapporter kan de to mål trække i hver sin retning. Betydningen afhænger af, om rapporten kører sjældent i baggrunden eller har en svartidsgrænse, som brugerne mærker. Det er den konkrete konsekvens af en langsom forespørgsel, ikke antallet af benchmarksejre, der bør afgøre dens vægt.

JSON kræver en sammenligning af forespørgsler og indeks

PostgreSQLs beskrivelse af jsonb forklarer, at typen lagrer dokumenter i et behandlet binært format. Det kræver mere arbejde ved indlæsning end PostgreSQLs tekstbaserede json-type, men undgår gentagen fortolkning ved behandling. jsonb kan også indekseres med GIN til blandt andet søgning efter nøgler og bestemte nøgle-værdi-par. Den fordel afhænger af, om forespørgslen bruger en operator, som det valgte indeks understøtter.

MySQLs beskrivelse af JSON-typen angiver, at dokumenter valideres ved lagring og omdannes til et internt format med hurtig adgang til elementer. En JSON-kolonne indekseres ikke direkte som en jsonb-kolonne med GIN. MySQL kan i stedet indeksere en genereret kolonne, som udtrækker en værdi fra dokumentet; dokumentationen beskriver også indeks til flere værdier i JSON-arrays.

Hvis produktdata ofte filtreres efter den samme egenskab, er søgning på den egenskab med relevante indeks i begge databaser en meningsfuld prøve. Hvis dokumenterne hovedsageligt gemmes og hentes i deres helhed, fortæller en test af avanceret søgning mindre om den daglige belastning. Indeksernes fleksibilitet og vedligeholdelse skal vurderes sammen med svartiden: et indeks, der hjælper læsninger, er også en del af arbejdet ved ændringer af data.

Beslutningsmatrix for den konkrete belastning

• Simple opslag: Begge databaser er relevante. PostgreSQL førte snævert i den citerede prøve, så mål især svartid og gennemløb ved applikationens egen samtidighed.
• Indsættelser og opdateringer: MySQL førte ved de målte ordreindsættelser, PostgreSQL ved de målte brugeropdateringer. Vægt den operation, de nødvendige indeks og transaktionsstørrelsen, som faktisk dominerer.
• Blandet OLTP: MySQL førte i den offentliggjorte blanding. Brug resultatet som pejlemærke, hvis både fordelingen mellem læsning og skrivning og arbejdet pr. transaktion ligner.
• Analytiske forespørgsler: PostgreSQL afsluttede den målte join hurtigere. Giv den type resultater større vægt, når rapporter og aggregeringer har stramme svartidskrav.
• Dokumentdata: Sammenlign de JSON-felter, der faktisk søges i, med de indeks hver database kan bruge. Lagringsformatet alene udpeger ingen vinder.

Når valget skal træffes i egen drift

Et brugbart beslutningsgrundlag består af de forespørgsler, der bestemmer kapacitet eller mærkbar ventetid i det påtænkte system. Samme logiske data, relevante indeks og sammenlignelige krav til holdbarhed gør resultaterne lettere at tolke. Gennemløb og svartid bør ses sammen, fordi flere afsluttede operationer ikke nødvendigvis hjælper, hvis de langsomste brugerhenvendelser bliver for langsomme.

Hvis den vigtigste belastning er korte transaktioner, bør de vægte mere end en rapport, som sjældent køres. Hvis rapporten derimod blokerer en central arbejdsgang, kan dens svartid være afgørende, selv om databasen klarer færre transaktioner i en anden prøve. PostgreSQL og MySQL skal vælges ud fra den forskel, der faktisk har en konsekvens for applikationen.

Læs også:

• n8n, Make eller Zapier: 10 trin kan ændre hele AI-regningen
• ChatGPT, Claude eller Gemini til 20 dollar? Pakken afgør valget
• RAG eller finjustering? Fejlvalget gør virksomhedens viden forældet