Baza de date rusă postgres pro. Infrastructură de calcul paralelă în PostgreSQL. Comparația versiunilor PostgreSQL

Limbaje de scripting- PL/Lua, PL/LOLCODE, PL/Perl, plPHP, PL/Python, PL/Ruby, PL/sh, PL/Tcl și PL/Scheme;

Limbaje clasice - C, C++, Java (prin modulul PL/Java);

Limbajul statistic R (prin modulul PL/R).

PostgreSQL permite utilizarea funcțiilor care returnează un set de înregistrări, care pot fi apoi utilizate în același mod ca rezultatul unei interogări obișnuite.

Funcțiile pot fi executate atât cu drepturile creatorului lor, cât și cu drepturile utilizatorului actual. Funcțiile sunt uneori echivalate cu proceduri stocate, dar există o diferență între cele două concepte.

Declanșatoare

Declanșatorii sunt definiți ca funcții inițiate de operațiuni DML. De exemplu, o operație INSERT poate declanșa un declanșator care verifică înregistrarea adăugată pentru a vedea dacă îndeplinește anumite condiții. Când scrieți funcții pentru declanșatoare, pot fi utilizate diverse limbaje de programare.

Declanșatoarele sunt asociate cu tabele. Declanșatoarele multiple sunt executate în ordine alfabetică.

Reguli și puncte de vedere

Motorul de reguli este un mecanism pentru crearea de handlere personalizate nu numai pentru operațiunile DML, ci și pentru operațiunile de eșantionare. Principala diferență față de mecanismul de declanșare este că regulile sunt declanșate în etapa de analiză a cererii, înainte de a alege planul optim de execuție și procesul de execuție în sine. Regulile vă permit să suprascrieți comportamentul sistemului atunci când efectuați o operație SQL pe o tabelă. Un exemplu bun este implementarea mecanismului de vederi: atunci când se creează o vedere, se creează o regulă care specifică că în loc să efectueze o operație de selectare pe vizualizare, sistemul trebuie să efectueze o operație de selectare pe tabelul/tabelele de bază, ținând cont de selecția condițiile care stau la baza definiției vederii. Pentru a crea vizualizări care acceptă operațiuni de actualizare, regulile pentru operațiunile de inserare, modificare și ștergere a rândurilor trebuie definite de utilizator.

Indici

PostgreSQL are suport pentru indexuri următoarele tipuri: B-tree, hash, R-tree, GiST, GIN. Dacă este necesar, pot fi create noi tipuri de indici, deși acest lucru este departe de a fi un proces banal. Indecșii din PostgreSQL au următoarele proprietăți:

este posibil să vizualizați indexul nu numai direct, ci și în ordine inversă - crearea unui index separat pentru funcționarea construcției ORDER BY ... DESC nu este necesară;
este posibil să se creeze un index pe mai multe coloane de tabel, inclusiv coloane de diferite tipuri de date;
indicii pot fi funcționali, adică construiți nu pe baza unui set de valori ale unei anumite coloane/coloane, ci pe baza unui set de valori al unei funcții a unui set de valori;
indicii pot fi parțiali, adică construiți numai pe o parte a tabelului (pe o parte din proiecția acestuia); în unele cazuri, acest lucru ajută la crearea de indici mult mai compacti sau la îmbunătățirea performanței prin utilizarea tipuri diferite indici pentru diferite părți ale tabelului (de exemplu, în ceea ce privește frecvența actualizării);
Planificatorul de interogări poate folosi mai mulți indici simultan pentru a rula interogări complexe.

Multi-versiune (MVCC)

PostgreSQL acceptă modificarea simultană a bazei de date de către mai mulți utilizatori folosind mecanismul Multiversion Concurrency Control (MVCC). Acest lucru asigură conformitatea cu ACID și practic elimină nevoia de blocări de citire.

Căutare text integral

PostgreSQL are un sistem încorporat căutarea textului integral, care vă permite să căutați documente în baza de date și să le sortați într-o anumită ordine. Principalele avantaje ale utilizării căutării încorporate full-text sunt: integrarea strânsă cu SGBD (tranzacționalitate, acces simultan, recuperarea erorilor), scalabilitate, oportunități ample setări (dicționare, analizoare etc.).

Sisteme informatice geografice

PostGIS este o extensie a DBMS PostgreSQL concepută pentru stocarea datelor geografice într-o bază de date. PostGIS include suport pentru indici spațiali R-Tree/GiST și funcții de procesare a geodatelor.

2019: Compatibil cu TerraLink xDE

2018

Includerea co-fondatorului Postgres Professional, Alexander Korotkov, în lista de comitetari DBMS PostgreSQL

În iunie 2018, lista de committeri (dezvoltatori care contribuie la dezvoltarea codului) ai SGBD PostgreSQL a fost completată cu un al treilea rus. Lista principalilor comisiști ai kernel-ului PostgreSQL, co-fondator și director de dezvoltare al companiei ruse Postgres Professional.

2017

Documentația pentru versiunea 10 este localizată pentru Rusia

Principalele inovații:

Replicare logică: Părți ale acestui mecanism au fost adăugate la PostgreSQL de ceva timp, iar în această versiune replicarea logică a devenit complet disponibilă pentru utilizatori. Cu ajutorul acestuia, puteți replica selectiv tabele individuale pe un alt server, care poate executa apoi atât interogări de citire, cât și de scriere. Serverele care participă la replicare pot rula sub versiuni diferite PostgreSQL, care vă permite să actualizați clusterul de la timp minim doar eu.
Partiționare declarativă scutește administratorul de nevoia de a defini manual ierarhia tabelului, de a crea declanșatoare și constrângeri de integritate.
Execuție paralelă a interogărilor A devenit posibilă scanarea bitmap-urilor și indexurilor, îmbinării îmbinărilor și subinterogărilor în plus față de capabilitățile care au apărut în versiunea anterioară.
Replicare sincronă în funcție de cvorum vă permite să înregistrați modificările dacă acestea au fost confirmate de numărul necesar de replici aleatorii.
Autentificare SCRAM este o versiune mai rezistentă la criptografie a autentificării MD5 utilizate anterior.

În total, conform dezvoltatorilor, versiunea 10 include peste 100 de modificări și îmbunătățiri, dintre care unele au fost făcute de Postgres Professional.

Integrarea Ethereum

14 septembrie 2017 firma ruseasca Postgres Professional a anunțat crearea unui prototip al extensiei Postthereum pentru integrarea unui DBMS PostgreSQL complet cu o platformă blockchain concepută pentru înregistrarea tranzacțiilor cu orice tip de active pe baza unui sistem de „contracte inteligente”. Conform planului companiei, mare băncile rusești, corporațiile și agențiile guvernamentale care lucrează cu SGBD-ul PostgreSQL, cu ajutorul acestei dezvoltări vor putea combina baze de date cu aplicații blockchain bazate pe Ethereum. Citeşte mai mult.

2016

PostgreSQL 9.6

Pe 29 septembrie 2016, comunitatea de dezvoltatori a prezentat ramura stabilă a SGBD PostgreSQL 9.6. Actualizările lui 9.6 vor fi lansate pe parcursul a cinci ani, până în septembrie 2021.

Adăugiri majore

Comparație între Tibero și PostgreSQL

Eliberarea corectivă a tuturor ramurilor

Pe 11 februarie 2016, comunitatea de dezvoltatori PostgreSQL a anunțat lansarea de actualizări corective pentru toate ramurile PostgreSQL acceptate: 9.5.1, 9.4.6, 9.3.11, 9.2.15 și 9.1.20, care a eliminat două vulnerabilități, a introdus o porțiune de remedieri de erori, a adăugat suport pentru Python 3.5 în PL/Python și abilitatea de a partaja Python2 și Python3 într-o singură bază de date.

Ramura 9.0.x a fost întreruptă. Lansarea actualizărilor pentru filială:

9.1 prelungit până în septembrie 2016.
9.2 prelungit până în septembrie 2017,
9.3 prelungit până în septembrie 2018,
9.4 prelungit până în decembrie 2019,
9.5 prelungit până în ianuarie 2021.

Prima dintre vulnerabilități (CVE-2016-0773) apare în motorul de procesare expresii obisnuiteși poate cauza blocarea backend-ului la analizarea expresiilor regulate cu caractere din afara domeniului Unicode (problema afectează sistemele care utilizează intrarea utilizatorului pentru a genera expresia regulată).

A doua vulnerabilitate (CVE-2016-0766) este prezentă în motorul PL/Java și vă permite să vă creșteți privilegiile atunci când lucrați cu baza de date.

PostgreSQL 9.5

Pe 7 ianuarie 2016, a devenit cunoscut despre lansarea unei ramuri stabile a SGBD PostgreSQL 9.5. Lansarea actualizărilor pentru ramura 9.5 va fi acceptată până în ianuarie 2021.

Schimbări

Funcționalitatea „UPSERT” (adăugați sau modificați), implementată printr-o nouă expresie „INSERT... ON CONFLICT NOHING/UPDATE”, vă permite să gestionați situația în care datele nu pot fi adăugate prin „INSERT”, de exemplu, din cauza la o încălcare a condițiilor de unicitate sau invaliditate a valorilor unuia dintre câmpuri. În loc să aruncați o eroare, acum puteți ignora execuția instrucțiunii sau puteți modifica datele asociate câmpului cheie (adică, dacă înregistrarea există deja, efectuați UPDATE în loc de INSERT);
Restricție de acces la nivel de rând (Row-Level Security, RLS). Accesul utilizatorilor la datele dintr-un tabel poate fi acum restricționat la nivelul rândurilor individuale; de exemplu, puteți interzice unei anumite categorii de utilizatori să vizualizeze rândurile care stochează date adăugate de un alt utilizator. Pentru a activa RLS, ar trebui să utilizați directiva „ALTER TABLE tablename ENABLE ROW LEVEL SECURITY”, după care trebuie să setați regulile de acces folosind expresia „CREATE POLICY”;
Indicii BRIN („block range indexes”) permit indexarea ultra-compactă a tabelelor foarte mari, fără utilizarea arborilor B tradiționali. Esența indicilor BRIN se rezumă la împărțirea indicelui general în blocuri, fiecare dintre acestea conținând date de index doar pentru un anumit interval de valori. În cadrul testului, o metodă similară s-a dovedit a fi de aproximativ două ori mai lentă decât arborele b la efectuarea operațiunilor de recuperare a datelor, dar de 3-4 ori mai rapidă la crearea și actualizarea unui index și, de asemenea, a ocupat mult mai puțin spațiu pe disc (64 KB față de 28 MB);
Noi funcții și operatori pentru tipul de date JSONB. Pentru a schimba valorile într-un document JSONB, acum puteți evita preluarea și redefinirea întregului document prin introducerea funcției jsonb_set(). De asemenea, sunt adăugate funcțiile json_strip_nulls (eliminarea atributelor care conțin valori NULL) și jsonb_pretty (ieșire în format JSON). S-a adăugat operatorul „||”. pentru a concatena două valori JSONB;
Instrumentul pg_rewind vă permite să simplificați semnificativ procesul de restaurare a configurațiilor tolerante la erori după trecerea la un server de rezervă. După ce serverul principal revine în funcțiune, apare sarcina de a-și sincroniza starea cu serverul de rezervă, care a continuat să funcționeze și care a reușit să-și acumuleze cota de modificări. Utilitarul pg_wind încearcă să restabilească starea serverului primar din jurnalul de tranzacții WAL, parcurgându-le începând cu momentul cu puțin timp înainte de eșec, identificând datele modificate și transferând doar blocurile modificate, ceea ce vă permite să faceți fără a restabili un complet copiați de pe un server de rezervă funcțional.
Vitezele de sortare și hashing semnificativ optimizate în memorie. Datorită utilizării unei noi metode de sortare a valorilor și numerelor șirurilor, a fost posibilă creșterea vitezei de creare a indicilor de până la 20 de ori, iar timpul de execuție a interogărilor care necesită sortarea unor volume mari de date a fost redus cu 2- de 12 ori;
S-a adăugat suport pentru expresia TABLESAMPLE, care vă permite să creați un eșantion pe o cantitate incompletă de date din tabele mari, fără a efectua operațiuni de sortare care necesită mult resurse pe întregul tabel. De exemplu, interogarea „SELECT * FROM test TABLESAMPLE SYSTEM(10)” va produce rezultate care acoperă doar 10% din tabelul de test. Sunt disponibili mai mulți algoritmi pentru eliminarea valorilor în timpul procesului de subeșantionare;
Scalare îmbunătățită pe sisteme cu o cantitate mare nuclee de procesor și RAM. De exemplu, pe un sistem cu 24 de nuclee CPU și 496 GB de RAM în testul EnterpriseDB sub o încărcare de 64 de conexiuni simultane, PostgreSQL 9.5 a arătat o creștere a performanței cu 96% în comparație cu PostgreSQL 9.4;
Gestionarea automată a dimensiunii jurnalului de tranzacții. Abilitatea de a exclude tabelele de a fi reflectate în jurnalul de tranzacții (ALTER TABLE ... SET LOGGED / UNLOGGED);
Capacitățile analitice „GROUPING SETS”, „CUBE” și „ROLLUP”, permițându-vă să generați rezultate grupate pe un set de câmpuri și să calculați numărul de combinații ale diferitelor categorii;
Replicare îmbunătățită și îmbunătățiri ale toleranței la erori. A fost adăugat un mecanism pentru urmărirea stării de execuție a replicării, inclusiv metode pentru determinarea cauzei modificărilor individuale în timpul replicării logice;
Au fost aduse mai multe îmbunătățiri motorului Foreign Data Wrappers, inclusiv declarația „IMPORT FOREIGN SCHEMA”, care vă permite să automatizați importul tuturor tabelelor străine aferente pentru tabele existente cu eticheta de server selectată. În plus, este posibil să se moștenească tabele externe din tabele locale și invers, de exemplu, „CREATE local_customers () moștenește (remote.customers);”
Opțiunea „-j” a fost adăugată la utilitarul vacuumdb, permițându-vă să rulați VACUUM în mai multe fire concurente.

2015

Infrastructură de calcul paralelă în PostgreSQL

Pe 4 mai 2015, a devenit cunoscut faptul că au fost aduse modificări arborelui sursă al SGBD-ului PostgreSQL odată cu implementarea unei infrastructuri pentru calcul paralel.

Oferă:

Proceduri convenabile pentru coordonarea pornirii și opririi proceselor de lucru concurente;
Sincronizarea diferitelor stări interne (GUC, mapare CID combinată, instantanee ale tranzacțiilor) între liderul grupului lucrări paraleleși fluxuri de lucru paralelizate direct;
Restricție de apeluri diverse operatii, ceea ce poate duce la efectuarea unor modificări incorecte în condiții de paralelizare activă;
Livrarea notificărilor către client prin mesaje ErrorResponse, NoticeResponse și NotifyResponse de la handleri care rulează în paralel.

Postgres-XL pe EcoServer - o alternativă pentru centrele de date

Pe 13 august 2015, a devenit cunoscut faptul că testarea sistemului de management al bazei de date Postgres-XL pe serverele liniei EcoServer a fost finalizată.

Au fost efectuate teste pentru monitorizarea noilor tehnologii și implementarea planului de dezvoltare tehnologică pentru 2015.

Andrei Cernogorov, CEO„Indigo IT” a menționat: „Astăzi, cele mai populare SGBD de pe piața IT sunt MS SQL și Oracle DataBase. În același timp, după un număr capabilități cheie ele nu sunt în niciun fel inferioare lor, și în unele locuri chiar superioare, DBMS-ului open source PostgreSQL, care deschide perspective largi pentru utilizarea sa ca parte a programului de substituire a importurilor.”

Pentru testare, specialiștii companiei au pregătit seturi de date de testare identice pentru toate SGBD-urile. Obiectul de testare a fost o bază de date de 1 TB constând din 1 milion de obiecte de afaceri. Durata testării pentru fiecare SGBD este de 10 ore.

La aceasta au participat ultimele versiuni DBMS cel mai solicitat de către clienții Indigo IT:

deschide DBMS PostgreSQL 9.4.

Au fost efectuate un total de 5 seturi de teste:

crearea de documente structurate complexe,
actualizarea documentelor structurate complex,
căutare de documente,
scrierea unui fișier în baza de date,
obținerea unui fișier din baza de date.

Rezultatele testelor, 2015

Timpul petrecut în fiecare dintre seturile de testare indicate în tabel înseamnă valoarea medie pentru toate seturile (ms). Testarea a fost efectuată pe servere cu procesoare Intel Xeon E5 v3 cu 128 GB RAM.

Ca urmare testarea sarcinii pe două din cele cinci seturi de testare (crearea documentelor structurate complex, actualizarea documentelor structurate complex), PostgreSQL 9.4 a arătat rezultate de aproape trei ori mai bune decât concurenții săi. La testele rămase (căutarea documentelor, înregistrarea și preluarea fișierelor din baza de date), participanții la test au prezentat rezultate aproape identice.

Această versiune a SGBD PostgreSQL cu sursă deschisă acceptă formatul de schimb de date JSON utilizat pe scară largă și este destinată pieței în creștere pentru magazinele de date non-relaționale NoSQL și în special SGBD-ul MongoDB popular.

Prima versiune beta a PostgreSQL 9.4 introduce o serie de caracteristici noi care vizează piața în expansiune rapidă a aplicațiilor web, multe dintre acestea necesită stocare și recuperare rapidă a unor volume mari de date de utilizator.

Versiunea PostgreSQL 9.4 acceptă formatul JSON (JavaScript Simple Object Notation), care a câștigat rapid popularitate la organizarea schimbului de date între diferite sisteme, inclusiv folosind protocolul REST (Representational State Transfer). Succesul documentului MongoDB DBMS se datorează în mare măsură popularității tot mai mari a JSON.

Formatul structurat PostgreSQL pentru stocarea datelor conform specificațiilor JSON (JSONB) elimină necesitatea de a restructura documentul înainte de a-l introduce în baza de date. Ca rezultat, PostgreSQL ingerează documente la fel de repede ca MongoDB, în timp ce continuă să îndeplinească cerințele ACID (atomicitate, consistență, izolare, durabilitate) pentru stocarea informațiilor în bazele de date. În plus, PostgreSQL acceptă Set complet indexați servicii, funcții și operatori pentru a manipula eficient datele JSON.

Versiunile anterioare de PostgreSQL acceptau și JSON, dar documentele JSON erau stocate în format text, drept urmare operațiunile de înregistrare și recuperare a acestora au durat mult mai mult.

PostgreSQL a primit o serie de caracteristici noi:

Un nou API pentru decodarea datelor dintr-un flux de replicare deschide calea dezvoltatorilor independenți de software pentru a construi sisteme de replicare mai rapide.
O nouă funcție din Vizualizările materializate numită „reîmprospătare simultană” permite ca rapoartele rezumative să fie actualizate din mers.
Caracteristica Alter System Set va ajuta administratorii să modifice fișierul de configurare PostgreSQL direct din Linie de comanda SQL.

Au fost adăugate o serie de funcții și capabilități, inclusiv Dynamic Background Workers, manipularea matricei și funcțiile tabelului, productivitatea generală a crescut.

PostgreSQL 9.3

PostgreSQL 9.3 implementează o serie de mecanisme care vă permit să faceți schimb de informații cu alte baze de date și depozite de date. Modulele Foreign Data Wrapper, care au apărut în versiunea 9.1 și anterior permiteau doar citirea datelor din alte sisteme, oferă acum capacitatea de scriere. Acceptă lucrul cu tabele relaționale și cu informații semi-structurate din sistemele NoSQL. De asemenea, a fost creat un driver pentru DBMS, care vă permite să conectați două copii diferite ale PostgreSQL în sine și asigură execuția accelerată a tranzacțiilor între ele.

Alte caracteristici includ suport JSON îmbunătățit și capacitatea de a crea module arbitrare de server de fundal cu acces nelimitat la datele PostgreSQL. Un exemplu este modulul Mongres, care traduce automat interogările MongoDB în format PostgreSQL.

Implementat actualizare automata reprezentări și a adăugat un utilitar care vă permite să executați în mod paralel backup baze mari. Au fost luate măsuri pentru a îmbunătăți fiabilitatea SGBD. Funcția Fast Failover vă permite să comutați munca de la baza de date master la o copie în mai puțin de o secundă. Acum poți verifica sume de control pagini pentru a ajuta la diagnosticarea defecțiunilor hard diskului.

PostgreSQL 9.2

PostgreSQL 9.0

Dezvoltatorii sistemului de gestionare a bazelor de date deschise PostgreSQL au lansat în septembrie 2010 prima versiune candidată a sistemului Postrgesql 9.0, care implementează toate funcțiile pregătite pentru lansare în cea de-a noua versiune a acestui popular SGBD. Disponibil gratuit pe acest moment O versiune binară a versiunii preliminare a Postgresql 9.0 este disponibilă și toată lumea poate testa noile capabilități ale acestei dezvoltări înainte de a transfera servere de producție care funcționează cu informații reale.

Tot în versiunea a noua, a devenit posibilă replicarea informațiilor din jurnalele binare, corespunzătoare mecanismului Hot Stanby Databases din Oracle Database. Dezvoltatorii au acordat atenție și sistemelor cloud sau SaaS din ce în ce mai populare. Acum DBMS este optimizat pentru a lucra într-un mediu de mașină virtuală, acceptă un mecanism pentru clonarea rapidă a datelor, precum și capacitatea de a replica informații de la un singur server master la un număr mare (mai mult de o sută) de servere slave. De asemenea noua versiune acceptă pe deplin capabilitățile de adresare a memoriei în variantele de Windows pe 64 de biți.

Traducere

Astăzi să vorbim despre avantajele Postgres față de alte sisteme open source. Cu siguranță vom trata acest subiect mai detaliat la PG Day"16 Rusia, care este la doar două luni distanță.

S-ar putea să vă întrebați „De ce PostgreSQL?” La urma urmei, există și alte opțiuni de baze de date relaționale open source (în scopul acestui articol, ne-am uitat la MySQL, MariaDB și Firebird), așa că ce poate oferi Postgres și nu? Sloganul PostgreSQL afirmă că este „Cea mai avansată bază de date open source din lume”. Vom da mai multe motive pentru care Postgres face astfel de afirmații.

În prima parte a acestei serii, vom vorbi despre stocarea datelor - model, structură, tipuri și limitări de dimensiune. Și în a doua parte ne vom concentra mai mult pe eșantionare și manipulare a datelor.

Model de date

PostgreSQL nu este doar un SGBD relațional, ci și un obiect relațional. Acest lucru îi oferă câteva avantaje față de alte baze de date SQL open source, cum ar fi MySQL, MariaDB și Firebird.

O caracteristică fundamentală a unei baze de date obiect-relaționale este suportul pentru obiectele utilizator și comportamentul acestora, inclusiv tipuri de date, funcții, operațiuni, domenii și indici. Acest lucru face ca Postgres să fie incredibil de flexibil și de fiabil. Printre altele, poate crea, stoca și prelua structuri complexe de date. În unele dintre exemplele de mai jos, veți vedea constructe imbricate și compuse care nu sunt acceptate de RDBMS-urile standard.

Structuri și tipuri de date

Există o listă extinsă de tipuri de date pe care le acceptă Postgres. Pe lângă tipurile de date numerice, float, text, boolean și alte tipuri de date așteptate (și multe variații ale acestora), PostgreSQL oferă suport pentru uuid, monetare, enumerate, geometrice, binare, adrese de rețea, șiruri de biți, căutare text, xml, json, matrice, tipuri și intervale compozite, precum și unele tipuri interne pentru identificarea obiectelor și a locațiilor de înregistrare. Pentru a fi corect, MySQL, MariaDB și Firebird au și ele unele dintre aceste tipuri de date, dar numai Postgres le acceptă pe toate.

Să aruncăm o privire mai atentă la unele dintre ele:

Adresele de rețea

PostgreSQL oferă stocarea diferitelor tipuri de adrese de rețea. Tipul de date CIDR (Classless Internet Domain Routing) urmează convenția pentru adresele de rețea IPv4 și IPv6. Aici sunt cateva exemple:

192.168.100.128/25
10.1.2.3/32
2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128
::ffff:1.2.3.0/128

De asemenea, disponibil pentru stocarea adreselor de rețea este tipul de date INET, utilizat pentru gazdele IPv4 și IPv6, unde subrețelele sunt opționale. Tipul de date MACADDR poate fi utilizat pentru a stoca adrese MAC pentru identificarea hardware, cum ar fi 08-00-2b-01-02-03.

MySQL și MariaDB au și funcții INET pentru conversia adreselor de rețea, dar nu oferă tipuri de date pentru stocarea adreselor de rețea în interior. Firebird nu are, de asemenea, tipuri pentru stocarea adreselor de rețea.

Matrice multidimensionale

Deoarece Postgres este o bază de date obiect-relațională, matricele de valori pot fi stocate pentru majoritatea tipurile existente date. Acest lucru se poate face adăugând paranteze pătrate la specificația tipului de date pentru coloană sau utilizând expresia ARRAY. Mărimea matricei poate fi specificată, dar nu este necesară. Să ne uităm la un meniu de picnic de sărbători pentru a demonstra utilizarea matricelor:

Creați un tabel ale cărui valori sunt tablouri CREATE TABLE holiday_picnic (holiday varchar(50) -- valoare șir text sandwich, -- matrice de text lateral, -- matrice multidimensională desert text ARRAY, -- array of beverage text ARRAY -- matrice de 4 elemente); -- inserați valori de matrice în tabel INSERT INTO holiday_picnic VALUES ("Ziua Muncii", "("roast beef","veggie","curcan")", "( ("salata de cartofi","salata verde", "salata de macaroane"), ("chips","biscuiți")", "("cocktail de fructe","plăcintă cu fructe de pădure","înghețată")", "("sodă","suc","bere" ,"apă ")");
MySQL, MariaDB și Firebird nu pot face acest lucru. Pentru a stoca astfel de matrice de valori în mod tradițional baze de date relaționale date, va trebui să utilizați o soluție și să creați masa separata cu rânduri pentru fiecare dintre valorile matricei.

Date geometrice

Datele de locație devin rapid o cerință de bază pentru multe aplicații. PostgreSQL a acceptat mult timp multe tipuri de date geometrice, cum ar fi puncte, linii, cercuri și poligoane. Unul dintre aceste tipuri este PATH, care constă din multe puncte secvențiale și poate fi deschis (punctele de început și de sfârșit nu sunt conectate) sau închis (punctele de început și de sfârșit sunt conectate). Să luăm ca exemplu un traseu de drumeții. ÎN în acest caz, Traseul de drumeție este o buclă, așa că punctele de început și de sfârșit sunt conectate, ceea ce înseamnă că drumul meu este închis. Paranteze rotundeîn jurul unui set de coordonate indică o cale închisă, iar cele pătrate indică o cale deschisă.

Creați un tabel pentru a stoca traseele CREATE TABLE trasee (trail_name varchar(250), trail_path path); -- introduceți traseul în tabel, -- pentru care traseul este determinat de coordonatele în format latitudine-longitudine INSERT INTO trase VALUES ("Dool Trail - Creeping Forest Trail Loop", ((37.172,-122.22261666667), (37.171616666667, -122,22385), (37,1735,-122,2236), (37,175416666667,-122,223), (37,1758,-122,22378333333), (37,1794666667,-122,223), (37,1758,-122,22378333333), (37,17946666667,-122,223) 95,-122,2267 5), (37,180783333333,-122,22466666667), (37,176116666667, -122,2222), (37,1753,-122,22293333333), (37,173116666667,-122,22281666667)));
Extensia PostGIS pentru PostgreSQL extinde proprietățile de date geometrice existente cu tipuri spațiale auxiliare, funcții, operatori și indici. Oferă suport pentru locație și acceptă atât date raster, cât și date vectoriale. De asemenea, oferă compatibilitate cu o varietate de instrumente geospațiale terțe (cu drepturi de autor și cu sursă deschisă) pentru afișarea, randarea și lucrul cu date.

Rețineți că MySQL 5.7.8 și MariaDB începând cu versiunea 5.3.3 au adăugat extensii de tip de date pentru a sprijini standardul de informații geografice OpenGIS. Această versiune de MySQL și versiunile ulterioare de MariaDB oferă stocare de tip de date similară cu geodatele native Postgres. Cu toate acestea, în MySQL și MariaDB, valorile datelor trebuie mai întâi convertite în format geometric folosind comenzi simple înainte de a fi introduse în tabel. Firebird nu acceptă în prezent tipuri de date geometrice.

Suport JSON

Suportul JSON în PostgreSQL vă permite să treceți la stocarea datelor fără schemă într-o bază de date SQL. Acest lucru poate fi util atunci când structura de date necesită o oarecare flexibilitate: de exemplu, dacă structura încă se schimbă în timpul dezvoltării sau nu se știe ce câmpuri va conține obiectul de date.

Tipul de date JSON oferă validare JSON, care vă permite să utilizați operatori și funcții JSON specializate încorporate în Postgres pentru a efectua interogări și a manipula datele. De asemenea, este disponibil și tipul JSONB - o variație binară a formatului JSON în care spațiile sunt eliminate, sortarea obiectelor nu este păstrată, în schimb acestea sunt stocate în cel mai optim mod și numai ultima valoare pentru chei duplicate. JSONB este de obicei formatul preferat, deoarece necesită mai puțin spațiu pentru obiecte, poate fi indexat și este mai rapid de procesat, deoarece nu necesită repetări. analizare.

MySQL 5.7.8 și MariaDB 10.0.1 au adăugat suport pentru obiectele JSON native. Dar, deși există multe funcții și operatori pentru JSON care sunt acum disponibili în aceste baze de date, aceștia nu sunt indexați în același mod ca JSONB în PostgreSQL. Firebird nu s-a alăturat încă tendinței și acceptă doar obiecte JSON ca text.

Crearea unui nou tip

Dacă se întâmplă să găsiți că lista extinsă de tipuri de date a Postgres este insuficientă, puteți utiliza comanda CREATE TYPE pentru a crea noi tipuri de date, cum ar fi compus, enumerat, interval și de bază. Să ne uităm la un exemplu de creare și trimitere de solicitări de tip nou compus:

Creați un nou tip compozit „vin” CREATE TYPE wine AS (wine_vineyard varchar(50), wine_type varchar(50), wine_year int); -- creați un tabel care folosește perechi de tip compozit „vin” CREATE TABLE (menu_entree varchar(50), wine_pairing wine); -- inserați date în tabel folosind expresia ROW INSERT INTO pairings VALUES ("Coada homarului", ROW("Stag""s Leap","Chardonnay", 2012)), ("Elk Medallions",ROW("Rombauer" , „Cabernet Sauvignon”, 2012)); /* selectează dintr-un tabel folosind numele coloanei (utilizați paranteze separate printr-un punct de numele câmpului într-un tip compus) */ SELECT (wine_pairing).wine_vineyard, (wine_pairing).wine_type FROM pairings WHERE menu_entree = "Elk Medallions";
Deoarece nu sunt obiect-relaționale, MySQL, MariaDB și Firebird nu oferă o funcționalitate atât de puternică.

Dimensiunile datelor

PostgreSQL poate gestiona o mulțime de date. Restricțiile actuale publicate sunt enumerate mai jos:

În Compune [aprox. per.: organizația în care lucrează autorul articolului original] vă scalăm automat instalația, astfel încât să nu vă faceți griji cu privire la creșterea cantității de date. Dar, după cum știe orice administrator de baze de date, ar trebui să fiți atenți la prea multe sau prea multe opțiuni. Vă recomandăm să folosiți bunul simț atunci când creați tabele și adăugați indecși.

În comparație, MySQL și MariaDB sunt renumite pentru limita de dimensiune a rândurilor de 65.535 de octeți. Firebird oferă, de asemenea, doar 64 Kb ca dimensiune maximă a liniei. De obicei, cantitatea de date este limitată de dimensiunea maximă a fișierului a sistemului de operare. Deoarece PostgreSQL poate stoca date tabulare în mai multe fișiere dimensiune mai mică, el poate ocoli această limitare. Dar merită remarcat faptul că prea multe fișiere pot avea un impact negativ asupra performanței. MySQL și MariaDB acceptă mai multe coloane per tabel (până la 4.096 în funcție de tipul de date) și dimensiuni mai mari ale tabelelor individuale decât PostgreSQL, dar necesitatea depășirii limitelor Postgres existente apare doar în cazuri extrem de rare.

Integritatea datelor

Postgres se străduiește să fie compatibil ANSI-SQL:2008, ACID (Atomicity, Consistency, Isolation and Durability) și este cunoscut pentru integritatea sa referențială și tranzacțională. Cheile primare, cheile externe de constrângere și în cascadă, constrângerile unice, constrângerile NOT NULL, constrângerile de verificare și alte caracteristici de integritate a datelor asigură păstrarea numai a datelor valide.

MySQL și MariaDB lucrează mai mult pentru a se potrivi Standardul SQL cu motoare de tabel InnoDB/XtraDB. Ele oferă acum o opțiune STRICT folosind moduri SQL care setează verificări de valabilitate asupra datelor utilizate. Cu toate acestea, în funcție de modul pe care îl utilizați, în timpul actualizării pot fi inserate sau create date invalide și chiar trunchiate fără știrea dvs. Niciuna dintre aceste baze de date nu acceptă în prezent VERIFICAȚI restricțiile. În plus, au multe caracteristici referitoare la constrângerile de integritate referenţială. chei externe. În plus față de cele de mai sus, integritatea datelor poate fi compromisă semnificativ în funcție de motorul de stocare ales. MySQL (și fork-ul MariaDB) nu au făcut niciun secret din faptul că schimbă integritatea și conformitatea cu standardele pentru viteză și eficiență.

Rezumând

Postgres are multe caracteristici. Construit folosind modelul obiect-relațional, acesta acceptă structuri complexe și o gamă largă de tipuri de date încorporate și definite de utilizator. Oferă o capacitate extinsă de date și este de încredere pentru gestionarea atentă a integrității datelor. Este posibil să nu aveți nevoie de toate funcțiile avansate de stocare pe care le-am explorat în acest articol, dar, din moment ce nevoile dvs. se pot aduna rapid, există un avantaj clar de a le avea pe toate la îndemână.

Dacă simțiți că PostgreSQL nu se potrivește nevoilor dvs. sau preferați să „trageți de la șold”, atunci poate doriți să aruncați o privire la bazele de date NoSQL pe care le oferim la Compose sau să luați în considerare altele baze de date SQL datele pe care le-am menționat. Fiecare dintre ele are propriile sale avantaje. Compose crede ferm că este foarte important să alegeți baza de date potrivită pentru sarcina specifica…uneori asta înseamnă selectarea mai multor baze de date!

Vrei mai mult Postgres?

SQL

Dezvoltare site

Traducere

Astăzi să vorbim despre avantajele Postgres față de alte sisteme open source. Cu siguranță vom trata acest subiect mai detaliat la PG Day"16 Rusia, care este la doar două luni distanță.

În prima parte a acestei serii, vom vorbi despre stocarea datelor - model, structură, tipuri și limitări de dimensiune. Și să ne concentrăm mai mult pe eșantionare și manipulare a datelor.

Model de date

PostgreSQL nu este doar un SGBD relațional, ci și un obiect relațional. Acest lucru îi oferă câteva avantaje față de alte baze de date SQL open source, cum ar fi MySQL, MariaDB și Firebird.

Structuri și tipuri de date

Există o listă extinsă de tipuri de date pe care le acceptă Postgres. Pe lângă tipurile de date numerice, float, text, boolean și alte tipuri de date așteptate (și multe variații ale acestora), PostgreSQL se mândrește cu suport pentru uuid, monetare, enumerare, geometrice, binare, adrese de rețea, șiruri de biți, căutare text, xml, json, matrice , tipuri și intervale compozite, precum și unele tipuri interne pentru identificarea obiectelor și a locațiilor de înregistrare. Pentru a fi corect, MySQL, MariaDB și Firebird au și ele unele dintre aceste tipuri de date, dar numai Postgres le acceptă pe toate.

Să aruncăm o privire mai atentă la unele dintre ele:

Adresele de rețea

192.168.100.128/25
10.1.2.3/32
2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128
::ffff:1.2.3.0/128

Matrice multidimensionale

Deoarece Postgres este o bază de date obiect-relațională, matricele de valori pot fi stocate pentru majoritatea tipurilor de date existente. Acest lucru se poate face adăugând paranteze pătrate la specificația tipului de date pentru coloană sau utilizând expresia ARRAY. Mărimea matricei poate fi specificată, dar nu este necesară. Să ne uităm la un meniu de picnic de sărbători pentru a demonstra utilizarea matricelor:

Creăm un tabel ale cărui valori sunt matrice CREATE TABLE holiday_picnic (holiday varchar(50) -- text sandwich valoare șir, -- text lateral matrice , -- matrice multidimensională text desert ARRAY, -- matrice beverage text ARRAY -- matrice de 4- x elemente); -- inserați valori de matrice în tabel INSERT INTO holiday_picnic VALUES ("Ziua Muncii", "("roast beef","veggie","curcan")", "( ("salata de cartofi","salata verde", "salata de macaroane"), ("chips","biscuiți")", "("cocktail de fructe","plăcintă cu fructe de pădure","înghețată")", "("sodă","suc","bere" ,"apă ")");
MySQL, MariaDB și Firebird nu pot face acest lucru. Pentru a stoca astfel de matrice de valori în bazele de date relaționale tradiționale, ar trebui să utilizați o soluție și să creați un tabel separat cu rânduri pentru fiecare dintre valorile matricei.

Date geometrice

Datele de locație devin rapid o cerință de bază pentru multe aplicații. PostgreSQL a acceptat mult timp multe tipuri de date geometrice, cum ar fi puncte, linii, cercuri și poligoane. Unul dintre aceste tipuri este PATH, care constă din multe puncte secvențiale și poate fi deschis (punctele de început și de sfârșit nu sunt conectate) sau închis (punctele de început și de sfârșit sunt conectate). Să luăm ca exemplu un traseu de drumeții. În acest caz, traseul de drumeții este o buclă, deci punctele de pornire și de sfârșit sunt conectate și, prin urmare, calea mea este închisă. Parantezele rotunde din jurul unui set de coordonate indică o cale închisă, în timp ce parantezele pătrate indică o cale deschisă.

Suport JSON

Tipul de date JSON oferă validare JSON, care vă permite să utilizați operatori și funcții JSON specializate încorporate în Postgres pentru a efectua interogări și a manipula datele. De asemenea, este disponibil și tipul JSONB, o variantă binară a formatului JSON care elimină spații, nu păstrează sortarea obiectelor, ci le stochează în cel mai optim mod și stochează doar ultima valoare pentru cheile duplicate. JSONB este de obicei formatul preferat, deoarece necesită mai puțin spațiu pentru obiecte, poate fi indexat și este mai rapid de procesat, deoarece nu necesită re-parsare.

Crearea unui nou tip

Dimensiunile datelor

PostgreSQL poate gestiona o mulțime de date. Restricțiile actuale publicate sunt enumerate mai jos:

În comparație, MySQL și MariaDB sunt renumite pentru limita de dimensiune a rândurilor de 65.535 de octeți. Firebird oferă, de asemenea, doar 64 Kb ca dimensiune maximă a liniei. De obicei, cantitatea de date este limitată de dimensiunea maximă a fișierului a sistemului de operare. Deoarece PostgreSQL poate stoca date tabulare în multe fișiere mai mici, poate rezolva această limitare. Dar merită remarcat faptul că prea multe fișiere pot avea un impact negativ asupra performanței. MySQL și MariaDB acceptă mai multe coloane per tabel (până la 4.096 în funcție de tipul de date) și dimensiuni mai mari ale tabelelor individuale decât PostgreSQL, dar necesitatea depășirii limitelor Postgres existente apare doar în cazuri extrem de rare.

Integritatea datelor

MySQL și MariaDB lucrează mai mult pentru a se conforma standardului SQL cu motoarele de tabel InnoDB/XtraDB. Ele oferă acum o opțiune STRICT folosind moduri SQL care setează verificări de valabilitate asupra datelor utilizate. Cu toate acestea, în funcție de modul pe care îl utilizați, în timpul actualizării pot fi inserate sau create date invalide și chiar trunchiate fără știrea dvs. Niciuna dintre aceste baze de date nu acceptă în prezent restricțiile CHECK. În plus, au multe caracteristici referitoare la constrângerile de integritate referențială asupra cheilor externe. În plus față de cele de mai sus, integritatea datelor poate fi compromisă semnificativ în funcție de motorul de stocare ales. MySQL (și fork-ul MariaDB) nu au făcut niciun secret din faptul că schimbă integritatea și conformitatea cu standardele pentru viteză și eficiență.

Rezumând

Dacă simțiți că PostgreSQL nu se potrivește nevoilor dvs. sau preferați să „trageți de la șold”, atunci poate doriți să aruncați o privire la bazele de date NoSQL pe care le oferim la Compose sau să luați în considerare celelalte baze de date SQL pe care le-am menționat . Fiecare dintre ele are propriile sale avantaje. Compose crede ferm că este foarte important să alegeți baza de date potrivită pentru o anumită sarcină... uneori asta înseamnă să alegeți mai multe baze de date!

Vrei mai mult Postgres?

PostgreSQL este un SGBD open-source, multiplatformă, cu relații obiecte. Acest articol vă va arăta cum să instalați PostgreSQL în Ubuntu Linux, conectați-vă la acesta și executați câteva interogări SQL simple, precum și cum să configurați o copie de rezervă.

Pentru a instala PostgreSQL 9.2 pe Ubuntu 12.10, executați următoarele comenzi:

sudo apt-add-repository ppa:pitti/postgresql
sudo apt-get update
sudo apt-get install postgresql-9.2

Să încercăm să lucrăm cu DBMS prin intermediul shell-ului:

sudo -u postgres psql

Să creăm o bază de date de testare și un utilizator de testare:

CREATE DATABASE test_database;
CREATE USER test_user CU parola "qwerty" ;
ACCORDĂ TOATE PE BAZĂ DE DATE baza_de_date_test CĂTRE utilizator_test;

Pentru a ieși din shell, introduceți comanda \q .

Acum să încercăm să lucrăm cu baza de date creată în numele test_user:

psql -h localhost test_database test_user

Să creăm un tabel nou:

CREATE SEQUENCE user_ids;
CREATE TABLE utilizatori (
id INTEGER PRIMARY KEY DEFAULT NEXTVAL ("user_ids") ,
autentificare CHAR(64) ,
parola CHAR(64));

Vă rugăm să rețineți că, spre deosebire de alte SGBD, PostgreSQL nu are coloane cu proprietatea auto_increment. În schimb, Postgres folosește secvențe. Pentru moment, este suficient să știm că folosind funcția nextval putem obține numere unice pentru o anumită secvență:

SELECTAȚI NEXTVAL ("user_ids" );

Prin setarea valorii implicite pentru câmpul ID din tabelul utilizatorilor la NEXTVAL ("user_ids"), am obținut același efect pe care îl dă auto_increment. La adăugarea de noi înregistrări în tabel, nu trebuie să specificăm id-ul, deoarece va fi generat automat un id unic. Mai multe tabele pot folosi aceeași secvență. Astfel, putem garanta că valorile unor câmpuri din aceste tabele nu se suprapun. În acest sens, secvențele sunt mai flexibile decât auto_increment.

Același tabel poate fi creat folosind o singură comandă:

CREATE TABLE users2 (
id CHEIE PRIMARĂ DE SERIE ,
autentificare CHAR(64) ,
parola CHAR(64));

În acest caz, secvența pentru câmpul id este creată automat.

Acum folosind comanda \d puteți vedea o listă cu toate tabelele disponibile, iar folosind \d utilizatorii puteți vedea o descriere a tabelului utilizatori. Dacă nu obțineți informațiile pe care le căutați, încercați \d+ în loc de \d . Puteți obține o listă de baze de date cu comanda \l și puteți trece la o anumită bază de date cu comanda \c dbname. Pentru a afișa ajutorul comenzii, spuneți \? .

Este important de reținut că PostgreSQL convertește numele tabelelor și coloanelor în litere mici în mod implicit. Dacă nu doriți acest comportament, puteți utiliza ghilimele duble:

CREATE TABLE „otherTable” („someValue” VARCHAR (64) ) ;

O altă caracteristică a PostgreSQL care poate cauza dificultăți atunci când începeți să lucrați cu acest SGBD sunt așa-numitele „scheme”. O schemă este ceva ca un spațiu de nume pentru tabele, ca un director cu tabele în interiorul unei baze de date.

Crearea unei scheme:

CREATE SCHEMA rezervări;

Comutați la schemă:

SETĂ search_path TO rezervări;

Vizualizați lista schemele existente puteți folosi comanda \dn. Schema implicită este denumită public. În principiu, puteți utiliza cu succes PostgreSQL fără să știți despre existența schemelor. Dar atunci când lucrați cu cod vechi și în unele cazuri marginale, cunoașterea schemelor poate fi foarte utilă.

În caz contrar, lucrul cu PostgreSQL nu este mult diferit de lucrul cu orice alt SGBD relațional:

INSERT INTO utilizatori (login, parola)
VALORI ("afiskon" , "123456" );
SELECT * FROM utilizatori;

Dacă acum încercați să vă conectați la Postgres de pe o altă mașină, veți eșua:

psql -h 192.168.0.1 test_database test_user

Psql: nu s-a putut conecta la server: conexiune refuzată
Serverul rulează pe gazda „192.168.0.1” și acceptă
Conexiuni TCP/IP pe portul 5432?

Pentru a remedia acest lucru, adăugați linia:

listen_addresses = "localhost,192.168.0.1"

... și în fișierul /etc/postgresql/9.2/main/postgresql.conf.

Postgres Pro este un SGBD rusesc dezvoltat de Postgres Professional bazat pe SGBD PostgreSQL distribuit gratuit. Postgres Pro este inclus în registrul software rusesc (a se vedea https://reestr.minsvyaz.ru/reestr/65273/)

În acest fel, clienții pot accesa beneficiile de funcționalitate și performanță care îi avantajează fără a fi nevoiți să aștepte o nouă lansare PostgreSQL (care poate dura până la un an). În calitate de autori, oferim sprijin pentru toate dezvoltările noastre. În calitate de reprezentanți ai comunității internaționale a dezvoltatorilor PostgreSQL, oferim și suport comercial pentru SGBD PostgreSQL distribuit gratuit.

Comparația versiunilor PostgreSQL

SGBD	PostgreSQL Afacere	PostgreSQL Standard	PostgreSQL
	Un DBMS comercial dezvoltat de Postgres Professional pentru aplicații critice și sarcini mari.	SGBD rusesc open source dezvoltat de Postgres Professional pe baza SGBD PostgreSQL distribuit gratuit	Un SGBD distribuit gratuit dezvoltat de comunitatea internațională.

Registrul unificat al software-ului rusesc	✓	✓
Contor de tranzacții pe 64 de biți	✓
Backup incremental la nivel de bloc	✓
Certificat FSTEC SVT 5, NDV 4	✓	✓
Tranzacții autonome	✓
Tabele de partiționare	✓	✓	✓
Comprimarea datelor	✓
Multimaster	✓
Suport 1C	✓	✓	✓
Mese portabile	✓
Sugestii pentru planificator	✓

Versiuni PostgreSQL

Numărul versiunii PostgreSQL este derivat din numărul versiunii PostgreSQL cu adăugarea unei cifre care indică numărul lansării curente. Când este lansată o nouă versiune minoră de PostgreSQL (acest lucru se întâmplă de obicei când apar patch-uri legate de securitate și corectarea erorilor grave), numerotarea PostgreSQL este resetată la una. De exemplu, când PostgreSQL 9.5.1 este lansat, PostgresPro 9.5.1.1 este lansat, apoi înainte de lansarea PostgreSQL 9.5.2, Postgres Pro 9.5.1.2, 9.5.1.3 etc. poate fi lansat. Când PostgreSQL 9.5.2 este lansat, Postgres Pro va fi actualizat la versiunea 9.5.2.1 etc.

Concomitent cu lansarea cod sursa Postgres Pro publicăm ansamblurile noastre ca pachete sub diverse platforme. Acestea sunt următoarele OSși versiunile lor:

Linux
- CentOS 6/7
- Debian 7/8
- Ubuntu 12.04/14.04/16.04/16.10,
- Oracle Linux,
- server Rosa Enterprise Linux,
- Server ROSA SX Cobalt,
- Server ROSA DX Cobalt,
- ROSA Marathon LTS 2012,
- Alt Linux Centaur 8,
- Alt Linux SPT 6,
- Alt Linux SPT 7,
- SUSE Linux Enterprise Server,
Microsoft ® Windows ® 2012 sau 2016.

Bazele de date Postgres Pro 9.5.*.* sunt compatibile cu PostgreSQL 9.5.* La actualizarea de la 9.5, nu este necesară dump/restaurare. La mutarea de la mai mult versiuni anterioare PostgreSQL necesită utilizarea dump/restore sau pg_upgrade.

Versiunea actuală a Postgres Pro Standard este 11.2.1. Data lansării - 28 martie 2019. .

Diferențele dintre Postgres Pro Standard și PostgreSQL

În PostgreSQL Standard vs. Versiune curentă PostgreSQL include în prezent următoarele modificări:

Îmbunătățiri ale performanței sistemelor multi-core:
- optimizarea alocării tabelelor hash în memoria partajată, eliminând disputa de blocare pentru un număr mare de procese.
- Optimizarea proprietarului resurselor. Îmbunătățește performanța interogărilor complexe și a interogărilor împotriva tabelelor cu un număr mare de partiții.
- Optimizări ale managerului de buffer
- Optimizare LWLock pentru arhitectura Power8
- Optimizări de comitere în două faze
Îmbunătățiri ale căutării text integral:
- suport pentru căutarea expresiei
- suport pentru dicționare hunspell pentru lucrul cu forme de cuvinte
- unele dicționare, inclusiv rusă și engleză, sunt incluse în distribuție și conectarea lor necesită o comandă SQL
- modulul shared_ispell, care optimizează performanța căutării full-text prin încărcarea dicționarelor în memorie la pornirea serverului și nu la începutul sesiunii.
Indici de acoperire. Suport pentru constructia INCLUDING din CREATE INDEX.
Portabilitate: libicu este acceptat pe toate platformele, oferind o gestionare neechivocă a ordinii de sortare și a altor operațiuni cu caractere Unicode. Pe o serie de platforme, această bibliotecă îmbunătățește performanța de sortare și, mai important, permite Postgres Pro să folosească chei abreviate, care au fost dezactivate în versiunea principală a PostgreSQL.
Modulul pg_trgm nu acceptă doar compararea șirurilor neclare, ci și căutarea subșirurilor fuzzy.
Modulul pageinspect acceptă accesul nu numai la metainformații, ci și la reprezentarea internă a datelor din tabel.
A fost adăugat un nou modul, sr_plan, care vă permite să salvați planurile de execuție a interogărilor și să utilizați planuri salvate în loc să generați din nou un plan de interogare de fiecare dată când este executat.
A fost adăugat modulul dump_stat, care vă permite să salvați informații despre statistici și să le restaurați atunci când descărcați o bază de date. Acest lucru vă permite să accelerați procesul de recuperare prin eliminarea necesității de a calcula statistici cu comanda VACUUM ANALYZE după recuperare.
S-a adăugat modulul JSQuery care permite limbaj special formulați interogări la câmpuri de tip JSONB cu suport pentru indici GIN.
Modulul oferă un tip de date suplimentar pentru compatibilitate cu Microsoft SQL Server.
Modulul oferă un operator de egalitate suplimentar pentru compatibilitate cu Microsoft SQL Server.
Modulul oferă o funcție nesigură din punct de vedere tranzacțional pentru trunchierea tabelelor temporare, împiedicând creșterea directorului pg_class.
Modulul oferă un set de funcții care actualizează imediat statisticile pe tabelele țintă după operațiunile INSERT, UPDATE, DELETE și SELECT INTO pe acestea.
Modulul adaugă suport pentru instrucțiuni la planificator, permițându-vă să dezactivați sau să activați anumiți indecși atunci când executați o interogare.

Puteți afla mai multe despre diferențele dintre PostgreSQL și PostgreSQL în Tabelul de comparare a produselor.

Licență standard PostgreSQL

Postgres Pro Standard este distribuit sub licența PostgreSQL cu suplimente Postgres Professional:

Se acordă drepturi de utilizare, copiere, modificare și distribuire a acestui software și a documentației sale în scopuri de testare, dezvoltare software, familiarizare cu funcționalitatea SGBD, utilizare în proces educațional gratuit și fără semnarea vreunui acord, cu condiția ca odată cu fiecare copie să fie furnizate notificarea de copyright de mai sus, paragraful actual și următoarele patru paragrafe. Utilizarea în alte scopuri, integrarea în alte produse, replicarea și alte acțiuni necesită achiziționarea unei licențe separate.

Universitatea California nu își asumă nicio responsabilitate pentru nicio daune, inclusiv pierderea de venit, care decurg direct sau indirect, special sau incidental, din utilizarea acestui software sau a documentației sale, chiar dacă Universitatea din California a fost informată cu privire la posibilitatea unor astfel de daune. .

Universitatea din California declină în mod special orice garanție de orice fel, inclusiv, dar fără a se limita la, garanțiile implicite de vandabilitate sau potrivire pentru un anumit scop. Acest software este furnizat „ca atare”, iar Universitatea din California nu are nicio obligație de a furniza întreținere, asistență, actualizări, îmbunătățiri sau modificări.

Compania cu răspundere limitată profesională Postgres nu își asumă nicio răspundere pentru orice daune, inclusiv pierderea de venituri, cauzate de utilizarea directă sau indirectă, specială sau accidentală a acestui software sau a documentației acestuia, chiar dacă Compania cu răspundere limitată profesională Postgres a fost informată cu privire la posibilitatea unei astfel de daune. .

Compania cu răspundere limitată profesională Postgres declină în mod special orice garanție, inclusiv, dar fără a se limita la, garanțiile implicite de vandabilitate sau potrivire pentru un anumit scop. Acest software este furnizat „ca atare”, iar Postgres Professional Limited Liability Company nu este obligată să ofere întreținere, asistență, actualizări, extensii sau modificări.