, l'últim llançament de "la millor base de dades relacional de codi obert del món", sortirà d'aquí a un parell de setmanes (si tot va segons el previst). Això segueix el calendari habitual: una nova versió amb moltes funcions noves surt un cop l'any i, francament, és impressionant. Per això em vaig convertir en un membre actiu de la comunitat PostgreSQL.
Al meu entendre, a diferència de les versions anteriors, PostgreSQL 12 no conté una o dues funcions revolucionàries (com ara la partició o el paral·lelisme de consultes). Una vegada vaig fer broma que la característica principal de PostgreSQL 12 és una major estabilitat. No és això el que necessiteu quan gestioneu les dades crítiques de la vostra empresa?
Però PostgreSQL 12 no es limita a això: amb noves funcions i millores, les aplicacions funcionaran millor, Tot el que has de fer és actualitzar!
(Bé, potser fins i tot reconstruir índexs, però en aquesta versió no fa tanta por com estem acostumats.)
Seria fantàstic actualitzar PostgreSQL i gaudir immediatament de millores significatives sense gestos innecessaris. Fa uns quants anys, vaig analitzar l'actualització de PostgreSQL 9.4 a PostgreSQL 10 i vaig veure quina velocitat era l'aplicació a causa del paral·lelisme de consultes millorat a PostgreSQL 10. I, el més important, gairebé no em requeria res (només cal establir el paràmetre de configuració). max_parallel_workers).
D'acord, és convenient quan les aplicacions funcionen millor immediatament després de l'actualització. I ens esforcem molt per agradar als usuaris, perquè PostgreSQL en té cada cop més.
I com et fa feliç una senzilla actualització a PostgreSQL 12? Ara t'ho diré.
Millores importants en la indexació
Sense la indexació, la base de dades no anirà lluny. Com es pot trobar informació ràpidament? S'anomena el sistema d'indexació PostgreSQL fonamental . Aquest tipus d'índex està optimitzat per a sistemes d'emmagatzematge.
Només fem servir l'operador CREATE INDEX ON some_table (some_column), i PostgreSQL fa un gran treball per mantenir l'índex actualitzat mentre estem constantment inserint, actualitzant i suprimint valors. Tot funciona per si mateix, com per màgia.
Però els índexs PostgreSQL tenen un problema: ells i ocupa espai de disc addicional i es redueix el rendiment d'extracció i actualització de dades. Per "inflor" vull dir un manteniment ineficient de l'estructura de l'índex. Això pot estar relacionat o no amb les tuples escombraries que (gràcies a Peter Gagan per la informació))). La inflor de l'índex es nota especialment en les càrregues de treball on l'índex està canviant activament.
PostgreSQL 12 millora molt el rendiment dels índexs B-tree, i experiments amb proves com TPC-C han demostrat que ara s'utilitza l'espai, de mitjana, un 40% menys. Ara passem menys temps no només mantenint els índexs de l'arbre B (és a dir, escrivint operacions), sinó també recuperant dades, perquè els índexs s'han fet molt més petits.
Les aplicacions que actualitzen activament les seves taules solen ser aplicacions OLTP () serà molt més eficient pel que fa a l'ús del disc i al processament de consultes. Com més espai en disc, més espai té la base de dades per créixer sense actualitzacions d'infraestructura.
Algunes estratègies d'actualització requereixen que reconstruïu índexs d'arbre B per aprofitar aquests avantatges (per exemple, no reconstruirà els índexs automàticament). En versions anteriors de PostgreSQL, la reconstrucció d'índexs grans a les taules va provocar un temps d'inactivitat important perquè no es podia fer cap canvi durant aquest temps. Però PostgreSQL 12 té una altra característica interessant: ara podeu reconstruir índexs en paral·lel amb l'ordre per evitar completament el temps mort.
PostgreSQL 12 té altres millores a la infraestructura d'indexació. Una altra cosa on hi havia una mica de màgia... , també conegut com WAL (registre d'escriptura anticipada). El registre d'escriptura anticipada escriu totes les transaccions a PostgreSQL en cas d'error i replicació. Les aplicacions l'utilitzen per arxivar i . Per descomptat, el registre d'escriptura anticipada s'escriu al disc, i això pot afectar el rendiment.
PostgreSQL 12 ha reduït la sobrecàrrega dels registres WAL que creen els índexs GiST, GIN i SP-GiST quan es construeix un índex. Això té diversos avantatges tangibles: els registres WAL ocupen menys espai al disc i les dades es reprodueixen més ràpidament, com ara durant la migració per error o la recuperació puntual. Si utilitzeu aquests índexs a les vostres aplicacions (per exemple, les aplicacions geoespacials basades en PostGIS utilitzen molt l'índex GiST), aquesta és una altra característica que millorarà molt el rendiment sense cap esforç per part vostra.
Particions: més gran, millor, més ràpid
S'ha presentat PostgreSQL 10 . A PostgreSQL 11, s'ha tornat molt més fàcil d'utilitzar. A PostgreSQL 12, podeu escalar particions.
A PostgreSQL 12, el rendiment del sistema de particions ha millorat significativament, sobretot si hi ha milers de particions en una taula. Per exemple, si una consulta només afecta unes poques particions d'una taula amb milers d'elles, s'executarà molt més ràpid. Les millores de rendiment no es limiten a aquest tipus de consultes. També notareu quanta més rapidesa són les operacions d'INSERT a taules amb moltes particions.
Escriure dades utilitzant - Per cert, aquesta és una gran manera i aquí en teniu un exemple - a les taules particionades a PostgreSQL 12 també s'ha tornat més eficient. Tot va ser ràpid amb COPY, però a PostgreSQL 12 vola completament.
Aquests avantatges fan possible que PostgreSQL emmagatzemi conjunts de dades encara més grans i facin que siguin més fàcils de recuperar. I cap esforç per part teva. Si l'aplicació té moltes seccions, per exemple, escriu dades de sèries temporals, una simple actualització millorarà significativament el seu rendiment.
I tot i que això no és exactament una millora d'actualització i alegria, a PostgreSQL 12 podeu crear claus externes que facin referència a taules particionades per fer que treballar amb particions sigui un plaer.
AMB consultes acaba de millorar molt
Quan (també conegut com CTE, també conegut com AMB consultes), tenia ganes d'escriure un article sobre com . Aquesta és una d'aquestes característiques que acceleraran l'aplicació. A menys que, per descomptat, utilitzeu CTE.
Sovint noto que als principiants d'SQL els encanta utilitzar CTE: si els escriviu d'una determinada manera, teniu la sensació d'estar escrivint un programa imperatiu. Personalment, m'agradava reescriure aquestes consultes per desplaçar-me без CTE i augmentar la productivitat. Ara tot és diferent.
PostgreSQL 12 us permet integrar un tipus de CTE específic sense efectes secundaris (SELECT), que només s'utilitza una vegada al final de la sol·licitud. Si fes un seguiment de les consultes CTE que vaig reescriure, la majoria entrarien en aquesta categoria. Això ajuda els desenvolupadors a escriure codi clar que ara també és ràpid.
A més, PostgreSQL 12 optimitza l'execució SQL en si, no cal que feu res. Tot i que probablement no hauré d'optimitzar aquestes consultes ara, és fantàstic que PostgreSQL continuï treballant en l'optimització de consultes.
Just a temps (JIT): ara el predeterminat
En sistemes PostgreSQL 12 amb suport La compilació JIT està activada per defecte. Primer, obtens suport per a algunes operacions internes, i en segon lloc, consultes amb expressions (l'exemple més senzill és x + y) en llistes de selecció (que teniu després de SELECT), agregats, expressions amb clàusules WHERE i altres poden utilitzar JIT per millorar el rendiment.
Com que JIT està habilitat per defecte a PostgreSQL 12, el rendiment millorarà per si sol, però suggereixo provar l'aplicació a PostgreSQL 11, on es va introduir JIT per primera vegada, per mesurar el rendiment de la consulta i veure si cal ajustar alguna cosa.
Però, què passa amb la resta de les noves funcions de PostgreSQL 12?
PostgreSQL 12 té un munt de funcions noves interessants, des de la capacitat d'inspeccionar dades JSON mitjançant expressions de ruta estàndard SQL/JSON fins a l'autenticació multifactor amb un clientcert=verify-full, columnes generades i molt més. N'hi ha prou per a una publicació a part.
Igual que PostgreSQL 10, PostgreSQL 12 millorarà el rendiment general immediatament després de l'actualització. Per descomptat, podeu fer-ho a la vostra manera: proveu l'aplicació en condicions similars en un sistema de producció abans d'habilitar millores, com vaig fer amb PostgreSQL 10. Encara que PostgreSQL 12 ja sigui més estable del que esperava, no tingueu mandra provar aplicacions. bé, abans de llançar-los a producció.
Font: www.habr.com