Innholdsserie:

1. Historie om utviklingen av MySQL og PostgreSQL

Historien til MySQL begynner i 1979, ved opprinnelsen sto lite selskap ledet av Monty Widenius. I 1996 dukket den første utgivelsen av 3.11 for Solaris med en offentlig lisens opp. Deretter ble MySQL portert til andre operativsystemer, og en spesiell kommersiell lisens dukket opp. I 2000, etter å ha lagt til et grensesnitt som ligner på Berkeley DB, ble databasen transaksjonell. Replikering ble lagt til omtrent samtidig. I 2001 la versjon 4.0 InnoDB-motoren til den eksisterende MyISAM, noe som resulterte i caching og økt ytelse. I 2004 ble versjon 4.1 utgitt, som introduserte underspørringer, delvis indeksering for MyISAM og Unicode. I versjon 5.0 i 2005 dukket det opp lagrede prosedyrer, markører, utløsere og visninger. MySQL utvikler kommersielle trender: i 2009 ble MySQL et varemerke for Oracle.

Historien til Postgres begynte i 1977 med Ingress-databasen.

I 1986 ble det omdøpt til PostgreSQL ved University of Berkeley, California.

I 1995 ble Postgres en åpen database. Interaktiv psql dukket opp.

I 1996 ble Postgres95 omdøpt til PostgreSQL-versjoner 6.0.

Postgres har flere hundre utviklere rundt om i verden.

2. Arkitektur av MySQL og PostgreSQL

PostgreSQL– en enhetlig databaseserver med en enkelt motor – lagringsmotor. Postgres bruker en klient-server-modell.

For hver klient, a ny prosess(ikke en strøm!). For å jobbe med slike klientprosesser bruker serveren semaforer.

Kundeforespørselen går gjennom følgende stadier.

1. Koble.
2. Parsing: riktigheten av forespørselen kontrolleres og et spørringstre opprettes. Parseren er basert på de grunnleggende Unix-verktøyene yacc og lex.
3. Omskriv: et spørringstre blir tatt og tilstedeværelsen av regler i det sjekkes, som ligger i systemkataloger. Hver gang brukerspørringen skrives om til en spørring som får tilgang til databasetabellene.
4. Optimizer: for hver forespørsel opprettes en spørringsplan, som sendes til eksekutøren. Poenget med planen er at den går gjennom alle mulige alternativer for å få resultatet (om man skal bruke indekser, sammenføyninger osv.), og velger det raskeste alternativet.
5. Utførelse av spørring: eksekveren går rekursivt gjennom treet og henter resultatet ved hjelp av sortering, sammenføyninger osv., og returnerer rader. Postgres er en objektrelasjonell database, hver tabell i den representerer en klasse, og arv implementeres mellom tabeller. Implementert SQL92 og SQL99 standarder.

Transaksjonsmodellen er bygget på grunnlag av den såkalte multi-version concurrency control (MVCC), som gir maksimal ytelse. Referensiell integritet sikres ved tilstedeværelsen av primær- og sekundærnøkler.

MySQL har to lag - et ytre sql-lag og et internt sett med motorer, hvorav InnoDb-motoren brukes oftest, da den støtter ACID mest.

Implementert SQL92 standard.

Fra et modulært synspunkt kan MySQL-kode deles inn i følgende moduler.

1. Serverinitialisering.
2. Tilkoblingsansvarlig.
3. Strømbehandler.
4. Kommandobehandler.
5. Autentisering.
6. Parser.
7. Optimizer.
8. Bordsjef.
9. Motorer (MyISAM, InnoDB, MEMORY, Berkeley DB).
10. Hogst.
11. Replikering.
12. Network API.
13. Kjerne API.

Rekkefølgen for driften av modulene er som følger: først lastes den første modulen, som leser kommandolinjealternativer, konfigurasjonsfiler, tildeler minne, initialiserer globale strukturer, laster inn systemtabeller og overfører kontroll til tilkoblingsbehandleren.

Når en klient kobler til databasen, overføres kontrollen til trådbehandleren, som oppretter en tråd (ikke en prosess!) for klienten, og autentiseringen av den kontrolleres.

Kundeforespørsler avhengig av type på øvre nivå behandlet av den fjerde modulen (dispatcher). Forespørsler vil bli loggført innen den 11. modulen. Kommandoen sendes til parseren og hurtigbufferen sjekkes. Deretter kan forespørselen gå til optimalisereren, tabellmodulen, replikeringsmodulen osv. Som et resultat blir dataene returnert til klienten gjennom strømbehandleren.

Den viktigste koden er i filen sql/mysqld.cc. Det inneholder grunnleggende funksjoner, som ikke har endret seg siden versjon 3.22: init_common_variables() init_thread_environment() init_server_components() grant_init() // sql/sql_acl.cc init_slave() // sql/slave.cc get_options()newsockets_connections()socket_connections()newsockets_connections() check_connection() acl_check_host() // sql/sql_acl.cc create_random_string() // sql/password.cc check_user() // sql/sql_parse.cc mysql_parse() // sql/sql_parsecommandche() Quch_query_ () // sql/sql_cache.cc BLI MED::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update.cc mysql_check/q_sql(sql) .cc

sql/sql_class.h-overskriften definerer basisklassene: Query_arena, Statement, Security_context, Open_tables_state classes, THD. THD-klasseobjektet representerer et trådhåndtak og er et argument stor kvantitet funksjoner.

3. Sammenligning av MySQL og PostgreSQL: likheter og forskjeller

SYRE standard

ACID-standarden er basert på atomitet, integritet, isolasjon og pålitelighet. Denne modellen brukes for å garantere dataintegritet. Dette gjennomføres på grunnlag av transaksjoner. PostgreSQL er fullt ACID-kompatibel. For å støtte ACID fullt ut i MySQL, må du sette default-storage-engine=innodb i konfigurasjonen.

Opptreden

Databaser er ofte optimalisert basert på miljøet de opererer i. Begge basene har ulike teknologierå forbedre ytelsen. Historisk sett begynte MySQL å bli utviklet med tanke på hastighet, mens PostgreSQL ble utviklet helt fra starten som en database med et stort antall innstillinger og samsvar med standarden. PostgreSQL har en rekke innstillinger som øker tilgangshastigheten:

• delvise indekser;
• datakomprimering;
• minne tildeling;
• forbedret cache.

MySQL har delvis støtte for delvise indekser i InnoDB. Hvis du tar MySQL ISAM-motoren, viser det seg å være raskere på flate søk, mens det ikke er blokkering på innlegg, ingen støtte for transaksjoner, fremmednøkler.

Komprimering

PostgreSQL komprimerer og dekomprimerer data bedre, slik at du kan lagre mer data på diskplass. Samtidig leses komprimeringsdata raskere fra disken.

MySQL-komprimering for forskjellige motorer støttes delvis, delvis ikke, og dette avhenger av den spesifikke versjonen av en bestemt motor.

Når det gjelder ytelse med flere prosessorer, har PostgreSQL en fordel fremfor MySQL. Selv MySQL-utviklerne innrømmer selv at motoren deres ikke er så god i denne forbindelse.

Datatyper

MySQL: bruker typene TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB for å lagre binære data, som varierer i størrelse (opptil 4 GB).

Karakter: fire typer - TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

PostgreSQL: Støtter brukerdatamotor med CREATE TYPE-kommando, BOOLEAN-type, geometriske typer.

Karakter: TEKST (begrensning – maks radstørrelse).

For å lagre binære data er det en BLOB-type, som er lagret i filsystem. Tabellkolonner kan defineres som flerdimensjonal matrise variabel lengde. Objektrelasjonell utvidelse: Strukturen til en tabell kan arves fra en annen tabell.

Lagrede prosedyrer

Både PostgreSQL og MySQL støtter lagrede prosedyrer. PostgreSQL følger Oracle PL/SQL-standarden, MySQL følger IBM DB2-standarden. MySQL støtter utvide SQL for å skrive funksjoner i C/C++ siden versjon 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C for å skrive lagrede prosedyrer.

Nøkler

Både PostgreSQL og MySQL støtter unike primærnøkkel og fremmednøkkel. MySQL støtter ikke sjekkbegrensning, pluss sekundære nøkler er delvis implementert. PostgreSQL: full implementering pluss støtte for ON DELETE CASCADE og ON UPDATE CASCADE.

Utløsere

MySQL: rudimentær støtte. PostgreSQL: deklarative utløsere: SELECT, INSERT, DELETE, UPDATE, ISTEAD OF; prosedyreutløsere: CONSTRAINT TRIGGER. Hendelser: FØR eller ETTER på INSERT, DELETE, UPDATE.

Autoinkrement

MySQL: Det kan bare være én slik kolonne i en tabell, som må indekseres. PostgreSQL: SERIAL datatype.

Replikasjoner

Støttes i både MySQL og PostgreSQL. PostgreSQL har en modulær arkitektur, og replikering er inkludert i separate moduler:

• Slony-I er hovedreplikeringsmekanismen i Postgres, ytelsen reduseres som en kvadratisk funksjon av antall servere;

Replikering i PostgreSQL er triggerbasert og tregere enn i MySQL. Det er planlagt å legge til replikering til kjernen fra og med versjon 8.4.

I MySQL er replikering inkludert i kjernen og har to smaker, som starter med versjon 5.1:

• SBR – setningsbasert replikering;
• RBR – radbasert replikering.

Den første typen er basert på logging av poster til en binær logg, den andre er basert på logging av endringer. Fra og med versjon 5.5 støtter MySQL såkalt semi-synkron replikering, der hovedserveren (master) tilbakestiller data til en annen server (slave) med hver commit. NDB-motoren utfører full synkron to-fase replikering.

Transaksjoner

MySQL: Kun InnoDB. Støtt SAVEPOINT, Rull TILBAKE TIL SAVEPOINT. Låsenivåer: tabellnivå (MyISAM). PostgreSQL: støttet pluss leseforpliktende og isolasjonsnivåer. Støtte ROLLBACK, ROLLBACK TIL SAVEPOINT. Låsenivåer: radnivå, tabellnivå.

Privileginivåer

PostgreSQL: Privilegier kan tildeles en bruker eller brukergruppe.

Eksporter-importer data

MySQL: et sett med eksportverktøy: mysqldump, mysqlhotcopy, mysqlsnapshot. Import fra tekstfiler, html, dbf. PostgreSQL: eksport - pg_dump-verktøy. Importer mellom databaser og filsystem.

Nestede søk

Tilgjengelig i både MySQL og PostgreSQL, men fungerer kanskje ikke effektivt i MySQL.

Indeksering

Indekshashing: delvis i MySQL, full i PostgreSQL. Fulltekstsøk: i MySQL – delvis, i PostgreSQL – full. Delvise indekser: støttes ikke i MySQL, støttes i PostgreSQL. Multi-kolonne indekser: i MySQL er grensen 16 kolonner, i PostgreSQL – 32. Uttrykksindekser: i MySQL – emulering, i PostgreSQL – full. Ikke-blokkerende opprette indeks: i MySQL - delvis, i PostgreSQL - full.

Oppdeling

MySQL støtter horisontal partisjonering: område, liste, hash, nøkkel, sammensatt partisjonering. PostgreSQL støtter RANGE og LIST. Automatisk partisjonering for tabeller og indekser.

Automatisk gjenoppretting fra feil

MySQL: delvis for InnoDB - du må ta en sikkerhetskopi manuelt. PostgreSQL: Write Ahead Logging (WAL).

Datalagringsmotorer

PostgreSQL støtter én motor – Postgres Storage System. Det er flere av dem i MySQL 5.1:

• MyISAM – brukes til å lagre systemtabeller;
• InnoDB – maksimal ACID-overholdelse, lagrer data fra primærnøkler, cacher innsettinger, støtter komprimering fra versjon 5.1 - se attributt ROW_FORMAT=KOMPRESSERT;
• NDB Cluster – en minneorientert motor, klyngearkitektur som bruker synkron replikering;
• ARKIV – støtter komprimering, bruker ikke indekser;
• og også: MERGE, MEMORY (HEAP), CSV.

InnoDB er utviklet av InnoBase, et datterselskap av Oracle. I versjon 6 skal to motorer vises - Maria og Falcon. Falcon er en motor basert på ACID-transaksjoner.

Lisensering

PostgreSQL: BSD (Berkeley Software Distribution) åpen kildekode. MySQL: GPL (Gnu General Public License) eller kommersiell. MySQL er åpen kildekode-produkt. Postgres er et åpen kildekode-prosjekt.

Konklusjon

For å oppsummere kan vi si følgende: MySQL og PostgreSQL er de to mest populære åpen kildekode-databasene i verden. Hver base har sine egne egenskaper og forskjeller. Hvis du trenger rask lagring Til enkle spørsmål med minimalt oppsett vil jeg anbefale MySQL. Hvis du trenger sikker lagring for store datamengder med mulighet for utvidelse, replikering, fullt kompatibel med moderne standarder SQL-språk, Jeg vil foreslå å bruke PostgreSQL.

Vi vil diskutere spørsmål MySQL-innstillinger og PostgreSQL.

Ressurser for nedlasting

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

Zone=Åpen kildekode, Linux

ArtikkelID=779830

ArticleTitle=MySQL & PostgreSQL: Del 1. Sammenlignende analyse

Et utmerket spørsmål for en holivar. Men vi vil ikke. Publisert av forfatteren undersøker forfatteren begge DBMS-ene fra posisjonen til å ta vare på data og kommer til den konklusjon at PostgreSQL er egnet for seriøse prosjekter, og MySQL er ikke et alternativ i det hele tatt.

Et eksempel på overlegenheten til PosgreSQL over MySQL

La oss for eksempel lage en tabell og sette typen numeric(4, 2) for ett av feltene - fire sifre for å lagre hele tallet og to sifre etter desimaltegnet. Og så skal vi prøve å sette inn et tall som ikke samsvarer med beskrivelsen. Og hva tror du? Ikke noe problem!

I manuell modus vil vi (muligens) se en advarsel (1 advarsel), prøv å gjette hva det handler om og gjenopprett den forrige verdien. Men advarselen er lett å gå glipp av. Hvis du skriver en søknad som omhandler lagring av økonomiske data, vil slike feil være svært kostbare.

PostgreSQL tar vare på dataene dine og oppfører seg mer seriøst:

INSERT INTO DATA VALUES (1, 1234.5678); FEIL: NUMERISK FELT-overløp DETALJER: ET FELT MED NØYAKTIGHET 4 , skala 2 må avrundes TIL en absolutt VERDI mindre enn 10 ^2 .

De lar oss rett og slett ikke gjøre en feil. Dessuten vil meldingen inneholde detaljer: nøyaktig hvilken begrensning vi brøt og hva maksimal størrelse nummer gitt Det er det.

Og nå litt mystikk. Husker du hvordan vi beskrev at id-feltet for MySQL ikke skal være NULL? La oss prøve:

Overraskende nok, til tross for det eksplisitte forbudet (IKKE NULL), tillot MySQL DBMS å oppdatere feltet, og satte verdien til 0, selv om vi ikke sa noe om null i det hele tatt. 0 og NULL er helt forskjellige enheter. 0 er et tall. NULL er en spesiell indikator som forteller oss at vi ikke vet hvilket tall som finnes i dette feltet. Og det trenger ikke å være 0. Dermed tildelte DBMS igjen en tilfeldig verdi til databasen vår. Hvis applikasjonen din har samme feil, vil MySQL hjelpe denne feilen forbli uoppdaget i lang tid. Hva med PostgreSQL? Alt er klart her.

Sammenligningen nedenfor ble gjort i MySQL AB. Jeg prøvde å være så nøyaktig og objektiv som mulig, men ved å vite MySQL kunne jeg ikke skryte av den samme kunnskapen om PostgreSQL-funksjoner, så jeg kunne ha tatt feil på noen måter.

Først av alt vil jeg merke meg at PostgreSQL og MySQL er mye brukt programvareprodukter, som ble utviklet for forskjellige formål (selv om skaperne av begge streber etter å bringe dem til full kompatibilitet med ANSI SQL-standarden). Dette betyr at MySQL er mer egnet for å løse noen problemer, mens PostgreSQL er mer egnet for andre. Når du velger en DBMS, sjekk om dens evner oppfyller kravene til problemet som skal løses. Hvis du vil topphastighet arbeid, ville det sannsynligvis være best å velge MySQL-server. Hvis du trenger tilleggsfunksjoner, kun tilgjengelig i PostgreSQL, denne DBMS er verdt å bruke.

En betydelig forskjell mellom MySQL og PostgreSQL er at nesten all koden i MySQL ble laget av utviklere som jobber hos MySQL AB og stadig er opptatt med å forbedre serverkoden. Unntaket fra denne regelen er transaksjonssystemer og regulære uttrykksbiblioteket.

Det meste av PostgreSQL-koden er skrevet av mange utviklere som ikke har noen forbindelse med hverandre. For ikke lenge siden kunngjorde PostgreSQL-utviklerne at teamet deres endelig hadde nok tid til å gjennomgå all koden som er inkludert i neste versjon av PostgreSQL.

Sammenligning av MySQL- og PostgreSQL-funksjoner

MySQL har følgende fordeler fremfor PostgreSQL:

· MySQL er vanligvis mye raskere enn PostgreSQL. I tillegg implementerer MySQL 4.0 en spørringsbuffer. Den lar deg øke hastigheten på forespørselsbehandlingen mange ganger for nettsteder som domineres av gjentatte leseforespørsler.

· I telling MySQL-brukere også langt bedre enn PostgreSQL. Derfor er koden testet mye mer omhyggelig og påliteligheten har eksperimentelt vist seg å være større enn PostgreSQL. MySQL brukes oftere enn PostgreSQL i produksjon, hovedsakelig fordi MySQL AB (tidligere TCX DataKonsult AB) gir høykvalitets kommersiell teknisk MySQL-støtte siden utseendet til dette systemet på markedet, og PostgreSQL ikke hadde noen støtte før ganske nylig.

· MySQL fungerer bedre på Windows enn PostgreSQL. MySQL Server kjører som en ekte (native) Windows-applikasjon (en tjeneste på NT/2000/XP), mens PostgreSQL kjører i emuleringsmiljøet Cygwin. Jeg har hørt om mangelen på stabilitet til PostgreSQL i Windows-miljøet, men jeg kunne fortsatt ikke bekrefte denne informasjonen selv.

MySQL utstyrt stort beløp API for andre språk og støttes av mange eksisterende programmer enn PostgreSQL.

MySQL kjører på svært pålitelig industrielle systemer 24/7 (24 timer i døgnet, 7 dager i uken). I de fleste tilfeller er ingen opprydding nødvendig i MySQL. PostgreSQL kan ennå ikke fungere på slike systemer, siden noen ganger er det nødvendig å kjøre VACUUM for å frigjøre plassen som er okkupert av konsekvensene av UPDATE- og DELETE-kommandoene og utføre den statistiske analysen som er nødvendig for å oppnå maksimal ytelse PostgreSQL. Det er også nødvendig å kjøre VACUUM etter hvert tillegg av flere kolonner til tabellen. På travle systemer må VACUUM kjøres oftere, i verste fall flere ganger om dagen. Men mens VACUUM kjører (og arbeidet kan vare i timevis hvis databasen er stor nok), er databasen praktisk talt "død". I PostgreSQL versjon 7.2 fører imidlertid ikke lenger de grunnleggende funksjonene til dette programmet til at databasen blokkeres, og brukere kan fortsette å jobbe med den på vanlig måte. Den nye VACUUM FULL-kommandoen tar ting mer seriøst: akkurat som i eldre versjoner, låser den tabellen og komprimerer en kopi av tabellen på disken.

· Det er betydelig flere bøker om MySQL enn om PostgreSQL. Bøker om MySQL er utgitt av O"Reilly, SAMS, Que og New Riders. Alle MySQL-funksjoner er beskrevet i detalj i dokumentasjonen, siden det er forutsetning innlemme nye funksjoner i koden.

· MySQL har en mye kraftigere ALTER TABLE-implementering.

· MySQL gir muligheten til å lage tabeller uten transaksjoner, noe som er nødvendig for applikasjoner som krever høyest mulig hastighet.

· MySQL kan fungere med to transaksjonsbevisste tabellmotorer, nemlig InnoDB og BerkeleyDB. Siden alle transaksjonsstøttesystemer fungerer forskjellig under ulike forhold, gir dette utvikleren mulighet til å finne beste løsningen for forholdene som systemet hans vil fungere under. Se avsnitt 7 MySQL-tabelltyper.

· Kommandoen MERGE tabellsammenslåing gir deg den unike muligheten til å lage en visning av flere identiske tabeller og arbeide med dem som én. Dette er spesielt praktisk for arbeid med logger delt opp, for eksempel etter måned.

· Evne til å komprimere skrivebeskyttede tabeller uten å overstyre direkte adgang til sine poster, forbedrer systemytelsen ved å redusere antall diskleseoperasjoner. Dette er spesielt nyttig for arkivering.

· MySQL implementerer fulltekstsøk.

· Det er mulig å jobbe med flere databaser gjennom én tilkobling (selvfølgelig avhengig av brukerens rettigheter).

· MySQL ble designet fra starten for å være flertråds, mens PostgreSQL bruker prosesser. Å bytte kontekster og få tilgang til delte data via flere tråder er mye raskere enn ved separate prosesser. Dette gir MySQL Server en god ytelsesfordel i flerbrukerapplikasjoner, og det lar MySQL Server også dra nytte av symmetriske multiprosessor (SMP)-systemer mye mer effektivt.

· MySQL har et mye kraftigere privilegiesystem enn PostgreSQL. Mens PostgreSQL bare gir INSERT, SELECT og UPDATE/DELETE-privilegier over en database eller tabell, gir MySQL muligheten til å definere et komplett sett med forskjellige privilegier på database-, tabell- og kolonnenivå. I tillegg lar MySQL deg angi privilegier for verts-/brukerkombinasjoner.

· MySQL bruker en kommunikasjonsprotokoll mellom klient og server med datakomprimering, som øker systemytelsen under forhold med lavhastighets kommunikasjonskanaler.

· Alle typer tabeller i MySQL (unntatt InnoDB) er implementert som filer (en tabell per fil), noe som i stor grad forenkler opprettelsen sikkerhetskopier, flytte, slette og til og med lage symbolske koblinger mellom databaser og tabeller, selv om serveren er nede.

· Oppdatering av MySQL er helt smertefritt. Når du oppgraderer MySQL, er det ikke nødvendig å kopiere/gjenopprette data, noe som er nødvendig å gjøre når du installerer de fleste PostgreSQL-oppdateringer.

Nedenfor er fordelene med PostgreSQL fremfor MySQL i dag.

Andre grunner til å velge PostgreSQL:

· I noen tilfeller er PostgreSQL nærmere ANSI SQL.

· PostgreSQL-arbeid Du kan øke hastigheten ved å utføre koden din som lagrede prosedyrer.

· Ved lagring av geografiske data gir R-trær PostgreSQL en fordel fremfor MySQL (merk: i MySQL-versjoner 4.1, støtte for R-trær er implementert for MyISAM-tabeller).

· Teamet med PostgreSQL-utviklere som skriver kode for serveren er større.

Ulemper med PostgreSQL sammenlignet med MySQL:

· VACUUM gjør PostgreSQL vanskelig å bruke på alltid-på-systemer.

· Tilgjengelighet av kun transaksjonstabeller.

· Betydelig flere sakte arbeid INSERT, DELETE og UPDATE kommandoer.

Konklusjon

De eneste tilgjengelige referansene i dag som sammenligner MySQL Server og PostgreSQL som alle kan laste ned og kjøre, er referansene i MySQL-pakken. Og det er derfor jeg velger MySQL

Blogg til selskapet Mail.ru Group

I påvente av rapporten min på PGCONF.RUSSIA 2015-konferansen, vil jeg dele noen observasjoner om de viktige forskjellene mellom MySQL og PostgreSQL DBMS. Dette materialet vil være nyttig for alle de som ikke lenger er fornøyd med egenskapene og funksjonene til MySQL, så vel som de som tar sine første skritt i Postgres. Selvfølgelig skal dette innlegget ikke betraktes som en uttømmende liste over forskjeller, men det vil være ganske tilstrekkelig for å ta en avgjørelse til fordel for en eller annen DBMS.

Replikering

Temaet for rapporten min er "Asynkron replikering uten sensur, eller hvorfor PostgreSQL vil erobre verden," og replikering er et av de mest smertefulle temaene for travle prosjekter som bruker MySQL. Det er mange problemer - riktig drift, stabilitet, ytelse - og ved første øyekast ser de ikke sammen. Ser vi på den historiske konteksten, får vi interessant konklusjon: MySQL-replikering har så mange problemer fordi det ikke var gjennomtenkt, og poenget uten retur var støtte for lagringsmotoren (plugin-motorer) uten svar på spørsmålene "hva skal jeg gjøre med loggen?" og "hvordan forskjellige lagringsmotorer kan delta i replikering." I 2004, i PostgreSQL-postlisten, prøvde en bruker å "finne" lagringsmotoren i kildekode PostgreSQL og ble veldig overrasket over at de ikke var der. Under diskusjonen foreslo noen å legge til denne funksjonen til PostgreSQL, og en av utviklerne svarte: "Gutter, hvis vi gjør dette, vil vi få problemer med replikering og transaksjoner mellom motorer."

Problemet er at mye lagring styringssystemer… ofte gjør sine egne WAL og PITR. Noen gjør også sin egen bufferhåndtering, låsing og replikering/lasthåndtering. Så, som du sier, det er vanskelig å si hvor et grensesnitt skal være
abstrahert.

lenke til dette brevet i postgresql e-postliste

Mer enn 10 år har gått, og hva ser vi? MySQL har irriterende problemer med transaksjoner mellom tabeller i forskjellige lagringsmotorer og MySQL har problemer med replikering. I løpet av disse ti årene har PostgreSQL lagt til plug-in datatyper og indekser, og har også replikering – det vil si at fordelen med MySQL er jevnet ut, mens de arkitektoniske problemene til MySQL består og forstyrrer livet. MySQL 5.7 prøvde å løse replikeringsytelsesproblemet ved å parallellisere det. Siden prosjektet på jobb er veldig følsomt for replikeringsytelse på grunn av omfanget, prøvde jeg å teste om det ble noe bedre. Jeg fant ut at parallell replikering i 5.7 er tregere enn enkelt-tråds replikering i 5.5, og bare i noen tilfeller - omtrent det samme. Hvis du bruker MySQL 5.5 og ønsker å oppgradere til en nyere versjon, vær oppmerksom på at migrering ikke er mulig for høyt belastede prosjekter, siden replikering rett og slett ikke lenger vil følge med.

Etter høybelastningsforedraget noterte Oracle testen jeg utviklet og sa at de ville prøve å fikse problemet; nylig skrev de til og med til meg at de kunne se parallellitet i testene sine, og sendte meg innstillingene. Hvis jeg ikke tar feil, var det med 16 tråder en liten akselerasjon i forhold til den entrådede versjonen. Dessverre har jeg ennå ikke gjentatt testene mine på de angitte innstillingene - spesielt fordi problemene våre fortsatt er relevante med slike resultater.

De eksakte årsakene til denne ytelsesregresjonen er ukjent. Det var flere antagelser – for eksempel skrev Christian Nelsen, en av MariaDB-utviklerne, på bloggen sin at det kan være problemer med ytelsesskjemaet og trådsynkroniseringen. På grunn av dette er det en regresjon på 40 %, som er synlig i vanlige tester. Oracle-utviklere tilbakeviser dette, og de overbeviste meg til og med om at det ikke eksisterer; tilsynelatende ser jeg et annet problem (og hvor mange av dem er det?).

I MySQL-replikering forverres problemer med lagringsmotoren av det valgte replikeringsnivået – de er logiske, mens de i PostgreSQL er fysiske. I prinsippet har logisk replikering sine fordeler; det lar deg gjøre mer interessante ting, jeg vil også nevne dette i rapporten. Men PostgreSQL, selv innenfor rammen av dens fysiske replikering, reduserer allerede alle disse fordelene til ingenting. Med andre ord, nesten alt som er i MySQL kan allerede gjøres i PostgreSQL (eller vil være mulig i nær fremtid).

Du kan ikke håpe på å implementere fysisk replikering på lavt nivå i MySQL. Problemet er at i stedet for én logg (som i PostgreSQL), er det to eller fire av dem, avhengig av hvordan du teller dem. PostgreSQL forplikter ganske enkelt spørringer, de går til en logg, og denne loggen brukes i replikering. PostgreSQL-replikering er superstabil fordi den bruker samme logg som failover-operasjoner. Denne mekanismen har blitt skrevet i lang tid, godt testet og optimalisert.

I MySQL er situasjonen annerledes. Vi har en separat InnoDB-logg og en replikeringslogg, og vi må forplikte begge. Og dette er en to-fase forpliktelse mellom tidsskrifter, som per definisjon er treg. Det vil si at vi ikke bare kan si at vi gjentar en transaksjon fra InnoDB-loggen – vi må finne ut hva slags forespørsel det er og kjøre den på nytt. Selv om dette er logisk replikering, på linjenivå, må disse linjene ses etter i indeksen. Og ikke bare må du gjøre mye arbeid for å utføre spørringen, men den vil igjen bli skrevet til InnoDB-loggen på replikaen, noe som tydeligvis ikke er bra for ytelsen.

I PostgreSQL, i denne forstand, er arkitekturen mye mer gjennomtenkt og bedre implementert. Den kunngjorde nylig en funksjon kalt Logical Decoding – som lar deg gjøre alle slags interessante ting, som er svært vanskelig å gjøre i en fysisk journal. I PostgreSQL er dette et tillegg på toppen, logisk dekoding lar deg jobbe med en fysisk logg som om den var en logisk. Det er denne funksjonaliteten som snart vil fjerne alle fordelene med MySQL-replikering, bortsett fra kanskje loggstørrelsen - statement-basert MySQL-replikering vil vinne - men statement-basert MySQL-replikering har helt ville problemer på de mest uventede stedene, og bør ikke vurderes Bra valg(Jeg vil også snakke om alt dette i rapporten).

I tillegg er det triggerreplikering for PostgreSQL – dette er Tungsten, som lar deg gjøre det samme. Triggerreplikering fungerer som følger: utløsere settes, de fyller tabeller eller skriver filer, resultatet sendes til replikaen og brukes der. Det er gjennom Tungsten, så vidt jeg vet, at de migrerer fra MySQL til PostgreSQL og omvendt. I MySQL fungerer logisk replikering direkte på motornivå, og det er ikke lenger mulig å gjøre det på annen måte.

Dokumentasjon

PostgreSQL har mye bedre dokumentasjon. I MySQL ser det formelt ut til og med å eksistere, men poenget er individuelle alternativer kan være vanskelig å forstå. Det ser ut til å være skrevet hva de gjør, men for å forstå hvordan du konfigurerer dem riktig, må du bruke uoffisiell dokumentasjon og se etter artikler om dette emnet. Ofte trenger du å forstå MySQL-arkitekturen; uten denne forståelsen ser innstillingene ut som en slags magi.

For eksempel tok Percona-selskapet fart: de drev MySQL Performance Blog, og i denne bloggen var det mange artikler som diskuterte visse aspekter ved bruk av MySQL. Dette brakte vill popularitet, brakte kunder inn i rådgivning og tillot oss å tiltrekke ressurser for å lansere utviklingen av vår egen Percona-Server-gaffel. Eksistensen og populariteten til MySQL Performance Blog beviser at offisiell dokumentasjon rett og slett ikke er nok.

PostgreSQL har faktisk alle svarene i dokumentasjonen. På den annen side har jeg hørt mye kritikk når jeg sammenligner PostgreSQL-dokumentasjonen med det "voksne" Oracle. Men dette er faktisk veldig viktig indikator. Ingen prøver å sammenligne MySQL med det voksne Oracle i det hele tatt - det ville vært morsomt og absurd - men PostgreSQL begynner allerede å bli sammenlignet ganske seriøst, PostgreSQL-fellesskapet hører denne kritikken og jobber med å forbedre produktet. Dette tyder på at den i sine evner og ytelse begynner å konkurrere med slike kraftig system som Oracle de kjører på mobiloperatører og banker, mens MySQL forblir i nettstednisjen. Og gigantiske prosjekter som har vokst til en stor mengde data og brukere slurper opp MySQL med en stor skje, og løper stadig inn i sine begrensninger og arkitektoniske problemer som ikke kan korrigeres ved å bruke en rimelig mengde krefter og tid.

Et eksempel på slike store prosjekter på PostgreSQL er 1C: PostgreSQL er tilgjengelig som et alternativ i stedet for Microsoft SQL, og Microsoft SQL er virkelig en fantastisk DBMS, en av de kraftigste. PostgreSQL kan erstatte MS SQL, og prøver å erstatte det med MySQL... la oss senke teppet av medlidenhet over denne scenen, som Mark Twain skrev.

Standarder

PostgreSQL overholder SQL-92, SQL-98, SQL-2003 (alle rimelige deler av den er implementert) og jobber allerede med SQL-2011. Dette er veldig kult. Til sammenligning støtter ikke MySQL SQL-92 engang. Noen vil si at i MySQL ble et slikt mål rett og slett ikke satt av utviklerne. Men du må forstå at forskjellen mellom versjoner av standarden ikke er små endringer - dette er ny funksjonalitet. Det vil si at i øyeblikket da MySQL sa: "Vi vil ikke følge standarden," introduserte de ikke bare noen mindre forskjeller som gjorde MySQL vanskelig å støtte, de stengte også døren for implementering av mange nødvendige og viktige funksjoner. Det er fortsatt ingen riktig optimizer. Det som kalles optimalisering der kalles "parser" pluss normalisering i PostgreSQL. I MySQL er dette bare en plan for utførelse av spørringer, uten separasjon. Og MySQL vil ikke komme til å støtte standarder veldig snart, siden det er en byrde som presser på dem bakoverkompatibilitet. Ja, de vil ha det, men om fem år har de kanskje noe. PostgreSQL har allerede alt nå.

Ytelse og administrativ kompleksitet

Fra synspunkt du bare administrasjonssammenligning er ikke til fordel for PostgreSQL. MySQL er mye enklere å administrere. Og ikke fordi det i denne forstand er bedre gjennomtenkt, men rett og slett vet hvordan man gjør mye mindre. Følgelig er det lettere å konfigurere det.

MySQL har et problem med komplekse spørringer. For eksempel, MySQL vet ikke hvordan å senke en gruppe i separate deler av union alle. Forskjellen mellom de to spørringene - i vårt eksempel fungerte gruppering etter individuelle tabeller og union alle på toppen 15 ganger raskere enn union alle og deretter gruppering, selv om optimizeren må bringe begge spørringene inn i den samme, effektive planen for utføring av spørringer. Vi vil måtte generere slike forespørsler manuelt – det vil si å kaste bort utviklernes tid på hva databasen skal gjøre.

"Enkelheten" til MySQL er resultatet, som du kan se ovenfor, fra ekstremt dårlige evner - MySQL fungerer rett og slett dårligere og krever mer tid og krefter under utvikling. Derimot har PostrgreSQL histogrammer og en normal optimizer, og vil utføre slike spørringer effektivt. Men hvis det er histogrammer, så er det innstillingene deres - i det minste bøttestørrelse. Du må vite om innstillingene og endre dem i noen tilfeller - derfor må du forstå hva denne innstillingen er, hva den er ansvarlig for, kunne gjenkjenne slike situasjoner og se hvordan du velger de optimale parameterne.

Noen ganger hender det at PostrgreSQLs ferdigheter kan hindre i stedet for å hjelpe. 95 % av tiden fungerer alt bra - bedre enn MySQL - men en dum spørring går mye tregere. Eller alt fungerer bra, og så plutselig (fra brukerens synspunkt) etter hvert som prosjektet vokser, begynte noen spørringer å fungere dårlig (det var mer data, en annen plan for utførelse av spørringer begynte å bli valgt). Mest sannsynlig, for å fikse det, bare kjør analyser eller finjuster innstillingene litt. Men du må vite hva du skal gjøre og hvordan du gjør det. Som et minimum må du lese PostgreSQL-dokumentasjonen om dette emnet, men av en eller annen grunn liker de ikke å lese dokumentasjon. Kanskje fordi det er til liten hjelp i MySQL? :)

Jeg vil understreke at PostgreSQL ikke er dårligere i denne forstand, det lar deg bare utsette problemer, mens MySQL umiddelbart kaster dem ut og du må bruke tid og penger på å løse dem. Slik sett fungerer MySQL alltid konsekvent dårlig, og selv på utviklingsstadiet tar folk disse funksjonene i betraktning: de gjør alt på enklest mulig måte. Dette gjelder bare produktivitet, mer presist, metodene for å oppnå det og forutsigbarheten. Når det gjelder korrekthet og bekvemmelighet, er PostgreSQL hode og skuldre over MySQL.

Så hva bør du velge?

For å velge mellom MySQL og PostgreSQL for et spesifikt prosjekt, må du først svare på andre spørsmål.

For det første, hvilken erfaring har teamet? Hvis hele teamet har 10 års erfaring med å jobbe med MySQL og trenger å komme i gang så raskt som mulig, så er det ikke et faktum at det er verdt å endre et kjent verktøy til et ukjent. Men hvis tidsfrister ikke er kritiske, er PostgreSQL verdt å prøve.

For det andre må vi ikke glemme driftsproblemer. Hvis du ikke har et høyt belastet prosjekt, er det fra et ytelsessynspunkt ingen forskjell mellom disse to DBMS-ene. Men PostgreSQL har en annen viktig fordel: den er strengere, gjør flere sjekker for deg, gir deg mindre mulighet til å gjøre feil, og dette er en stor fordel på lang sikt. For eksempel, i MySQL må du skrive dine egne verktøy for å verifisere den vanlige referanseintegriteten til databasen. Og selv med dette kan det være problemer. I denne forstand er PostgreSQL et kraftigere, mer fleksibelt verktøy, og det er mer behagelig å utvikle på det. Men dette avhenger i stor grad av utviklerens erfaring.

For å oppsummere: hvis du har en enkel nettbutikk, ingen penger til en admin, ingen seriøse ambisjoner å vokse inn i stort prosjekt og har erfaring med MySQL, så ta MySQL. Hvis du forventer at prosjektet vil bli populært, hvis det er stort, vil det være vanskelig å skrive det om, hvis det har kompleks logikk og relasjoner mellom tabeller – ta PostgreSQL. Selv ut av boksen vil det fungere for deg, vil hjelpe deg i utviklingen, vil spare tid og vil gjøre det lettere for deg å vokse.