Jämförelse av MySQL och PostgreSQL. Välj subd mellan mysql, postgresql, mariadb och mssql? Prestandajämförelse av ms sql-server och postgresql

Låt oss vara ärliga, även om 1C Enterprise är kompatibelt med många DBMS, fungerar faktiskt 99 procent antingen i MS SQL eller i gratis PostgreSQL.

Med andra ord, dessa två "subs" har erövrat klient-server 1C-marknaden.

Och vi kan lugnt anta att om företaget inte arbetar i MS SQL, så använder de troligen bara PostgreSQL.

Följaktligen är det vettigt att endast jämföra Postgres med MS SQL.

Idag skrivs det mycket om både MS SQL och PostgreSQL, men oftast jämför de dem inte objektivt.

I den här artikeln kommer vi att analysera de viktigaste tekniska punkterna i gratis PostgreSQL och jämföra det med MS SQL.

Det gör att du kan göra det bästa valet i framtiden och vara beredd på olika "överraskningar" eller, vad som skulle vara mer korrekt, "funktionerna" för att arbeta i detta gratis DBMS.

Vi kommer att utvärdera allt som det är, utan att lägga till de förtjänster som Postgres inte har och utan att försköna betald MS.

Jag kommer genast att svara på frågan som oroar många nybörjare!

JA! MS SQL är snabbare än PostgreSQL, det är ett faktum! Och det finns flera anledningar till detta!

Jag kanske omedelbart gjorde någon besviken, och du kanske inte håller med om det här påståendet, jag är ledsen, men själva fysiken i denna gratis DBMS tillåter inte att den går före MS SQL, särskilt om vi pratar om ett sådant gäng som "Monster 1C" och PostgreSQL.

Du kommer att stöta på liknande argument mer än en gång vid olika konferenser och seminarier tillägnade detta DBMS. Ingen döljer eller förnekar någonting, ett faktum är ett faktum.

Trots det är prestandan för PostgreSQL tillräckligt för användarna kunde fungera bekvämt i 1C.

Oavsett om det är ett dussin användare eller till och med flera hundra, som samtidigt arbetar i 1C Enterprise.

Varför "Monster 1C"?

Det är faktiskt så här 1C ser PostgreSQL utan speciella "patchar" och tillägg installerade.

Ja, vad som kallas out of the box, genom att ladda ner PostgreSQL distributionspaketet på kontoret. webbplats kommer du inte att kunna använda den för att fungera tillsammans med 1C. 1C-ka kommer fruktansvärt sakta ner och bara stanna, vägra arbeta.

Varför händer detta, och varför "lappar"?

Faktum är att 1C Enterprise skapar ett stort antal tillfälliga tabeller under sitt arbete, vi kan prata ungefär tusentals bord per sekund, och om vi till exempel tar registret "Slice of the last" - "Remainders and Omsättningar", där kan de mycket väl och en miljon rader att vara.

Faktum är att PostgreSQL som standard (utan "patchar") inte räknar statistik på dessa stora temporära tabeller, med andra ord, frågeoptimeraren som styrs av data från statistiken (och som vi minns är den tom, det finns inget att räkna) grovt sett gör ett urval med hjälp av VÄLJ* vilket såklart kommer att fungera väldigt, väldigt långsamt!

Därav de storslagna bromsarna i 1C!

Naturligtvis är detta inte alla problem som behöver lösas så att PostgreSQL fungerar tillsammans med 1C normalt. Andra "lappar" kommer att behövas och speciella tillägg och efter 15-20 användare, även ytterligare. inställningar i config

Ja, i verkligheten ser allt mycket mer komplicerat ut än vad jag beskrev ovan, men om du förenklar det mycket kommer huvudproblemet med långsamt 1C-arbete med PostgreSQL att se ut så här.

Det andra jag verkligen ogillar med PostgreSQL är ingen multithreading inom en enda begäran jämfört med MS SQL.

(Från och med version 9.6 gjorde vi det första försöket att parallellisera frågor, men än så länge fungerar det dåligt, ibland är effekten den motsatta). men för att prova 5!)

Vilket naturligtvis påverkar prestandan, så att du enkelt förstår -

PostgreSQL kan ta ner din 48-kärniga server med en enda stor fråga!

Det är enkelt, det finns ingen parallellisering av trådar inom en enda begäran, och en stor begäran "lastar" bara en kärna.

Ja, om det finns många förfrågningar, kommer alla kärnor att laddas, och allt kommer att fungera bra.

Och jag glömde nästan vi jämför PostgreSQL med MS SQL Standard inte Express!

Express, även om det kan användas för kommersiella ändamål, har ett antal begränsningar

till exempel 10 GB per bas, enkel CPU-användning, 1 GB random access minne,

gör användningen av en sådan produkt nästan orealistisk för att arbeta i 1C Enterprise.

Om du inte har en väldigt liten databas och bara ett par användare (och även då finns det väldigt få 1 GB bromsar för en DBMS).

Så låt oss jämföra PostgreSQL med den populära standardversionen.

SKRIP!!!

PostgreSQL är i första hand skript i jämförelse med MS SQL, de flesta operationer måste göras för hand, ja, visst kan du installera en del grundläggande saker genom gränssnittet, men jag betonar att de grundläggande, och ett steg till vänster, en steg till höger, och du måste skriva ett skript, eller BASH på Linux eller cmd, powershell på Windows.

Visa och analysera spår med SQL Server Profiler.

Den välkända SQL Server Profiler saknas i PostgreSQL, och med ordet "saknad" menar jag, jag kommer att gå in helt, tyvärr, det finns inget liknande i PostgreSQL.

Det finns naturligtvis verktyg som tillåter, om du har tid att avlyssna begäran eller ställa in en 1C-brytpunkt i debuggern och få något och se, men i jämförelse med Profiler, som de säger, var det inte ens i närheten.

Du kan sätta upp en logg och sedan gå igenom allt - men under lång tid!

Här är ett exempel:

En 1C-programmerare försöker felsöka någon stor fråga, det tar lång tid, till exempel 30 minuter, och så i PostgreSQL, för att data ska komma in i loggen, måste denna fråga exekveras! Kan du föreställa dig hur lång tid det tar att felsöka en sådan begäran?

I MS SQL kan du avbryta exekveringen av frågan och analysera den i Profiler, eftersom den redan kommer att finnas där, men med statusen "misslyckad".

Postgres har ingen motsvarighet när det gäller att skapa "säkerhetskopior"!

Här har du både en inkrementell "backup" och en komplett säkerhetskopiering och kontinuerlig WAL-arkivering.

Som faktiskt finns det en partiell säkerhetskopiering och partiell dataåterställning.

Du kan konfigurera kontinuerlig arkivering och punkt-i-tid återställning (Point-in-Time Recovery (PITR)).

Också replikering, finns tillgängligt i PostgreSQl utan några "patchar" av verktyg och tillägg!

• Kaskadreplikering
• Strömmande replikering
• Synkron replikering
• Kontinuerlig arkivering på en standby-server

Allt detta finns redan initialt i PostgreSQl och naturligtvis inte i "expressen" och är inte tillgängligt på MS SQL Standard-versionen.

För att få allt som listas ovan i MS SQL måste du köpa en mycket dyr MS SQL Enterprise, nu runt 15 000 $.

Vad är inte i jämförelse med MS SQL?

INGEN differentiell "backup"

Ja, det finns ingen differentiell "säkerhetskopiering" i PostgreSQl, men det finns olika analoger av inkrementella "säkerhetskopieringar".

Till exempel inkrementell "säkerhetskopiering" på blocknivå.

DET FINNS en uppdelning av TABLESPACEs, som redan stöder 1C som standard!

Vilket för övrigt inte finns i MS SQL!

Du kan till exempel konfigurera på vilken disk du ska ha "index" och på vilken disk "tabellen" ska ligga, det är väldigt praktiskt när du planerar en IT-infrastruktur när det kommer till stora 1C-databaser. ONLINE_ANALYZE för att räkna om statistik. Detsamma gäller för *dt-filen.

Med PostgreSQL behöver du sällan REINDEX!

I själva verket bör den endast användas när det finns en misstanke om att databasens integritet har skadats.

Du kan göra "säkerhetskopieringar" med undantag för tabeller!

Till exempel har du flera 1C-programmerare som jobbar i ditt företag, det kommer de garanterat att göra säkerhetskopior skapa "backuper" för vidareutveckling.

Som ett resultat lider användarna, databasen saktar ner under skapandet av en stor "säkerhetskopia", särskilt om denna databas innehåller sådana saker som olika bifogade filer, arkiv, dokument från brev. Sådana filtabeller kan lätt innehålla hundratals gigabyte. Och de kan också uteslutas i PostgreSQl genom att skapa en "säkerhetskopia", därigenom av liten storlek, och med all funktionalitet på samma gång.

Så vi laddar återigen inte nätverksenheter, täpper inte till kanalen, spenderar mycket mindre tid på att skapa en sådan "säkerhetskopiering"

I slutändan vinner alla! Och användare, och programmerare och administratörer sover lugnt.

I den här artikeln har vi bara analyserat de grundläggande skillnaderna mellan PostgreSQl och MS SQL (det finns andra), men om du bestämmer dig för valet till förmån för ett eller annat DBMS borde artikeln hjälpa!

Lycka till kollega!

P.S. Nu jobbar jag på en ny kurs "1C och PostgreSQL" (Redan på inspelningsstadiet, vänta, snart!)

Med vänlig hälsning, Bogdan.

I väntan på min presentation vid konferensen PGCONF.RUSSIA 2015 kommer jag att dela med mig av några observationer om viktiga skillnader mellan DBMS MySQL och PostgreSQL. Detta material kommer att vara användbart för alla som inte längre är nöjda med möjligheterna och MySQL-funktioner, samt de som tar sina första steg i Postgres. Naturligtvis bör detta inlägg inte betraktas som en uttömmande lista över skillnader, men det kommer att räcka för att fatta ett beslut till förmån för ett eller annat DBMS.

replikering

Problemet är att många lagringshanteringssystem... ofta gör sina egna WAL och PITR. Vissa gör också sin egen bufferthantering, låsning och replikering/belastningshantering. Så, som du säger, det är svårt att säga var ett gränssnitt ska vara
abstraherat.

Mer än 10 år har gått, och vad ser vi? MySQL har irriterande problem med transaktioner mellan tabeller för olika lagringsmotorer och MySQL har problem med replikering. Under dessa tio år har PostgreSQL lagt till pluggbara datatyper och index, och har även replikering - det vill säga att fördelen med MySQL har utjämnats, medan de arkitektoniska problemen med MySQL har kvarstått och stör livet. MySQL 5.7 försökte lösa replikeringsprestandaproblemet genom att parallellisera det. Eftersom projektet på jobbet är mycket känsligt för replikeringsprestanda på grund av dess skala, försökte jag testa om det blev bättre. Jag fann att parallell replikering i 5.7 är långsammare än entrådig replikering i 5.5, och endast i vissa fall - ungefär likadant. Om du för närvarande använder MySQL 5.5 och vill uppgradera till en nyare version, observera att migrering inte är möjlig för högbelastningsprojekt, eftersom replikeringen helt enkelt slutar köras.

Efter högbelastningsrapporten noterade Oracle testet jag utvecklade och sa att de skulle försöka åtgärda problemet; Nyligen skrev de till och med till mig att de kunde se parallelliteten i sina tester och skickade inställningarna. Om jag inte misstar mig så blev det med 16 trådar en liten speedup jämfört med den entrådiga versionen. Tyvärr har jag ännu inte upprepat mina tester på de angivna inställningarna - i synnerhet eftersom våra problem fortfarande är relevanta med sådana resultat.

De exakta orsakerna till denna prestandaregression är okända. Det fanns flera förslag – till exempel skrev Christian Nelsen, en av utvecklarna av MariaDB, i sin blogg att det kan finnas problem med prestandaschemat, med trådsynkronisering. På grund av detta finns en regression på 40 %, vilket är synligt på konventionella tester. Oracle-utvecklare förnekar detta, och de övertygade mig till och med att det inte existerar, tydligen ser jag något annat problem (och hur många av dem finns det?).

I MySQL-replikering förvärras problem med lagringsmotorn av den valda replikeringsnivån - de är logiska, medan de i PostgreSQL är fysiska. I princip har logisk replikering sina fördelar, det låter dig göra mer intressanta saker, jag kommer också att nämna detta i rapporten. Men PostgreSQL, även som en del av sin fysiska replikering, förnekar redan alla dessa fördelar. Med andra ord kan nästan allt som finns i MySQL redan göras i PostgreSQL (eller kommer att vara möjligt inom en snar framtid).

Du kan inte hoppas på att implementera fysisk replikering på låg nivå i MySQL. Problemet är att istället för en logg (som i PostgreSQL) finns det två eller fyra av dem – beroende på hur du räknar. PostgreSQL begår helt enkelt frågor, de kommer in i loggen och den här loggen används i replikering. PostgreSQL-replikering är superstabil eftersom den använder samma logg som failover-operationer. Denna mekanism har länge varit skriven, väl testad och optimerad.

I MySQL är situationen annorlunda. Vi har en separat InnoDB-logg och en replikeringslogg, och vi måste commitera både där och där. Och detta är en tvåfasig commit mellan loggar, som per definition är långsam. Det vill säga, vi kan inte bara ta och säga att vi upprepar transaktionen från InnoDB-loggen - vi måste ta reda på vad begäran är och starta om den. Även om detta är en logisk replikering, på radnivå, måste dessa rader sökas i indexet. Och du måste inte bara göra mycket arbete för att köra frågan – samtidigt kommer den återigen att skrivas till sin InnoDB-logg redan på repliken, vilket uppenbarligen inte är bra för prestanda.

I PostgreSQL, i denna mening, är arkitekturen en storleksordning mer genomtänkt och bättre implementerad. Nyligen tillkännagav den en funktion som heter Logical Decoding – som låter dig göra alla möjliga intressanta saker som är väldigt svåra att göra inom ramen för en fysisk journal. I PostgreSQL är detta ett tillägg från ovan, logisk avkodning låter dig arbeta med en fysisk logg som om den vore en logisk. Det är denna funktionalitet som snart kommer att ta bort alla fördelar med MySQL-replikering, förutom kanske storleken på loggen - statement-baserad MySQL-replikering kommer att vinna - men statement-baserad MySQL-replikering har helt vilda problem på de mest oväntade ställen, och du ska inte räkna det bra beslut(Jag kommer också att prata om allt detta i rapporten).

Dessutom finns det en utlöst replikering för PostgreSQL - det här är Tungsten, som låter dig göra detsamma. Utlöst replikering fungerar enligt följande: utlösare sätts, de fyller tabeller eller skriver filer, resultatet skickas till repliken och appliceras där. Det är genom Tungsten, så vitt jag vet, som de migrerar från MySQL till PostgreSQL och vice versa. I MySQL fungerar logisk replikering direkt på motornivå, och det går inte längre att göra det annorlunda nu.

Dokumentation

Till exempel är det så här Percona sköt: de körde MySQL Performance Blog, och det fanns många artiklar på den här bloggen som handlade om vissa aspekter av MySQL-drift. Detta väckte vild popularitet, ledde kunder till konsulttjänster, tillät att locka resurser för att lansera utvecklingen av sin egen gaffel av Percona-Server. Existensen och relevansen av MySQL Performance Blog bevisar att officiell dokumentation helt enkelt inte räcker.

PostgreSQL har praktiskt taget alla svar i dokumentationen. Å andra sidan har jag hört mycket kritik när jag jämför PostgreSQL-dokumentation med "vuxen" Oracle. Men det är faktiskt en mycket viktig indikator. Ingen försöker överhuvudtaget jämföra MySQL med ett äldre Oracle – det skulle vara löjligt och löjligt – men PostgreSQL börjar redan jämföras ganska seriöst, PostgreSQL-communityt hör denna kritik och jobbar på att förbättra produkten. Detta tyder på att den, när det gäller dess kapacitet och prestanda, börjar konkurrera med sådana kraftfullt system som Oracle som de jobbar på mobiloperatörer och banker, medan MySQL förblir i nischen av webbplatser. Och jätteprojekt som har vuxit till en stor mängd data och användare slurpar sorg med MySQL med en stor sked, ständigt vilande på dess begränsningar och arkitektoniska problem som inte kan fixas genom att lägga en rimlig tid och ansträngning.

Ett exempel på så stora projekt på PostgreSQL är 1C: PostgreSQL kommer som ett alternativ istället för Microsoft SQL, och Microsoft SQL är verkligen ett fantastiskt DBMS, ett av de mest kraftfulla. PostgreSQL kan ersätta MS SQL, och försöker ersätta MySQL... låt oss tycka synd om den här scenen, som Mark Twain skrev.

Standarder

Prestanda och administrationskomplexitet

MySQL har problem med komplexa frågor. Till exempel, MySQL vet inte hur man sänker grupperingen i separata delar av fackföreningen alla. Skillnaden mellan de två frågorna är att i vårt exempel fungerade gruppering efter separata tabeller och union allt ovanifrån 15 gånger snabbare än union all och sedan gruppering, även om optimeraren bör föra in båda frågorna i samma, effektiva frågekörningsplan. Vi kommer att behöva göra genereringen av sådana förfrågningar för hand - det vill säga lägga utvecklarnas tid på vad databasen ska göra.

"Enkelheten" i MySQL härrör, som kan ses ovan, från extremt dåliga funktioner - MySQL presterar helt enkelt sämre och kräver mer tid och ansträngning under utveckling. Däremot har PostrgreSQL histogram och en normal optimerare och kommer att utföra sådana frågor effektivt. Men om det finns histogram, så finns det deras inställningar - åtminstone hinkstorleken. Du måste känna till inställningarna och ändra dem i vissa fall - därför måste du förstå vilken typ av inställning det är, vad det är ansvarigt för, kunna känna igen sådana situationer, se och välja de optimala parametrarna.

Det händer ibland att skickligheten i PostrgreSQL kan hindra snarare än hjälpa. 95% av tiden fungerar allt bra - bättre än MySQL - och en dum fråga är mycket långsammare. Eller allt fungerar bra, och sedan plötsligt (från användarens synvinkel) när projektet växte, började vissa frågor att fungera dåligt (det fanns mer data, en annan exekveringsplan började väljas). Troligtvis, för att fixa det, räcker det att köra analysera eller justera inställningarna lite. Men du måste veta vad du ska göra och hur du gör det. Som ett minimum måste du läsa PostgreSQL-dokumentationen om detta ämne, men av någon anledning gillar de inte att läsa dokumentationen. Kanske för att det finns lite hjälp av det i MySQL? :)

Jag betonar att PostgreSQL inte är sämre i den här meningen, det låter dig bara skjuta upp problem, och MySQL kastar omedelbart ut dem och du måste lägga tid och pengar på att lösa dem. I denna mening fungerar MySQL alltid konsekvent dåligt, och även i utvecklingsstadiet tar människor hänsyn till dessa funktioner: de gör allt till det maximala på ett enkelt sätt. Detta gäller endast prestanda, närmare bestämt sätten att uppnå det och dess förutsägbarhet. När det gäller korrekthet och bekvämlighet ligger PostgreSQL med huvud och axlar över MySQL.

Så vad ska man välja?

För det första, vilken erfarenhet har laget? Om hela teamet har 10 års erfarenhet av MySQL och behöver starta upp så snabbt som möjligt, så är det inte ett faktum att det är värt att byta ut ett bekant verktyg mot ett obekant. Men om timingen inte är kritisk bör du prova PostgreSQL.

För det andra får vi inte glömma driftsproblemen. Om du inte har ett högt belastat projekt, då när det gäller prestanda är det ingen skillnad mellan dessa två DBMS. Men PostgreSQL har en annan viktig fördel: den är mer strikt, den gör fler kontroller åt dig, den ger dig mindre utrymme för fel, och detta är en stor fördel i det långa loppet. Till exempel måste MySQL skriva sina egna verktyg för att verifiera databasens normala referensintegritet. Och även det kan vara ett problem. I denna mening är PostgreSQL-verktyget kraftfullare, mer flexibelt och trevligare att utveckla på. Men detta beror till stor del på utvecklarens erfarenhet.

Sammanfattningsvis: om du har en enkel webbutik, inga pengar till en admin, inga seriösa ambitioner att växa till ett stort projekt och har erfarenhet av MySQL, ta då MySQL. Om du förväntar dig att projektet ska bli populärt, om det är stort, blir det svårt att skriva om det, om det har komplex logik och relationer mellan tabeller – ta PostgreSQL. Även utanför lådan kommer det att fungera för dig, hjälpa till i utvecklingen, spara tid och det blir lättare för dig att växa.

Det är svårt att hitta en organisation som inte använder redovisningssystem från 1C – även i megainnehav där SAP eller OEBS sedan länge har implementerats används de nästan alltid inom ett eller annat område. Det är glädjande att rysk applikationsprogramvara har blivit de facto-standarden för våra företag, men det finns en subtilitet: samma de facto-standard för 1C: Enterprise självt har blivit Microsoft använder SQL Server som ett DBMS.

Bland praktiserande 1C-smeknamn är den vanligaste åsikten att utan kommersiellt DBMS kommer inget bra från amerikanska tillverkare, säger de, flera hundra användare kräver oundvikligen installation av en databas på MS SQL, Oracle Database eller IBM DB2 i detta fall. Om arbete under kontroll av friheten för PostgreSQL DBMS skilde sig åsikterna från utövare kända för oss, men i intervallet från "fungerar inte alls" till "lämplig för flera dussin användare, inte mer".

Det fanns ett antal rimliga förklaringar till sådana blygsamma uppskattningar: både den aktiva användningen av temporära tabellmekanismer av 1C-plattformar (som implementeras alltför "ärligt" i Postgres - med transaktions-DDL, alla återställningsmöjligheter), och särdragen med att arbeta med text data (medan vanilla Postgres, återigen inom flerspråkiga texter, är för konservativt, och använder inte de mest högpresterande systembiblioteken), och ett antal andra mindre betydelsefulla aspekter.

Men vi trodde i hemlighet på Postgres, särskilt eftersom församlingen påstod sig lösa alla de problem som skeptiker använde för att motivera valet av kommersiellt DBMS. Dessutom var det viktigt för oss att få fram målindikatorer för hård- och mjukvarukomplexet - en databasmaskin för DBMS byggd på sanktionssäker hård- och mjukvara, utvecklad av IBS tillsammans med Postgres Professional.

Av de replikerade applikationerna skulle den mest uppenbara applikationen för en sådan maskin naturligtvis vara 1C-system. Och resultaten av de utförda riktmärkena överförde oss helt från kategorin "hemliga troende" (och till och med tvivlare) till kategorin "övertygade": nu kan vi säkert säga att 1C:Enterprise version 8.3 på Postgres Pro EE 1.5-bygget för Skala-SR / Postgres Pro fungerar bättre än på MS SQL 2012 på samma hårdvara med alla möjliga optimeringar.

Så, några detaljer om experimenten. När det gäller prestandatester har 1C allt systematiskt och vetenskapligt – det finns typisk konfiguration"Standard belastningstest", där riktmärket lanseras, vilket gradvis lägger till nya användare till belastningen tills applikationen är tillräckligt responsiv för bekvämt arbete. (Närmare bestämt läggs användare till tills standardapdex-applikationens prestandapoäng faller under tröskeln på 0,85, och det maximala antalet sådana effektiva användare anses vara resultatet av riktmärket.)

Vi använde version 8.3.9.1850 av 1C:Enterprise, standardbelastningstest i version 2.0.17.36. Inledningsvis beslutades det att inte ge några rabatter till Postgres: vi gör maximala optimeringar på MS SQL på noden från Skala-SR / Postgres Pro-komplexet (vi satte Windows på bar metall, vi ställer in det enligt alla kanoner, för hastighet gör vi en ramdisk för temporära tabeller), och sedan - vi returnerar samma nod till Skala-SR-komplexet, vi rullar Linux och Postgres Pro EE, och bara på den (utan klusterchips tillgängliga i komplexet) - kör vi samma test.

Test ett: vi börjar med 100 jobb, belastningen är 50/50 - hälften genererar dokument, hälften genererar rapporter. Test två: börja med 400, belastning 70/30. MS SQL "slutade" i det första testet på 360 användare, på det andra - på 540, dessutom var limitern i båda lanseringarna arbetet med lokal I/O, trots att processorn bara var 30% laddad i genomsnitt. Postgres Pro i det första testet nådde 440 jobb, och i det andra - upp till 660, och allt på databasservern vilade på processorn, som går till att ladda mer än 90% på "maximala användare".

För 1C, där antalet samtidiga användare är den mest problematiska begränsande faktorn, är detta ett anmärkningsvärt resultat, och viktigast av allt, det visar att dessa viktigaste ryska applikationssystem inte bara kan fungera utan västerländsk kommersiell DBMS, utan till och med göra det märkbart bättre .

Innehållsserie:

1. Utvecklingshistorik för MySQL och PostgreSQL

MySQL:s historia börjar 1979 med ett litet företag som leds av Monty Widenius. 1996 dök den första utgåvan av 3.11 upp under Solaris med en offentlig licens. Sedan portades MySQL till andra Operativsystem, en speciell kommersiell licens dök upp. År 2000, efter att ha lagt till ett gränssnitt som liknar Berkeley DB, blev databasen transaktionsbaserad. Ungefär samtidigt lades replikering till. År 2001 lade version 4.0 till InnoDB-motorn till den redan befintliga MyISAM, vilket resulterade i cachning och ökad prestanda. 2004 släpptes version 4.1, som introducerade delfrågor, partiell indexering för MyISAM, Unicode. Version 5.0 2005 introducerade lagrade procedurer, markörer, utlösare och vyer. MySQL utvecklar kommersiella trender: 2009 blev MySQL ett varumärke för Oracle.

Postgres historia började 1977 med Ingress-databasen.

1986 vid University of Berkeley, Kalifornien, döptes det om till PostgreSQL.

1995 blev postgres en databas med öppen källkod. Interaktiv psql dök upp.

1996 döptes Postgres95 om till PostgreSQL version 6.0.

Postgres har flera hundra utvecklare runt om i världen.

2. MySQL- och PostgreSQL-arkitektur

PostgreSQL- en enhetlig databasserver med en enda motor - lagringsmotor. Postgres använder en klient-server-modell.

För varje klient skapar servern ny process(inte en ström!). För att arbeta med sådana klientprocesser använder servern semaforer.

Kundförfrågan går igenom följande steg.

1. Ansluta.
2. Parsning: korrektheten av begäran kontrolleras och ett frågeträd skapas. Parsern är baserad på de grundläggande Unix-verktygen yacc och lex.
3. Skriv om: frågeträdet tas och förekomsten av regler (regler) i det, som ligger i systemkatalogerna, kontrolleras. Varje gång en användarfråga skrivs om till en fråga som kommer åt databastabeller.
4. Optimerare: för varje fråga skapas en frågeplan - frågeplan, som skickas till utföraren - utföraren. Meningen med planen är att alla går igenom den möjliga alternativ få resultatet (om man ska använda index, sammanfogningar, etc.), och det snabbaste alternativet väljs.
5. Frågeexekvering: Exekutorn korsar trädet rekursivt och får resultatet med hjälp av sortering, joins etc. och returnerar rader. Postgres är en objektrelationell databas, varje tabell i den representerar en klass, arv implementeras mellan tabellerna. SQL92 och SQL99 standarder implementerade.

Transaktionsmodellen bygger på den så kallade multi-version concurrency control (MVCC), som ger maximal prestanda. Referensintegritet säkerställs genom närvaron av primära och sekundära nycklar.

MySQL har två lager - ett externt sql-lager och en intern uppsättning motorer, varav InnoDb-motorn används oftast, eftersom den har mest stöd för ACID.

SQL92-standard implementerad.

Ur en modulär synvinkel kan MySQL-kod delas upp i följande moduler.

1. Serverinitiering.
2. Anslutningshanterare.
3. Stream manager.
4. Kommandohanterare.
5. Autentisering.
6. Parser.
7. Optimizer.
8. Bordschef.
9. Motorer (MyISAM, InnoDB, MEMORY, Berkeley DB).
10. Skogsavverkning.
11. Replikering.
12. nätverks-API.
13. kärn-API.

Ordningen på modulerna är som följer: först laddas den första modulen, som läser alternativen kommandorad, konfigurationsfiler, allokerar minne, initierar globala strukturer, laddar systemtabeller och överför kontrollen till anslutningshanteraren.

När en klient ansluter till databasen skickas kontrollen till trådhanteraren, som skapar en tråd (inte en process!) för klienten och kontrollerar dess autentisering.

Kundförfrågningar beroende på deras typ på högsta nivån behandlas av den fjärde modulen (dispatcher). Förfrågningar kommer att loggas av den 11:e modulen. Kommandot skickas till parsern, cachen kontrolleras. Vidare kan frågan komma in i optimeraren, tabellmodulen, replikeringsmodulen, etc. Som ett resultat returneras data till klienten via strömhanteraren.

Den viktigaste koden finns i filen sql/mysqld.cc. Den innehåller grundläggande funktioner som inte har ändrats sedan version 3.22: init_common_variables() init_thread_environment() init_server_components() grant_init() // sql/sql_acl.cc init_slave() // sql/slave.cc get_connections_read_connections_) handle_one_connection() check_connection() acl_check_host() // sql/sql_acl.cc create_random_string() // sql/password.cc check_user() // sql/sql_parse.cc mysql_parse() // sql_com.cc_mand query_com.(sql_) ::store_query() // sql/sql_cache.cc JOIN::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update.cc mytsql_check /_ sql/sql_table.cc

sql/sql_class.h-huvudet definierar basklasserna: Query_arena, Statement, Security_context, Open_tables_state classes, THD. Ett objekt i klassen THD är en tråddeskriptor och är ett argument för ett stort antal funktioner.

3. Jämförelse av MySQL och PostgreSQL: likheter och skillnader

SYRA standard

ACID-standarden är baserad på atomicitet, integritet, isolering och tillförlitlighet. Denna modell används för att garantera dataintegritet. Det implementeras på basis av transaktioner. PostgreSQL är helt kompatibel med ACID-standarden. För fullt stöd ACID i MySQL i konfigurationen du behöver ställa in default-storage-engine=innodb.

Prestanda

Databaser är ofta optimerade för miljön där de verkar. Båda baserna har olika teknologier för att förbättra prestandan. Historiskt sett har MySQL utvecklats med snabbhet i åtanke, medan PostgreSQL utvecklades från första början som en mycket anpassningsbar och standardkompatibel databas. PostgreSQL har ett antal inställningar som förbättrar åtkomsthastigheten:

• partiella index;
• Datakomprimering;
• minnesallokering;
• förbättrad cache.

MySQL har partiellt stöd för partiella index i InnoDB. Om vi ​​tar MySQL ISAM-motorn visar det sig vara snabbare på platta frågor, medan det inte finns några lås på insatser, det finns inget stöd för transaktioner, främmande nyckel.

Kompression

PostgreSQL är bättre på att komprimera och dekomprimera data, vilket gör att mer data kan lagras på diskutrymme. I det här fallet läses komprimeringsdata snabbare från disken.

MySQL-komprimering för olika motorer stöds delvis, delvis inte, och det beror på den specifika versionen av en viss motor.

På multiprocessor har PostgreSQL en fördel jämfört med MySQL. Till och med MySQL-utvecklarna själva medger att deras motor inte är så bra i detta avseende.

Datatyper

MySQL: använder typerna TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB för att lagra binära data, som skiljer sig i storlek (upp till 4 GB).

Karaktär: fyra typer - TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

PostgreSQL: stöder användardatamotor med CREATE TYPE-kommando, BOOLEAN-typ, geometrityper.

Karaktär: TEXT (gräns - max radstorlek).

För att lagra binär data finns det en BLOB-typ, som lagras i filsystem. Tabellkolumner kan definieras som en flerdimensionell matris med variabel längd. Objektrelationsförlängning: Strukturen i en tabell kan ärvas från en annan tabell.

Lagrade procedurer

Både PostgreSQL och MySQL stöder lagrade procedurer. PostgreSQL följer Oracle PL/SQL-standarden, MySQL följer IBM DB2-standarden. MySQL stöder utöka SQL för att skriva C/C++ funktioner sedan version 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C för att skriva lagrade procedurer.

Nycklar

Både PostgreSQL och MySQL stöder det unika med primärnyckel och främmande nyckel. MySQL stöder inte kontrollbegränsning plus sekundära nycklar är delvis implementerade. PostgreSQL: fullständig implementering plus stöd för ON DELETE CASCADE och ON UPDATE CASCADE.

triggers

MySQL: rudimentärt stöd. PostgreSQL: deklarativa utlösare: SELECT, INSERT, DELETE, UPDATE, ISTEAD OF; procedurutlösare: CONSTRAINT TRIGGER. Händelser: FÖRE eller EFTER på INSERT, DELETE, UPDATE.

automatisk ökning

MySQL: Det kan bara finnas en sådan kolumn i en tabell som behöver indexeras. PostgreSQL: SERIAL datatyp.

Replikationer

Stöds av både MySQL och PostgreSQL. PostgreSQL har en modulär arkitektur och replikering kommer i separata moduler:

• Slony-I är den huvudsakliga replikeringsmekanismen i postgres, prestanda sjunker i ett kvadratiskt beroende av antalet servrar;

Replikering i PostgreSQL är baserad på triggers och är långsammare än i MySQL. Replikering är planerad att läggas till kärnan från och med version 8.4.

I MySQL är replikering en del av kärnan och har två smaker sedan version 5.1:

• SBR - satsbaserad replikering;
• RBR - radbaserad replikering.

Den första typen är baserad på att logga poster till en binär logg, den andra typen är baserad på loggningsändringar. Från och med version 5.5 stöder MySQL den så kallade semi-synkrona replikeringen, där huvudservern (master) spolar data till en annan server (slav) vid varje commit. NDB-motorn utför helsynkron tvåfasreplikering.

Transaktioner

MySQL: Endast för InnoDB. SAVEPOINT, ROLLBACK TILL SAVEPOINT-stöd. Låsnivåer: tabellnivå (MyISAM). PostgreSQL: stöds plus läs engagerade och isoleringsnivåer. ROLLBACK, ROLLBACK TILL SAVEPOINT-stöd. Låsnivåer: radnivå, tabellnivå.

Privilegenivåer

PostgreSQL: Behörigheter kan tilldelas en användare eller grupp av användare.

Exportera-importera data

MySQL: uppsättning exportverktyg: mysqldump, mysqlhotcopy, mysqlsnapshot. Importera från textfiler, html, dbf. PostgreSQL: export - verktyget pg_dump. Importera mellan databaser och filsystem.

Underfrågor

Det finns både MySQL och PostgreSQL, men MySQL kan vara improduktivt.

Indexering

Indexhashning: partiell i MySQL, fullständig i PostgreSQL. Fulltextsökning: i MySQL - partiell, i PostgreSQL - full. Partiella index: stöds inte i MySQL, stöds i PostgreSQL. Flerkolumnsindex: i MySQL är gränsen 16 kolumner, i PostgreSQL - 32. Uttrycksindex: i MySQL - emulering, i PostgreSQL - fullt. Icke-blockerande skapa index: delvis i MySQL, fullt i PostgreSQL.

Partitionering

MySQL stöder horisontell partitionering: intervall, lista, hash, nyckel, sammansatt partitionering. PostgreSQL stöder RANGE och LIST. Automatisk partitionering för tabeller och index.

Automatisk failover

MySQL: partiell för InnoDB - du måste göra en säkerhetskopia manuellt. PostgreSQL: Write Ahead Logging (WAL).

Datalagringsmotorer

PostgreSQL stöder en motor - Postgres Storage System. Det finns flera i MySQL 5.1:

• MyISAM - används för att lagra systemtabeller;
• InnoDB – maximal ACID-kompatibilitet, lagrar data med primärnycklar, cachar inlägg, stöder komprimering sedan version 5.1 – se ROW_FORMAT=COMPRESSED-attribut;
• NDB Cluster är en minnesorienterad motor, klusterarkitektur som använder synkron replikering;
• ARKIV - stöder komprimering, använder inte index;
• och även: MERGE, MEMORY (HEAP), CSV.

InnoDB är utvecklat av InnoBase, ett dotterbolag till Oracle. I den 6:e versionen ska två motorer dyka upp - Maria och Falcon. Falcon är en motor baserad på ACID-transaktioner.

Licensiering

PostgreSQL: BSD (Berkeley Software Distribution) öppen källkod. MySQL: GPL (Gnu General Public License) eller kommersiell. MySQL är en produkt med öppen källkod. Postgres är ett projekt med öppen källkod.

Slutsats

Sammanfattningsvis kan vi säga följande: MySQL och PostgreSQL är de två mest populära databaserna med öppen källkod i världen. Varje bas har sina egna egenskaper och skillnader. Om du behöver snabb lagring för enkla frågor med minimal installation, skulle jag rekommendera MySQL. Om du behöver pålitlig lagring för en stor mängd data med möjligheten att expandera, replikera, helt överensstämma med moderna SQL-språkstandarder, skulle jag föreslå att du använder PostgreSQL.

Vi kommer att diskutera MySQL- och PostgreSQL-konfigurationsproblem.

Ladda ner resurser

static.content.url=http://www.website/developerworks/js/artrating/

Zone=Öppen källkod, Linux

Artikel-ID=779830

ArticleTitle=MySQL & PostgreSQL: Del 1 Benchmarking

Relationsdatabaser har funnits länge. De blev populära tack vare styrsystem som implementerar relationsmodellen så bra att den är det på bästa möjliga sätt arbeta med data, särskilt för kritiska applikationer och tjänster.

MySQL har funnits länge och har visat sig vara en bra lösning, Postgresql kom på marknaden ungefär samtidigt, men ger ganska mycket intressanta funktioner och möjligheter, tack vare vilka det snabbt vinner popularitet. I den här artikeln kommer vi att försöka jämföra MySQL vs Postgresql, jämföra de viktigaste skillnaderna mellan dessa system, ta reda på hur de fungerar och försöka förstå vilket system som passar bäst för ditt projekt.

Databaser är designade för strukturerad lagring och snabb åtkomst till olika data. Varje databas, förutom själva data, måste ha en viss arbetsmodell, enligt vilken databehandling kommer att utföras. För att hantera databaser används DBMS eller databashanteringssystem, sådana program inkluderar MySQL och Postgresql.

Relationella databashanteringssystem tillåter att data placeras i tabeller genom att länka rader från olika tabeller och därmed länka olika, logiskt kombinerade data. Innan du kan lagra data måste du skapa tabeller av en viss storlek och ange en datatyp för varje kolumn. Kolumnerna representerar datafält och själva data placeras i rader. Både databashanteringssystem och MySQL vs Postgresql är relationella. Därefter kommer vi att överväga mer i detalj hur de två programmen skiljer sig åt. Och låt oss nu gå vidare till en mer detaljerad övervägande.

Kort historia

MySQL

MySQL-utvecklingen började redan på 90-talet. Den första interna releasen av databasen ägde rum 1995. Under denna tid var flera företag involverade i utvecklingen av programmet. Utvecklingen startades av det svenska företaget MySQL AB, som förvärvades av Sun Microsystems, som i själva verket blev Oracles egendom. För tillfället, sedan 2010, har Oracle utvecklats.

postgresql

Utvecklingen av Postgresql började redan 1986 vid University of California, Berkeley. Utvecklingen varade i nästan åtta år, sedan delades projektet upp i två delar, den kommersiella databasen IIlustra och det helt kostnadsfria Postrgesql-projektet, som är utvecklat av entusiaster.

Datalagring

MySQL

MySQL är en relationsdatabas, olika motorer används för att lagra data i tabeller, men arbetet med motorer är dolt i själva systemet. Motorn påverkar inte syntaxen för frågor och deras exekvering. Huvudmotorerna som stöds är MyISAM, InnoDB, MEMORY, Berkeley DB. De skiljer sig från varandra i hur data skrivs till disken, såväl som i metoderna för läsning.

postgresql

Postgresql är en objektrelationsdatabas som körs på endast en motor - lagringsmotorn. Alla tabeller representeras som objekt, de kan ärvas och alla åtgärder med tabeller utförs med hjälp av objektivt orienterade funktioner. Liksom i MySQL lagras all data på disk i speciellt sorterade filer, men strukturen på dessa filer och posterna i dem är väldigt olika.

SQL standard

Oavsett vilket databashanteringssystem som används är SQL ett standardiserat frågekörningsspråk. Och det stöds av alla lösningar, även MySQL eller Postgresql. SQL-standarden utvecklades 1986 och sedan dess har flera versioner släppts.

MySQL

MySQL stöder inte alla nya funktioner i SQL-standarden. Utvecklarna valde denna utvecklingsväg för att hålla MySQL enkel att använda. Företaget försöker uppfylla standarderna, men inte på bekostnad av enkelheten. Om en funktion kan förbättra användbarheten kan utvecklare implementera den som sin egen förlängning utan att ta hänsyn till standarden.

postgresql

Postgresql är ett projekt med öppen källkod, det är utvecklat av ett team av entusiaster, och utvecklarna försöker följa SQL-standarden så mycket som möjligt och implementera alla de nyaste standarderna. Men allt detta sker på bekostnad av enkelheten. Postgresql är mycket komplext och på grund av detta är det inte lika populärt som MySQL.

Bearbetningsförmåga

Andra skillnader mellan postgresql och mysql framgår av föregående stycke, dessa är databehandlingsmöjligheter och begränsningar. Efterlevnad av nyare standarder ger naturligtvis nya möjligheter.

MySQL

När en fråga körs, laddar MySQL in hela serversvaret i klientens minne, för stora mängder data kanske det inte är särskilt bekvämt. I allmänhet är Postgresql överlägsen Mysql när det gäller funktioner, vi kommer vidare att överväga vilka.

postgresql

Postgresql stöder användningen av markörer för att flytta genom mottagna data. Du får bara en pekare, hela svaret lagras i databasserverns minne. Den här pekaren kan sparas mellan sessioner. Det stöder att bygga index för flera kolumner i en tabell samtidigt. Dessutom kan index vara olika typer, förutom hash och b-tree, är GiST och SP-GiST tillgängliga för att arbeta med städer, GIN för textsökning, BRIN och Bloom.

Postgresql stöder reguljära uttryck i frågor, rekursiva frågor och tabellärvning. Men det finns några begränsningar här, till exempel kan du bara lägga till ett nytt fält i slutet av tabellen.

Prestanda

Databaser måste vara optimerade för den miljö där du kommer att arbeta. Historiskt sett har MySQL designats för maximal prestanda, medan Postgresql har designats för att vara mycket anpassningsbar och så standardkompatibel som möjligt. Men med tiden har Postgresql fått många förbättringar och optimeringar.

MySQL

I de flesta fall används en InnoDB-tabell för att organisera arbetet med en databas i MySQL, denna tabell är ett B-träd med index. Index gör att du kan hämta data från disk mycket snabbt, och detta kommer att kräva färre diskoperationer. Men att skanna ett träd kräver att man hittar två index, vilket redan är långsamt. Allt detta betyder att MySQL blir snabbare än Postgresql endast när du använder en primärnyckel.

postgresql

All Postgresql-tabellhuvudinformation finns i RAM. Du kan inte skapa en tabell som är slut på minnet. Tabellposter sorteras efter index, så du kan hämta dem mycket snabbt. För mer bekvämlighet kan du använda flera index på samma tabell.

I allmänhet är PostgreSQL snabbare, förutom användningen av primärnycklar. Låt oss titta på några tester med olika operationer:

Datatyper

En av höjdpunkterna i båda databaserna är de datatyper som stöds som du kan använda. Eftersom båda lösningarna försöker matcha SQL-syntaxen har de liknande uppsättningar, men skiljer sig fortfarande åt på vissa sätt.

MySQL

MySQL stöder följande datatyper:

• TINYINT: mycket litet heltal.;
• SMALLINT: liten helhet;
• MEDIUMINT: medelstort heltal;
• INT: heltal av normal storlek;
• STORT: stor helhet;
• FLYTA: enkelprecisionssignerat flyttalsnummer;
• DUBBEL, DUBBEL PRECISION, RIKTIGT: dubbelprecisionssignerat flyttalnummer
• DECIMAL, NUMERISK: undertecknat flyttalnummer;
• DATUM: datumet;
  DATUM TID: kombination av datum och tid;
• TIDSSTÄMPEL: tidsstämpel;
• TID: tid;
  ÅR:år i formatet YY eller YYYY;
• RÖDING: sträng med fast storlek, höger vadderad med mellanslag till maximal längd;
• VARCHAR: sträng med variabel längd;
• TINYBLOB, LINYTEXT: binär eller textdata med en maximal längd på 255 tecken;
• BLOB, TEXT: binär eller textdata med en maximal längd på 65535 tecken;
• MEDIUMBLOB, MEDIUMTEXT: text eller binär data;
• LONGBLOB, LONGTEXT: text eller binär data med en maximal längd på 4294967295 tecken;
• ENUM: uppräkning;
• UPPSÄTTNING: set.

postgresql

De fälttyper som stöds i Postgresql är ganska olika, men de låter dig skriva exakt samma data:

• bigint: signerat 8-byte heltal;
• storserie: automatiskt inkrementerat 8-byte heltal;
• bit: binär sträng med fast längd;
• lite varierande: variabel längd binär sträng;
• boolesk: flagga;
• låda: rektangel på planet;
• byte: binära data;
• karaktär varierande: teckensträng med fast längd;
• karaktär:
• cidr: IPv4 eller IPv6 nätverksadress;
• cirkel: cirkel på planet;
• datum: kalenderdatum;
• Dubbel precision: flyttal med dubbel precision;
• inet: Internet IPv4- eller IPv6-adress;
• heltal: signerat 4-byte heltal;
• intervall: period;
• linje: en oändlig rät linje på ett plan;
• lseg: segment på ett plan;
• macaddr: MAC-adress;
• pengar: penningvärde;
• väg: geometrisk bana på planet;
• punkt: geometrisk punkt på planet;
• polygon: polygon på ett plan;
• verklig: Flyttal med en enda precision;
• smallint: två-byte heltal;
• serie: automatiskt ökande fyra-bitars heltal;
• text: teckensträng med variabel längd;
• tid: Tider på dygnet;
• tidsstämpel: datum och tid;
• tsquery: textsökfråga;
• tsvector: textsökningsdokument;
• uid: unik identifierare;
• xml: XML-data.

Som du kan se finns det fler datatyper i Postgresql och de är mer olika, det finns fälttyper för vissa typer av data som MySQL inte har. Skillnaden mellan MySQL och Postgresql är uppenbar.

Utveckling

Båda projekten är öppen källkod, men utvecklas på olika sätt. Alla gillar inte MySQL-utveckling. Och i denna jämförelse ger mysql och postgresql många skillnader.

MySQL

MySQL-databasen utvecklas av Oracle och det går rykten om att företaget har för avsikt att bromsa utvecklingen av motorn. Många gafflar i projektet har skapats, inklusive en gaffel av MariaDB från utvecklaren av den ursprungliga MySQL. Ändå går utvecklingen långsamt.

postgresql

Som nämndes i början av artikeln började utvecklingen vid University of Berkeley. Sedan flyttade hon till ett kommersiellt företag. Nu utvecklas programmet av en oberoende grupp programmerare och styrelse i flera företag. Nya versioner släpps ganska aktivt och får fler och fler nya funktioner.

Slutsatser

I den här artikeln jämförde vi mysql och postgresql, tittade på de viktigaste skillnaderna mellan de båda databashanteringssystemen och försökte förstå vilket som är bättre än postgresql eller mysql. I allmänhet är Postgresql bäst när det gäller kapacitet, men det är komplext och inte tillämpbart överallt. MySQL är enklare men saknar några coola funktioner. Och vilken databas kommer du att välja för ditt projekt? Varför henne? Skriv i kommentarerna!

I slutet av videon som beskriver funktionerna och framtidsutsikterna för Postgresql: