Alegerea dintre MySQL și PostgreSQL este o decizie pe care fiecare dezvoltator de aplicații web trebuie să o ia atunci când alege între diferite SGBD-uri Open-Source. Ambele soluții sunt testate în timp și ambele merită o atenție deosebită. SGBD MySQL a fost menit să fie mai rapid, dar mai puțin funcțional, în timp ce dezvoltatorii PostgreSQL s-au concentrat pe gadgeturi mai utile din punct de vedere funcțional, pentru a se potrivi cât mai bine cu standardele Oracle. MySQL este foarte popular printre dezvoltatorii web datorită vitezei și ușurinței sale de utilizare. PosgreSQL este mai puțin popular deoarece este convenabil și simplu doar pentru acei dezvoltatori care au folosit anterior Oracle sau alte baze de date similare. Dar asta e tot caracteristicile vitezei MySQL în comparație cu PostgreSQL se topește treptat, deoarece cu fiecare actualizare PostgreSQL crește vizibil în viteză. Acum să aruncăm o privire mai atentă la aceste două SGBD.

Arhitectură

PostgreSQL este un SGBD unic cu un singur server de stocare a datelor (SDS). MySQL are două straturi în arhitectura sa. Primul strat este un set de servere de stocare a datelor. Prin urmare, atunci când se compară, acestea indică de obicei ce server de stocare MySQL a fost utilizat. Fiecare server se distinge prin parametrii de performanță și funcționalitatea sa. Cel mai comun dintre ele este InnoDB. Se deosebește de restul prin suport deplin pentru modelul ACID și performanță ridicată. Un concurent direct al InnoDB este MyISAM, care este potrivit pentru procesarea și stocarea unor cantități relativ mici de date care sunt citite în principal din baza de date, mai degrabă decât scrise. Și, de asemenea, atunci când absența ACID nu este critică. Aplicațiile care funcționează cu MySQL pot folosi simultan mai multe sisteme de stocare pentru a oferi cel mai bun set funcționalitate și performanță.

Performanţă

Performanța DBMS poate fi optimizată în funcție de mediul de utilizare. Comparațiile dintre performanța diferitelor SGBD-uri trebuie, de asemenea, efectuate cu mare atenție și să acorde atenție scopului utilizării și configurației în care funcționează SGBD. Atât MySQL, cât și PostgreSQL au multe pârghii cu care puteți controla performanța.

Orientare DBMS

Configurația standard a ambelor SGBD-uri este optimizată pentru sistemele mici, care sunt utilizate de majoritatea consumatorilor acestor SGBD-uri. Dacă comparăm performanța configurațiilor standard, diferențele sunt minime și este imposibil să identificăm un lider clar.

Caracteristicile vitezei

PostgreSQL

PostgreSQL oferă funcționalități care pot îmbunătăți performanța pentru anumite tipuri de interogări SQL. Dintre aceste funcții merită evidențiate:
— indexare parțială;
— compresia datelor;
— cantitatea de date stocată în memorie cu acces aleator;
— cache de interogări;

PostgreSQL poate comprima și decomprima datele din mers la viteze incredibile. Această funcție ar trebui utilizată în cazurile în care fiecare megaoctet contează spatiu pe disc, dar și cu utilizarea compresiei, viteza de transfer a datelor crește și ea considerabil. Această funcție vă permite să stocați date pe hard disk sub formă comprimată. Lista de funcții care afectează performanța în PostgreSQL nu se limitează la aceasta. Lista plina astfel de funcții pot fi găsite în Ghidul Administratorului PostgreSQL.

PostgreSQL acceptă un singur sistem de stocare. Este inclus în distribuția standard PostgreSQL.

MySQL:kernel

MySQL 5.1 acceptă 9 sisteme de stocare diferite:

1. MyISAM
2. InnoDB
3. Clusterul NDB
4. COMBINA
5. MEMORIE (GRAND)
6. FEDERATĂ
7. ARHIVA
8. GAURĂ NEAGRĂ

Cu toate acestea, Federated și Blackhole nu sunt servere de „stocare” de date (de exemplu, Blackhole nu stochează nimic). InnoDB este dezvoltat de o companie terță, InnoBase, care a fost fondată de Oracle. InnoDB acceptă tranzacții și este cel mai important server de stocare disponibil cu MySQL.

MySQL intenționează să introducă noi sisteme de stocare Maria și Falcon în viitoarea versiune 6.x. Aceștia au sarcina de a înlocui motoarele existente MyISAM și, respectiv, InnoDB.

Există și alte sisteme de stocare dezvoltate companii terțeși echipele de dezvoltare. Cele mai populare dintre ele:

• SolidDB
• NitroEDB
• BrightHouse

MySQL MyISAM are un cache primitiv care, înainte de a executa fiecare interogare de selecție, compară șirul de interogări cu interogările executate anterior prin comparație simplă și, dacă există o potrivire, returnează rezultatul selectat anterior. Această abordare potrivit pentru sistemele în care operațiunea copleșitoare este citirea datelor, deoarece de îndată ce oricare dintre tabele își schimbă starea (INSERT, UPDATE, DELETE), întregul cache este șters și, în consecință, avantajul de performanță este pierdut.

Cacherul de interogări rulează pe un fir separat și gestionează fiecare solicitare de preluare, astfel încât această abordare poate deveni în cele din urmă un blocaj și poate avea un impact semnificativ asupra performanța generală SGBD. Dezvoltatorii au prevăzut pentru dezactivarea acestei funcții, așa că nu este nevoie să vă faceți griji pentru acest lucru.

MySQL acceptă, de asemenea protocol de rețea compresia datelor, care este activată și dezactivată pe partea clientului (dacă serverul o permite, desigur). Această funcție comprimă toate datele care trec de la server la client.

MySQL:MyISAM

MyISAM este un sistem de stocare tradițional pentru MySQL și oferă cel mai bun echilibru de performanță și funcționalitate pentru bazele de date concepute în primul rând pentru date selectate. MySQL MyISAM procesează interogările selecte mai rapid decât PostgreSQL când vine vorba de interogări simple. MyISAM nu acceptă tranzacții sau chei străine.

MyISAM acceptă prefixele de compresie de top pentru chei și tabelele comprimate numai pentru citire.

Tabelele de sistem MySQL folosesc întotdeauna stocarea MyISAM. Acest lucru se face pentru a elimina chiar și posibilitatea potențială de pierdere a datelor.

MySQL: InnoDB

InnoDB este un sistem de stocare a datelor tranzacționale ACID complet funcțional (server) care utilizează tehnologia MVCC. Acest o alegere buna Pentru aplicatii moderne MySQL.

InnoDB stochează datele cu chei primare, astfel încât căutările cheilor primare sunt foarte rapide. Această abordare este foarte utilă pentru optimizarea fizică a bazei de date. În cazul în care nu este aplicabil și dă productivitate scăzută, atunci nu o puteți folosi în mod explicit, iar apoi sistemul va crea o cheie primară internă invizibilă de tip Integer(15) și va indexa după aceasta.

InnoDB creează automat indici hash atunci când procesează interogări SELECT. Această caracteristică poate fi dezactivată dacă este necesar. Unele procese rulează mai repede fără această caracteristică.

InnoDB are un buffer de inserare care memorează în cache actualizările la indecșii secundari și le trimite fundal. Această caracteristică îmbunătățește fundamental performanța interogărilor de inserare. Pentru a reduce numărul de apeluri către hard disk Pentru a înregistra date noi, acestea trebuie combinate în grupuri mari.

Dacă InnoDB este instalat ca un plugin pentru MySQL 5.1, acesta acceptă comprimarea tabelului din mers. Puteți utiliza atributele ROW_FORMAT=COMPRESSED sau KEY_BLOCK_SIZE în interogările CREATE TABLE și ALTER TABLE pentru a instrui InnoDB să comprima fiecare pagină în 1K, 2K, 4K, 8K sau 16K octeți.

Innobase Oy este o companie care dezvoltă InnoDB. A fost achiziționat de Oracle în octombrie 2005. De atunci, InnoDB a împrumutat din ce în ce mai mult de la Oracle DBMS. Și acum, odată cu achiziționarea MySQL de către SUN, această relație deja strânsă dintre Oracle și MySQL a devenit și mai puternică. MySQL atinge calitate înaltă nou nivel oportunități.

MySQL: Cluster NDB

NDB este un sistem de stocare de înaltă performanță situat în principal în memoria cu acces aleatoriu (RAM). Atributele neindexabile pot fi stocate pe hard disk. Datele și jurnalele sunt, de asemenea, sincronizate periodic cu hard disk-ul pentru a evita pierderea datelor în cazul unui blocaj brusc al clusterului. NDB este utilizat în principal în industria telecomunicațiilor, unde timpul de funcționare și performanța în timp real sunt critice. NDB colectează în mod transparent datele în fragmente care sunt livrate în mod regulat către toate părțile clusterului. NDB folosește replicarea sincronă internă pentru a se asigura că înregistrările sunt distribuite pe cel puțin două site-uri din cluster înainte de a fi angajate pe hard disk. NDB suportă, de asemenea recuperare automată elemente de cluster „căzute” (noduri). Din puncte slabe NDB merită remarcat faptul că are un suport foarte slab pentru interogări complexe folosind operatorii JOIN.

Pur și simplu nu există soluții similare în PostgreSQL în acest moment.

MySQL:Arhivă

MySQL a acceptat compresia on-the-fly încă din versiunea 5.0, când sistemul de stocare ARCHIVE a fost inclus în distribuție. Arhiva este un sistem de stocare care vă permite să faceți o singură scriere și multe citiri simultan. Proiectat special pentru bazele de date de arhivă, unde intrările în baza de date sunt efectuate mult mai rar și în principal de către o singură sursă de date. Forța de compresie ajunge la 90%. Arhiva nu acceptă indexuri. În MySQL 5.1, Archive poate funcționa cu mai multe partiții.

MySQL: Falcon

Falcon este un sistem de stocare tranzacțional ACID care a fost dezvoltat chiar de MySQL. În prezent este la început și disponibil pentru testare în ramura MySQL 6.0 beta. Falcon acceptă compresia de date din mers. Datele stocate în tabelele Falcon sunt comprimate pe hard disk, dar sunt stocate necomprimate în RAM. Comprimarea are loc automat atunci când datele sunt sincronizate pe hard disk.

MySQL: Maria

Maria este un sistem de stocare ACID care a fost dezvoltat de Monty Widenius și echipa de dezvoltare MySQL.

Multiprocesare

Din punct de vedere istoric, MySQL a fost dezvoltat și optimizat pentru sisteme cu un singur procesor. PostgreSQL arată mult mai frumos în acest sens. Cu cât sunt mai multe nuclee în sistem, cu atât mai rapid funcționează PostgreSQL, ceea ce este dificil de spus despre MySQL.

Odată cu răspândirea sistemelor multiprocesor pe piață, MySQL și-a dedicat eforturile îmbunătățirii DBMS. Cu fiecare versiune nouă, MySQL rulează din ce în ce mai rapid pe sistemele multiprocesor. Cele mai de succes versiuni, care cresc dramatic performanța SGBD în comparație cu Versiuni anterioare de remarcat sunt 5.0.30, 5.0.54 și 5.0.58. Acest fapt este confirmat de multe teste efectuate.

I/O asincron

PostgreSQL acceptă pe deplin API-ul asincron pentru utilizare în aplicații client. Această caracteristică vă permite să creșteți productivitatea în unele cazuri cu până la 40%. MySQL nu acceptă modul asincron. Dar există mai multe drivere care oferă această caracteristică. De exemplu, driverele MySQL pentru perl și ruby.

NUMARA(*)

SGBD-urile cu versiuni tranzacționale care sunt construite pe modelul MVCC, cum ar fi PostgreSQL și InnoDB, efectuează COUNT(*) foarte lent în comparație cu sistemele de stocare netranzacționale sau cu sistemele de stocare tranzacționale fără versiune, cum ar fi MyISAM. MyISAM în MySQL utilizează scanări de index pentru a procesa COUNT (*) și, de asemenea, memorează în cache rezultatul, această abordare este mult mai eficientă. PostgreSQL și InnoDB necesită scanare completă tabele pentru a se asigura că toate câmpurile vizibile sunt luate în considerare. Sistemele de stocare compatibile cu MVCC efectuează operațiunea COUNT(*) în acest mod deoarece MVCC stochează informații despre vizibilitatea sau non-vizibilitatea unei tranzacții în datele înregistrării în sine (ROW). În toate sistemele de stocare compatibile cu MVCC, memorarea în cache a rezultatelor operației COUNT(*) va duce la returnarea datelor incorecte. PostgreSQL Count() este mai lent decât COUNT(*) în InnoDB.

Teste de performanță

Toate testele de performanță DBMS depind direct de mediul și scopul utilizării. Fiecare SGBD poate fi configurat pentru performanțe optime pentru fiecare caz în parte. Prin urmare, nu va fi corect să comparați mostre simple sau complexe din baza de date. Sau inserții. Pentru a determina cel mai rapid SGBD, comparațiile trebuie făcute în condițiile cerute pe hardware-ul necesar și cu datele necesare.

Modelul ACID

ACID trebuie înțeles ca atomicitate, consistență, izolare și durabilitate. Acest model este utilizat pentru a asigura integritatea datelor folosind instrumente DBMS. Multe SGBD-uri realizează convențiile ACID prin utilizarea tranzacțiilor.

PostgreSQL și MySQL care utilizează sistemele de stocare InnoDB, Cluster și Falcon respectă pe deplin toate principiile și canoanele modelului ACID.
Posibilitati

PostgreSQL și MySQL au ambele un set impresionant de caracteristici și funcționalități care asigură integritatea datelor, funcționalitatea și performanța. Caracteristicile incluse cu PostgreSQL și MySQL pot îmbunătăți performanța, ușurința în utilizare, funcționalitatea sau stabilitatea.

Ușurință în utilizare

Gotcha este o funcție sau funcții care funcționează așa cum este descris, dar nu așa cum era de așteptat (http://sql-info.de/mysql/gotchas.html). Fanii PostgreSQL insistă că MySQL are mai multe caracteristici decât PostgreSQL.

În versiunile recente, MySQL a introdus utilizatorilor diferite moduri de operare SQL, care sunt compatibile cu diverse standarde SQL și fac MySQL ușor de înțeles pentru cei care nu au lucrat niciodată cu MySQL.

Inserați Ignorare / Înlocuire

MySQL acceptă instrucțiunile „INSERT IGNORE” și „REPLACE” care inserează o înregistrare dacă aceasta nu există și nu fac nimic altfel sau înlocuiește înregistrarea curentă.

PostgreSQL nu acceptă niciunul dintre cele de mai sus și recomandă utilizarea procedurilor stocate pentru a obține acest efect. Cu toate acestea, există un „DAR”. O singură valoare poate fi introdusă la un moment dat. Această condiție impune limitări serioase ale performanței și provoacă anumite dificultăți. Mânerul INSERT IGNORE și REPLACE inserarea mai multor valori și scrierea lor este mai plăcută decât o procedură.

Inca singur post utilîn MySQL: INSERT ... ON DUPLICATE UPDATE este, de asemenea, complet absent în PostgreSQL și pentru a o implementa singur necesită scrierea de proceduri stocate care pot procesa doar 1 înregistrare la un moment dat.

Limitatoare

Atât PostgreSQL, cât și MySQL acceptă delimitatorii Not-Null, Unique, Primary Key și Foreign Key. Cu toate acestea, MySQL nu acceptă constrângerea Check atunci când PostgreSQL a suportat-o ​​de ceva timp.

Tabelele InnoDB acceptă verificări ale cheilor externe. Pentru alte sisteme de stocare, MySQL analizează și ignoră FOREIGN KEY și REFERENCES din directiva CREATE TABLE.

Pentru motoarele MySQL care nu acceptă chei străine, pot fi utilizați declanșatori.

Valori implicite

PostgreSQL permite coloanelor să utilizeze orice funcție marcată IMMUTABLE sau STABLE ca valoare implicită. În MySQL, în acest moment, numai funcția Now() poate fi folosită ca valoare implicită pentru o coloană.

Proceduri stocate

Atât PostgreSQL, cât și MySQL acceptă proceduri stocate.

Principalul limbaj de interogare din PostgreSQL este PL/pgSQL, care este similar cu PL/SQL din Oracle. PostgreSQL acceptă, de asemenea, procedurile stocate SQL:2003 PSM, precum și alte limbaje de programare populare Perl (PL/Perl), Python (PL/Python), TCL (PL/Tcl), Java (PL/Java) și chiar C (PL). /C).

Urmează MySQL Sintaxa SQL:2003 pentru procedurile stocate, care este folosit și în IBM DB2.

MySQL acceptă alte limbaje de programare cu proceduri stocate prin pluginuri. Cele mai populare sunt Java, Perl, XML-RPC.

Declanșatoare

Atât PostgreSQL, cât și MySQL acceptă declanșatoare. Declanșatoarele din PostgreSQL pot executa oricare funcții personalizate din orice limbaj procedural.

Declanșatoarele din MySQL activează doar interogări SQL. Ele nu sunt declanșate de modificările de tabel făcute folosind API-ul MySQL și nu execută nicio interogare SQL.

PostgreSQL acceptă, de asemenea, reguli (RULES), care vă permit să operați pe sintaxa interogării și pot face unele operații mai ușoare decât mecanismul tradițional de declanșare.

Sintaxa pentru definirea declanșatorilor în PostgreSQL nu este la fel de puternică ca în MySQL. PostgreSQL necesită o definiție separată a funcției cu un tip de returnare special.

Replicare și disponibilitate ridicată

Replicarea este un mecanism prin care un DBMS își dublează datele pentru copii de siguranță și, de asemenea, pentru oglindirea către alte servere pentru a asigura o stabilitate ridicată. PostgreSQL și MySQL acceptă ambele replicare:

PostgreSQL

PostgreSQL acceptă replicarea plug-in-urilor. Există mai multe module care vă permit să replicați datele DBMS PostgreSQL:
-PGCluster
—Slony-I
— DBBalancer
-pgpool
— Comparator de tabel PostgreSQL
- SkyTools
— Sequoia
— Bucardo
— Mamut Replicator
— Cubercluster
- GridSQL (shared-nimic)

Există o concepție greșită că aceste module de la terți nu se integrează cumva bine și nu își fac treaba în mod corespunzător. De exemplu, Slony a fost proiectat și dezvoltat de Jan Weick, membru al echipei de dezvoltare PostgreSQL, cu contribuții din partea multor oameni din comunitatea PostgreSQL. Cu toate acestea, Slony este mult mai lent și utilizează mai multe resurse decât replicatorul încorporat în MySQL. Dar în PostgreSQL 8.4, a fost lansat un replicator încorporat.

Punctele slabe ale replicării în PostgreSQL

Slony-I este instrumentul cel mai utilizat pentru replicarea datelor în PostgreSQL și este direct opusul mecanismului de replicare a datelor încorporat în MySQL. În primul rând, folosește SQL și declanșatoare pentru a colecta date pentru replicare pe întregul server. Această abordare este fundamental mai lentă decât metoda nativă de replicare a datelor în MySQL, care utilizează modul binar de procesare a bazei de date. În al doilea rând, Slony-I nu este potrivit pentru utilizare în clustere uriașe, deoarece consumul de resurse este egal cu pătratul serverelor utilizate pentru replicarea datelor.

2 servere: MySQL: 2 = 2 PostgreSQL: 2*2^2 = 8
4 servere: MySQL: 4 = 4 PostgreSQL: 2*4^2 = 32
12 servere: MySQL: 12 = 12 PostgreSQL: 2*12^2 = 288.

În timp ce Slony-I este adecvat pentru Valabilitate ridicată folosind două servere. Slony-I este foarte greu de administrat.

Bucardo este scris în Perl și folosește intens declanșatoarele PL/PGSQL și PL/PERLU.

PGCluster nu este util acolo unde sunt așteptate performanțe ridicate și un număr mare de surse de date, deoarece PGCluster implementează replicarea sincronă care așteaptă ca scrierile să apară pe toate mașinile care participă la cluster. Cu toate acestea, în situațiile în care numărul de surse de date este minim și este necesar ca datele să fie întotdeauna identice pe toate mașinile din cluster, PGCluster va fi un instrument bun.

MySQL

MySQL vine cu suport pentru replicarea asincronă a datelor. Începând cu versiunea 5.1, MySQL acceptă două formate de replicare. Piese SBR interogări SQL, care fac modificări în baza de date, într-un fișier jurnal binar special la care sunt abonați toate serverele copil. În consecință, atunci când apar modificări în baza de date principală, toate celelalte baze de date primesc copii ale datelor. RBR urmărește modificările incrementale ale înregistrărilor și le scrie într-un fișier jurnal binar din care toate bazele de date copil primesc date. RBR este utilizat automat atunci când o anumită interogare este executată în baza de date principală. Unele sisteme de stocare precum NDB, Falcon și, în unele cazuri, InnoDB folosesc doar RBR pentru replicare.

Începând cu versiunea 6.0, MySQL acceptă replicarea semi-sincronă în care masterul confirmă primirea a cel puțin o bază de date copil înainte de a reveni din procedura de confirmare a datelor. Această metodă vă permite să minimizați pierderea de date, în special în clustere mari.

Tipuri de date

PostgreSQL nu acceptă numere întregi nesemnate, dar are suport mai larg pentru tipurile de date în aspectele conformității cu standardele, tipul boolean de bază, definirea tipurilor de date definite de utilizator, tipurile de date încorporate.

PostgreSQL permite definirea coloanelor de tabel ca o matrice multidimensională, cu lungime variabilă. Matricele pot fi orice tip încorporat sau personalizat, enumerare sau tip compozit. Dar matricele de domenii nu sunt încă acceptate.

MySQL nu are tipul de date IP Address care este prezent în PostgreSQL, dar funcțiile INET_ATON() și INET_NTOA() sunt folosite pentru a converti de la și la IPV4. Stocat în baza de date ca întreg.

Subinterogări

MySQL și PostgreSQL acceptă subinterogări. Subinterogările au apărut recent în MySQL și necesită îmbunătățiri semnificative în ceea ce privește performanța. În PostgreSQL, subinterogările au fost aduse aproape de perfecțiune.

Indexare avansată

Indexarea avansată permite SGBD-ului să efectueze interogări cu mult mai multe de mare viteză. Atât MySQL, cât și PostgreSQL acceptă indexarea avansată.

Indici multipli.

MySQL acceptă mai mulți indecși pe tabel și poate folosi un index pe tabel. PostgreSQL acceptă mai mulți indecși pe bază de interogare.

Indexuri de text complet.

MySQL vine cu suport pentru căutarea full-text, dar căutarea poate fi utilizată numai pe sistemele de stocare MyISAM. MySQL acceptă, de asemenea module externe pentru organizarea căutării full-text - Sphinx Fulltext Search Engine. Acest plugin adaugă suport pentru căutarea full-text pentru sistemele de stocare InnoDB.

PostgreSQL începând cu versiunea 8.2 are căutare full-text în modulul tsearch2. Începând cu versiunea 8.3, modulul tsearch2 a fost integrat în nucleul PostgreSQL.

Indexare parțială

MySQL nu acceptă indexarea parțială. PostgreSQL acceptă indexarea parțială. Un index parțial este un index construit pe o porțiune de tabel. O felie este definită de o expresie specială numită predicat index parțial. Indexul conține intrări care satisfac predicatul. Indicii parțiali sunt un lucru destul de specializat, dar există situații în care indicii parțiali pot fi foarte folositori.

Unul dintre cele mai importante aspecte Utilizarea indexurilor parțiale înseamnă a evita indexarea valorilor duplicate. Atunci când o interogare caută valori duplicate care nu sunt mai mult de câteva procente din întregul tabel, indecșii nu sunt utilizați. Deci nu este nevoie să stocați aceste date într-un index. Această abordare reduce dimensiunea indexului și crește viteza de procesare a interogărilor. De asemenea, crește viteza de efectuare a altor operațiuni pe tabele, cum ar fi viteza de actualizare a înregistrărilor.

Porționare

MySQL acceptă mai multe forme de porțiune orizontală:
- GAMĂ
- LISTA
- HASH
-CHEIE
— Porționare compozită folosind RANGE sau LIST cu HASH sau KEY

PostgreSQL acceptă doar RANGE și LIST. Porționarea HASH este acceptată folosind funcții externe. PostgreSQL acceptă și soluții compozite.

Licențiere

PostgreSQL este distribuit sub licența BSD, care include clauzele Free Software Definition și Open Source Definition și standardul Copyfree.

MySQL este disponibil sub licența publică generală GNU, care include și clauzele Free Software Definition și Open Source Definition, dar nu și standardul Copyfree. Aceasta înseamnă că, dacă este publicat un produs care utilizează codul sursă MySQL, va trebui fie să plătiți pentru o copie comercială a MySQL AB, fie să deschideți codul sursă pentru uz public.

Dezvoltare

MySQL este deținut și sponsorizat de o companie principală, MySQL AB. Adevărat, acum face parte din Sun Microsystems, care la rândul său a fost achiziționat de Oracle. MySQL AB deține drepturile de autor și sursele MySQL.

PostgreSQL nu este deținut sau întreținut de nicio companie comunitate globală dezvoltatorii, precum și companiile care participă la dezvoltare. PostgreSQL are sponsori corporativi care oferă bani pentru dezvoltare.

MySQL este un PRODUS open source cod sursa.
PostgreSQL este un proiect open source.

originea numelui

Când a fost creat standardul ANSI SQL, autorul său a spus că SQL a fost pronunțat oficial „ess queue ell”. Atât MySQL, cât și PostgreSQL reflectă acest standard în numele lor. MySQL este pronunțat oficial „my ess queue ell”. Cu toate acestea, mulți oameni pronunță MySQL drept „sequelul meu”.

Deoarece MySQL este proprietatea MySQL AB, compania a fost forțată să păstreze drepturile de autor în numele creației sale și, prin urmare, numele va rămâne cel mai probabil neschimbat.

PostgreSQL se pronunță „post gres ku ell”. Numele este format din vechiul nume Postgres (acesta era numele SGBD-ului pe baza căruia a fost creat PostgreSQL) și SQL. Unii oameni se referă la Postgresqual ca pidgysqual (pgsql). Există zvonuri că PostgreSQL va fi redenumit în Postgres. În prezent există o dezbatere activă pe această temă.

Popularitate

MySQL este cunoscut și utilizat pe scară largă în majoritatea dezvoltărilor open-source din întreaga lume. Cel mai des folosit sistem de stocare este MyISAM. Și putem spune cu încredere că MySQL este cel mai popular SGBD pentru dezvoltarea web din întreaga lume.

Motivul pentru această popularitate este că MySQL este mai ușor de utilizat decât alte SGBD-uri, în special PostgreSQL. Această declarație există de mulți ani. Dar, de fapt, în urmă cu câțiva ani, PostgreSQL a făcut modificări majore în structura sa și poate fi considerat pe drept mai ușor de utilizat decât MySQL. Dar întrebarea este încă deschisă. Ce sa aleg? MySQL sau PostgreSQL?

Versiunea articolului

Comparația de mai jos a fost făcută în MySQL AB. Am încercat să fiu cât mai precis și obiectiv, totuși, cunoscând MySQL, nu m-am putut lăuda cu aceleași cunoștințe despre capabilitățile PostgreSQL, așa că aș fi putut greși în anumite privințe.

În primul rând, aș dori să observ că PostgreSQL și MySQL sunt produse software utilizate pe scară largă care au fost dezvoltate în scopuri diferite (deși creatorii ambelor se străduiesc să le facă pe deplin compatibile cu standardul ANSI SQL). Aceasta înseamnă că MySQL este mai potrivit pentru rezolvarea unor probleme, în timp ce PostgreSQL este mai potrivit pentru altele. Atunci când alegeți un SGBD, verificați dacă capabilitățile acestuia îndeplinesc cerințele problemei care se rezolvă. Dacă este necesară viteza maximă, probabil cel mai bine este să optați pentru Ale mele SQL Server. Dacă aveți nevoie caracteristici suplimentare, disponibil numai în PostgreSQL, acest DBMS merită folosit.

O diferență semnificativă între MySQL și PostgreSQL este că aproape tot codul conținut în MySQL a fost creat de dezvoltatori care lucrează la MySQL AB și sunt ocupați în mod constant să îmbunătățească codul serverului. Excepția de la această regulă sunt sistemele de tranzacții și biblioteca de expresii regulate regexp.

Majoritatea codului PostgreSQL este scris de mulți dezvoltatori care nu au nicio legătură între ei. Nu cu mult timp în urmă, dezvoltatorii PostgreSQL au anunțat că echipa lor a avut în sfârșit suficient timp pentru a revizui tot codul inclus în următoarea versiune de PostgreSQL.

Comparație dintre caracteristicile MySQL și PostgreSQL

MySQL are următoarele avantaje față de PostgreSQL:

· MySQL este de obicei mult mai rapid decât PostgreSQL. În plus, MySQL 4.0 implementează un cache de interogări. Vă permite să creșteți viteza de procesare a cererilor de mai multe ori pentru site-urile care sunt dominate de solicitări de citire repetate.

· MySQL este, de asemenea, cu mult superior PostgreSQL în ceea ce privește numărul de utilizatori. Prin urmare, codul este testat mult mai meticulos, iar fiabilitatea sa s-a dovedit experimental a fi mai mare decât cea a PostgreSQL. MySQL este folosit mai des decât PostgreSQL în producție, în principal pentru că MySQL AB (fostul TCX DataKonsult AB) a oferit suport tehnic comercial de înaltă calitate pentru MySQL de la introducerea sa pe piață, în timp ce PostgreSQL nu a avut suport până de curând.

· MySQL rulează în mediu Windows este mai bun decât PostgreSQL. MySQL Server rulează ca o aplicație Windows reală (nativă) (un serviciu pe NT/2000/XP), în timp ce PostgreSQL rulează în mediul de emulare, Cygwin. Am auzit despre lipsa de stabilitate a PostgreSQL în mediul Windows, dar încă nu am putut verifica singur aceste informații.

Echipat MySQL o cantitate mare API pentru alte limbi și este susținut de mai multe programe existente decât PostgreSQL.

· MySQL rulează pe sisteme industriale foarte fiabile 24/7 (24 de ore pe zi, 7 zile pe săptămână). În cele mai multe cazuri, nu sunt necesare curățări în MySQL. PostgreSQL nu poate funcționa încă în astfel de sisteme, deoarece uneori trebuie să rulați VACUUM pentru a elibera spațiul ocupat de consecințele comenzilor UPDATE și DELETE și să efectuați analize statistice, necesar pentru a obține performanța PostgreSQL maximă. De asemenea, este necesar să rulați VACUUM după fiecare adăugare a mai multor coloane la tabel. Pe sistemele ocupate, VACUUM trebuie să fie rulat mai frecvent, în cele mai rele cazuri de mai multe ori pe zi. Dar în timp ce VACUUM rulează (și activitatea sa poate dura ore întregi dacă baza de date este suficient de mare), baza de date este practic „moartă”. Cu toate acestea, în versiunea PostgreSQL 7.2, îndeplinirea funcțiilor de bază ale acestui program nu mai duce la blocarea bazei de date, iar utilizatorii pot continua să lucreze cu ea în mod normal. Echipa noua VACUUM FULL ia lucrurile mai în serios: acesta, ca în versiunile mai vechi, blochează tabelul și comprimă o copie a tabelului de pe disc.

· Există mult mai multe cărți despre MySQL decât despre PostgreSQL. Cărți despre MySQL au fost publicate de O"Reilly, SAMS, Que și New Riders. Toate caracteristicile MySQL sunt descrise în detaliu în documentație, deoarece aceasta este o condiție prealabilă pentru includerea de noi funcții în cod.

· MySQL are o implementare ALTER TABLE mult mai puternică.

· MySQL oferă posibilitatea de a crea tabele fără tranzacții, ceea ce este necesar pentru aplicațiile care necesită cea mai mare viteză posibilă.

· MySQL poate lucra cu două motoare de tabele conștiente de tranzacții, și anume InnoDB și BerkeleyDB. Deoarece toate sistemele de suport pentru tranzacții funcționează diferit în condiții diferite, acest lucru oferă dezvoltatorului posibilitatea de a găsi cea mai bună soluție pentru condițiile în care sistemul său va funcționa. Vezi secțiunea 7 Tipuri de tabele MySQL.

· Comanda de îmbinare a tabelului MERGE vă pune la dispoziție oportunitate unică creați o vedere a mai multor tabele identice și lucrați cu ele ca unul singur. Acest lucru este deosebit de convenabil pentru lucrul cu jurnalele împărțite, de exemplu, pe lună.

· Capacitatea de a comprima tabele doar pentru citire fără a elimina accesul direct la înregistrările acestora îmbunătățește performanța sistemului prin reducerea numărului de citiri de disc. Acest lucru este util în special pentru arhivare.

· MySQL implementează căutarea full-text.

· Este posibil să lucrați cu mai multe baze de date printr-o singură conexiune (desigur, în funcție de privilegiile utilizatorului).

· MySQL a fost conceput de la început pentru a fi multi-threaded, în timp ce PostgreSQL utilizează procese. Schimbarea contextelor și accesarea datelor partajate prin mai multe fire este mult mai rapidă decât prin procese separate. Acest lucru oferă MySQL Server un avantaj de performanță în aplicațiile multi-utilizator și, de asemenea, permite serverului MySQL să profite de sistemele cu multiprocesor simetric (SMP) mult mai eficient.

· MySQL a implementat mult mai mult sistem puternic privilegii decât în ​​PostgreSQL. În timp ce PostgreSQL oferă numai privilegii INSERT, SELECT și UPDATE/DELETE asupra unei baze de date sau a unui tabel, MySQL oferă posibilitatea de a defini Set complet diverse privilegii la nivel de bază de date, tabel și coloană. În plus, MySQL vă permite să setați privilegii pentru combinațiile gazdă/utilizator.

· MySQL folosește un protocol de comunicare între client și server cu compresie de date, ceea ce mărește performanța sistemului în condițiile canalelor de comunicare cu viteză redusă.

· Toate tipurile de tabele din MySQL (cu excepția InnoDB) sunt implementate ca fișiere (un tabel pe fișier), ceea ce face mult mai ușoară crearea de copii de rezervă, mutarea, ștergerea și chiar crearea de legături simbolice între baze de date și tabele, chiar dacă serverul este jos .

· Actualizarea MySQL este complet nedureroasă. Când actualizați MySQL, nu este nevoie să copiați/restaurați datele, ceea ce este necesar să faceți atunci când instalați majoritatea actualizărilor PostgreSQL.

Mai jos sunt avantajele PostgreSQL față de MySQL astăzi.

Alte motive pentru a alege PostgreSQL:

· În unele cazuri, PostgreSQL este mai aproape de ANSI SQL.

· PostgreSQL poate fi accelerat prin executarea codului ca proceduri stocate.

· Arborii R oferă PostgreSQL un avantaj față de MySQL atunci când stochează date geografice (notă: MySQL versiunea 4.1 a introdus suport pentru arborele R pentru tabelele MyISAM).

· Echipa de dezvoltatori PostgreSQL care scriu cod pentru server este mai mare.

Dezavantajele PostgreSQL în comparație cu MySQL:

· VACUUM face PostgreSQL dificil de utilizat pe sistemele mereu pornite.

· Disponibilitatea numai a tabelelor tranzacționale.

· Funcționare semnificativ mai lentă a comenzilor INSERT, DELETE și UPDATE.

Concluzie

Singurele benchmark-uri disponibile astăzi care compară MySQL Server și PostgreSQL pe care oricine le poate descărca și rula sunt benchmark-urile din suita MySQL. Și de aceea aleg MySQL

Din cauza devalorizării rapide a rublei, cumpărarea unui SGBD Microsoft SQL a devenit foarte costisitoare, iar pentru unele companii costul acestor licențe a devenit complet inaccesibil. În prezent, pentru a implementa un server Microsoft SQL pentru 20 de utilizatori, trebuie să achiziționați următoarele licențe:

1 licență de sistem de operare (WinSvrStd 2012R2)

20 de licențe pentru conectarea la server (WinSvrCAL 2012)

1 licență pentru server DBMS (SQLSvrStd 2014)

20 de licențe pentru conectarea la DBMS (SQLCAL 2014)

Costul estimativ al unui astfel de pachet 275.000 de ruble, ceea ce este destul de scump pentru o companie cu doar 20 de oameni. Aceste costuri pot fi evitate dacă creați un server DBMS folosind software gratuit. Instalați un sistem de operare Linux și o versiune gratuită a DBMS - PostgreSQL. Pe un astfel de server, puteți implementa cu ușurință un server enterprise 1C, precum și alte roluri care pot fi combinate cu rolul bazelor de date, de exemplu WebServer sau stocare de fișiere.

Deoarece utilizarea software-ului gratuit este foarte atractivă punct financiar Având în vedere acest lucru, s-a decis să se verifice cât de bun este din punct de vedere al performanței.

Testarea performanței 1C:

Pentru efectuarea testului au fost luate echipamentele și software-ul enumerate în Tabelul 1. Server fizic Același a fost folosit pentru ambele standuri, doar software-ul a fost schimbat. Setările ambelor SGBD au fost folosite implicit și nu le descriem în detaliu în articol. Kitul de distribuție PostGreSQL cu patch-urile corespunzătoare a fost preluat de pe site-ul companiei 1C, versiunea este cea mai recentă disponibilă pe acest site.

Tabelul 1. Bancuri de încercare

Pentru început, a fost efectuat „testul Gilev”, care a arătat un ușor avantaj al standului numărul 2 față de un stand cu software liber.

Vedeți rezultatele de mai jos, diferența de valori este doar 3%.

Pentru informații:„Testul Gilev” este un test 1C sintetic popular care efectuează o serie operațiuni standard– cu cât testul este finalizat mai repede, cu atât scorul este mai mare. Evaluarea se realizează în unități convenționale. Scorul rezultat poate fi comparat cu scala atașată testului, care va arăta cât de mare este performanța sistemului actual.

Figura 1. Rezultatul testului Gilev. Stand nr. 2 DBMSDOMNIȘOARĂ SQL

Figura 2. Rezultatul testului Gilev. Stand nr. 1 DBMSPostgreSQL

În continuare, s-a decis să se efectueze testarea folosind metoda APDEX. Esența metodei este de a măsura timpul necesar pentru a efectua operațiuni de bază în 1C măsurătorile sunt efectuate de mai multe ori pe o anumită perioadă de timp; Apoi, rezultatul obținut este comparat cu timpul acceptabil pentru a finaliza o anumită operație.

Pentru a face acest lucru, am luat o bază de lucru reală a uneia dintre cele mai grele configurații 1C, caracteristicile bazei sunt indicate în tabelul nr.

Tabelul 2. Caracteristicile bazei de testare

A fost măsurat timpul necesar pentru a efectua 7 operații standard cu obiecte din baza de date. Fiecare test a fost efectuat de 10 ori și s-a obținut media. Măsurătorile au fost efectuate folosind un client gros via retea locala. Clientul a fost instalat pe stație de lucru sub Control Windows 7. Am încercat să rulăm teste și de la un client instalat pe Ubuntu Linux, dar nu a funcționat stabil și s-a decis să rulăm toate testele doar de la un client pe Windows.

Tabelul 3. RezultateAPDEX

În medie, baza noastră de date reală atunci când utilizați MSSQL a funcționat cu 45% mai rapid decât pe o bancă cu software gratuit. La unele teste, decalajul a fost foarte semnificativ, dar la altele, de exemplu, realizarea unui nou document a fost de doar 11%.

Concluzie:

1C pe MSSQL DBMS funcționează de aproximativ 1,5 ori mai rapid decât pe PostgreSQL. În consecință, dacă este posibil să cumpărați sau să închiriați licențe MSSQL, este mai bine să le utilizați pentru performanțe mai mari. Pentru bazele de date mici și ușoare, puteți încerca să utilizați versiunea MSSQL Express. Nu am efectuat teste cu acesta, așa că se poate arăta în ceea ce privește performanța fie mai bine, fie mai rău decât PostgreSQL. Această ediție este limitată la utilizarea a 1 procesor și 1 GB de RAM și, de asemenea, nu funcționează cu baze de date mai mari de 10 GB. Dacă baza de date crește la această dimensiune, atunci va înceta să funcționeze complet, dar după cum arată practica, dacă există 15-20 de utilizatori în baza de date, atunci puteți lucra confortabil cu o dimensiune a bazei de date de 4-5 GB, atunci baza de date începe să încetini foarte mult.

Evaluarea prin testul Gilev arată o superioritate extrem de ușoară a MSSQL, ceea ce ne permite să presupunem că alte baze de date 1C pot funcționa pe PostgreSQL la fel de bine ca și pe MSSQL și, eventual, mai rapid. Înainte de a alege un SGBD, vă recomandăm să efectuați teste pe baza de date specifică și să comparați rezultatele.

Utilizarea DBMS PostgreSQL pentru a implementa 1C pe acesta este solutie acceptabilaîn condiţii de buget limitat. Baza de date nu va funcționa la fel de repede ca pe MSSQL, dar nu trebuie să plătiți pentru licențe.

La sfârșitul anului 2017, am efectuat noi teste și le-am publicat într-un alt articol.

O altă modalitate de a economisi bani atunci când utilizați 1C este să închiriați un server 1C.

Integrarea sistemului. Consultanta

Bazele de date relaționale au fost folosite de mult timp. Au devenit populare datorită sistemelor de management care implementează atât de bine modelul relațional încât este în cel mai bun mod posibil lucrul cu date, în special pentru aplicații și servicii esențiale.

MySQL există de mult timp și s-a dovedit a fi solutie perfecta, Postgresql a apărut pe piață cam în același timp, dar oferă destul de multe caracteristici interesanteși oportunități, datorită cărora câștigă rapid popularitate. În acest articol vom încerca să comparăm MySQL vs Postgresql, să comparăm principalele diferențe dintre aceste sisteme, să aflăm cum funcționează și să încercăm să înțelegem care sistem va fi mai bun pentru proiectul tău.

Sisteme de management al bazelor de date

Bazele de date sunt concepute pentru stocare structurată și acces rapid la diverse date. Fiecare bază de date, pe lângă datele în sine, trebuie să aibă un model de operare specific conform căruia se va efectua prelucrarea datelor. Pentru gestionarea bazelor de date se folosesc DBMS sau sisteme de gestionare a bazelor de date, astfel de programe includ MySQL și Postgresql.

Sistemele de gestionare a bazelor de date relaționale vă permit să plasați date în tabele legând rânduri de la mese diferiteși astfel conectând date diferite, integrate logic. Înainte de a putea salva date, trebuie să creați tabele de o anumită dimensiune și să specificați un tip de date pentru fiecare coloană. Coloanele reprezintă câmpuri de date, iar datele în sine sunt plasate în rânduri. Ambele sisteme de gestionare a bazelor de date, MySQL vs Postgresql, sunt relaționale. În continuare, ne vom uita mai detaliat la modul în care diferă ambele programe. Acum să trecem la o considerație mai detaliată.

Poveste scurta

MySQL

Dezvoltarea MySQL a început în anii 90. Prima lansare internă a bazei de date a avut loc în 1995. În acest timp, mai multe companii dezvoltau programul. Dezvoltarea a început companie suedeză MySQL AB, care a fost achiziționat de Sun Microsystems, care a devenit de fapt proprietatea Oracle. În prezent, din 2010, Oracle îl dezvoltă.

Postgresql

Dezvoltarea Postrgresql a început în 1986 la Universitatea din California, Berkeley. Dezvoltarea a durat aproape opt ani, apoi proiectul a fost împărțit în două părți - baza de date comercială IIlustra și întregul proiect gratuit Postrgesql, care este dezvoltat de entuziaști.

Stocare a datelor

MySQL

MySQL este o bază de date relațională; sunt folosite diferite motoare pentru a stoca date în tabele, dar lucrul cu motoarele este ascuns în sistemul în sine. Motorul nu afectează sintaxa solicitărilor și execuția acestora. Principalele motoare suportate sunt MyISAM, InnoDB, MEMORY, Berkeley DB. Ele diferă în modul în care datele sunt scrise pe disc, precum și în metodele de citire a acestora.

Postgresql

Postgresql este o bază de date obiect-relațională care rulează pe un singur motor - motorul de stocare. Toate tabelele sunt reprezentate ca obiecte, pot fi moștenite, iar toate acțiunile cu tabele sunt efectuate folosind funcții orientate către obiective. Ca și în MySQL, toate datele sunt stocate pe disc, în fișiere special sortate, dar structura acestor fișiere și înregistrările din ele este foarte diferită.

Standardul SQL

Indiferent de sistemul de management al bazei de date utilizat, SQL este un limbaj de interogare standardizat. Și este susținut de toate soluțiile, chiar și de MySQL sau Postgresql. Standardul SQL a fost dezvoltat în 1986 și în acest timp au fost deja lansate mai multe versiuni.

MySQL

MySQL nu acceptă toate noile caracteristici ale standardului SQL. Dezvoltatorii au ales această cale de dezvoltare specială pentru a păstra MySQL este simplu pentru utilizare. Compania încearcă să respecte standardele, dar nu în detrimentul simplității. Dacă o anumită caracteristică poate îmbunătăți gradul de utilizare, atunci dezvoltatorii o pot implementa ca propria extensie fără a acorda atenție standardului.

Postgresql

Postgresql este un proiect open source, este dezvoltat de o echipă de entuziaști, iar dezvoltatorii încearcă să se conformeze cât mai mult posibil Standardul SQLși implementați toate cele mai recente standarde. Dar toate acestea vin în detrimentul simplității. Postgresql este foarte complex și din această cauză nu este la fel de popular ca MySQL.

Capabilitati de procesare

Alte diferențe între postgresql și mysql reiese din paragraful anterior: capacități și limitări de procesare a datelor. Desigur, respectarea standardelor mai noi aduce capabilități mai noi.

MySQL

Când o solicitare este executată, MySQL încarcă întregul răspuns al serverului în memoria clientului, când volume mari date, acest lucru poate să nu fie complet convenabil. Practic, Postgresql este superior Mysql în ceea ce privește funcțiile, ne vom uita în continuare.

Postgresql

Postgresql acceptă utilizarea cursoarelor pentru a naviga prin datele primite. Primiți doar un pointer; întregul răspuns este stocat în memoria serverului de baze de date. Acest indicator poate fi salvat între sesiuni. Acceptă construirea de indici pentru mai multe coloane de tabel simultan. În plus, indecșii pot fi de diferite tipuri, pe lângă hash și b-tree, GiST și SP-GiST sunt disponibile pentru lucrul cu orașe, GIN pentru căutare de text, BRIN și Bloom.

Postgresql acceptă expresii obisnuiteîn interogări, interogări recursive și moștenire de tabel. Dar există mai multe restricții, de exemplu, puteți adăuga un câmp nou doar la sfârșitul tabelului.

Performanţă

Bazele de date trebuie să fie optimizate pentru mediul în care veți lucra. Din punct de vedere istoric, MySQL s-a concentrat pe performanță maximă, iar Postgresql a fost dezvoltat ca o bază de date cu un număr mare de setări și pe cât posibil conformă cu standardul. Dar de-a lungul timpului, Postgresql a primit multe îmbunătățiri și optimizări.

MySQL

În cele mai multe cazuri, un tabel InnoDB este folosit pentru a organiza munca cu o bază de date în MySQL, acest tabel este un arbore B cu indici; Indexurile vă permit să preluați datele de pe disc foarte rapid și necesită mai puține operațiuni pe disc. Dar scanarea unui arbore necesită găsirea a doi indici, iar acest lucru este deja lent. Toate acestea înseamnă că MySQL va fi mai rapid decât Postgresql numai atunci când se utilizează o cheie primară.

Postgresql

Toate informațiile de antet ale tabelelor Postgresql se află în RAM. Nu puteți crea un tabel care nu are memorie. Intrările din tabel sunt sortate după index, astfel încât să le puteți recupera foarte rapid. Pentru o mai mare comoditate, puteți aplica mai mulți indecși la un singur tabel.

În general, PostgreSQL este mai rapid, cu excepția utilizării cheilor primare. Să ne uităm la câteva teste cu diferite operații:

Tipuri de date

Unul dintre punctele importante ale ambelor baze de date este tipurile de date acceptate pe care le puteți utiliza. Deoarece ambele soluții încearcă să se potrivească cu sintaxa SQL, ele au seturi similare, dar diferă în anumite privințe.

MySQL

MySQL acceptă următoarele tipuri de date:

• TINYINT: întreg foarte mic.;
• SMALLINT:întreg mic;
• MEDIUM:întreg de mărime medie;
• INT:întregul este de dimensiune normală;
• BIGINT:întreg mare;
• PLUTI: număr în virgulă mobilă cu precizie unică semnat;
• DUBLĂ, DUBĂ PRECIZIE, REAL: număr semnat în virgulă mobilă dublă precizie
• DECIMAL, NUMERIC: număr semnat în virgulă mobilă;
• DATA: data de;
  DATETIME: combinație de dată și oră;
• TIMESTAMP-UL: timestamp-ul;
• TIMP: timp;
  AN: an în format YY sau YYYY;
• CHAR: șir de dimensiune fixă, căptușit la dreapta cu spații până la lungimea maximă;
• VARCHAR:șir de lungime variabilă;
• TINYBLOB, TINYTEXT: date binare sau text cu o lungime maximă de 255 de caractere;
• BLOB, TEXT: date binare sau text cu o lungime maximă de 65535 caractere;
• MEDIUMBLOB, MEDIUMTEXT: text sau date binare;
• LONGBLOB, LONGTEXT: text sau date binare maximum 4294967295 caractere;
• ENUM: enumerare;
• A STABILIT: mulţimi.

Postgresql

Tipurile de câmp acceptate în Postgresql sunt destul de diferite, dar vă permit să înregistrați exact aceleași date:

• bigint:întreg semnat de 8 octeți;
• serial mare: număr întreg de 8 octeți cu incrementare automată;
• pic:șir binar de lungime fixă;
• putin variat:șir binar de lungime variabilă;
• boolean: steag;
• cutie: dreptunghi pe un plan;
• octet: date binare;
• caracter variabil:șir de caractere cu lungime fixă;
• caracter:
• cidr: adresa de rețea IPv4 sau IPv6;
• cerc: cerc pe un plan;
• Data: data calendaristică;
• precizie dubla: număr în virgulă mobilă de precizie dublă;
• inet: adresa de internet IPv4 sau IPv6;
• întreg: întreg semnat de 4 octeți;
• interval: perioadă;
• linia: o linie dreaptă infinită pe un plan;
• lseg: un segment pe un plan;
• macaddr: Adresa mac;
• bani: valoare monetară;
• cale: cale geometrică pe un plan;
• punct: punct geometric pe un plan;
• poligon: poligon pe un plan;
• real: număr unic cu virgulă mobilă de precizie;
• smallint: număr întreg de doi octeți;
• serial: număr întreg de patru biți incrementat automat;
• text:șir de caractere cu lungime variabilă;
• timp: Partea zilei;
• timestamp-ul: data si ora;
• tsquery: interogare de căutare text;
• tsvector: document de căutare text;
• uuid: identificator unic;
• xml: date XML.

După cum puteți vedea, există mai multe tipuri de date în Postgresql și sunt mai diverse, există tipuri de câmpuri pentru anumite tipuri de date pe care MySQL nu le are. Diferența dintre MySQL și Postgresql este evidentă.

Dezvoltare

Ambele proiecte sunt open source, dar sunt dezvoltate diferit. Nu tuturor le place dezvoltarea MySQL. Și aici este cazul în care o comparație între mysql și postgresql oferă multe diferențe.

MySQL

Baza de date MySQL este dezvoltată de Oracle și există zvonuri că compania intenționează să încetinească dezvoltarea motorului. Au fost create o mulțime de fork-uri ale proiectului, inclusiv un fork al MariaDB de la dezvoltatorul MySQL original. Dar totusi dezvoltarea ramane lenta.

Postgresql

După cum sa menționat la începutul articolului, dezvoltarea a început la Universitatea din Berkeley. Apoi s-a mutat la o companie comercială. Programul este în prezent în curs de dezvoltare grup independent programatori și consiliul de administrație al mai multor companii. Noile versiuni sunt lansate destul de activ și primesc din ce în ce mai multe funcții noi.

Nu este de mirare că MySQL este foarte popular în lume baze de date relaționale date. Acesta este un RDBMS open source bun, decent. Dar nu singurul de acest fel. PostgreSQL nu este mai rău decât MySQL și, în multe privințe, chiar mai bine. Să încercăm să aflăm despre ce este vorba mai exact.

Aș dori să subliniez imediat că În ultima vreme Nu am lucrat prea mult cu MySQL, așa că unele dintre cunoștințele mele despre acesta ar putea fi depășite. De asemenea, sunt departe de a fi un guru PostgreSQL, dar complet utilizator obișnuit acest SGBD. Dacă mai departe în text mint despre ceva, vă rog să nu ezitați să îl raportați în comentarii.

În PostgreSQL puteți folosi cursore. Imaginați-vă că o interogare returnează un gigaoctet de date. Sunteți forțat să transferați întreg acest gigabyte prin rețea (dacă DBMS rulează pe un server separat) și să îl stocați în memorie înainte de a face ceva cu el. Chiar dacă driverul pe care îl utilizați acceptă funcții precum fetch_next_row, de fapt încă pune în memorie întregul rezultat al interogării. Cu ajutorul cursoarelor, puteți nu numai să luați date în bucăți, procesându-le astfel într-o cantitate constantă de memorie, ci și să vă deplasați liber prin ele în direcții diferite. De exemplu, puteți citi primele 100 de rânduri, apoi vă uitați la a 10001-a linie și, în funcție de valoarea acesteia, treceți la ultima linie sau închideți cu totul cursorul.

Un mecanism la fel de interesant sunt indicii funcționali. Să presupunem că trebuie să stocați numele și prenumele utilizatorului în coloane separate și că faceți distincție între majuscule și minuscule, dar căutați utilizatori după Numele completși nu ține seama de majuscule. Dacă SGBD nu acceptă indecși funcționali, sunteți forțat să creați un câmp suplimentar în tabel cu valoarea LOWER (prenume || " " || prenume), construiți un index pe acesta și mențineți valoarea corectă în acest câmp. Dacă există zece variante de interogare de acest fel, veți avea nevoie de zece coloane suplimentare. Indicii funcționali, după cum sugerează și numele, vă permit să construiți un index pe baza funcţie arbitrară, evitând astfel toate problemele descrise. De exemplu, puteți rula eficient interogări cu condiții precum UNDE sin(x) > 0,45 ȘI sin(x)< 0.46 .

PostgreSQL poate construi indecși doar pe o parte a rândurilor dintr-un tabel. Acest mecanism se numește indici parțiali. De exemplu, dacă accesați baza de date cu interogări precum SELECTAȚI * DIN jurnalele WHERE ip > inet „192.168.0.0” ȘI ip< inet "192.168.0.255" AND level = "error" , atunci puteți construi un index bazat pe câmpul ip numai pentru rândurile a căror valoare câmpului de nivel este egală cu "eroare". Acest lucru are sens dacă există o mulțime de jurnale și linii cu nivelul de valoare = "eroare" puţini. Cu indexurile parțiale, obțineți interogări mai rapide și mai puțină supraîncărcare (spațiu pe disc, timp pentru adăugarea de noi rânduri) decât cu indecșii obișnuiți.