, la plej nova versio de "la plej bona malferma fonta interrilata datumbazo de la mondo", aperos post kelkaj semajnoj (se ĉio iras laŭ plano). Ĉi tio sekvas la kutiman horaron publikigi novan version kun amaso da novaj funkcioj unufoje jare, kaj sincere, tio estas impona. Tial mi fariĝis aktiva membro de la komunumo PostgreSQL.
Laŭ mi, male al antaŭaj eldonoj, PostgreSQL 12 ne enhavas unu aŭ du revoluciajn funkciojn (kiel dispartigo aŭ demanda paralelismo). Mi iam ŝercis, ke la ĉefa trajto de PostgreSQL 12 estas pli granda stabileco. Ĉu vi ne bezonas tion kiam vi administras la kritikajn datumojn de via komerco?
Sed PostgreSQL 12 ne ĉesas tie: kun novaj funkcioj kaj plibonigoj, aplikoj funkcios pli bone, kaj ĉio, kion vi devas fari, estas ĝisdatigi!
(Nu, eble rekonstruu la indeksojn, sed en ĉi tiu eldono ĝi ne estas tiel timiga kiel ni kutimis.)
Estos bonege ĝisdatigi PostgreSQL kaj tuj ĝui signifajn plibonigojn sen nenecesa tumulto. Antaŭ kelkaj jaroj, mi reviziis ĝisdatigon de PostgreSQL 9.4 al PostgreSQL 10 kaj vidis kiel la aplikaĵo plirapidiĝis danke al la plibonigita demanda paralelismo en PostgreSQL 10. Kaj, plej grave, preskaŭ nenio estis postulata de mi (nur starigu agordan parametron). max_parallel_workers).
Konsentu, estas oportune kiam aplikaĵoj funkcias pli bone tuj post ĝisdatigo. Kaj ni tre klopodas plaĉi al uzantoj, ĉar PostgreSQL havas pli kaj pli da ili.
Do kiel simpla ĝisdatigo al PostgreSQL 12 povas feliĉigi vin? Mi diros al vi nun.
Gravaj indeksaj plibonigoj
Sen indeksado, datumbazo ne iros malproksimen. Kiel alie vi povas rapide trovi informojn? La fundamenta indekssistemo de PostgreSQL estas nomita . Ĉi tiu speco de indekso estas optimumigita por stokadsistemoj.
Ni simple uzas la operatoron CREATE INDEX ON some_table (some_column), kaj PostgreSQL faras multan laboron por konservi la indekson ĝisdatigita dum ni konstante enmetas, ĝisdatigas kaj forigas valorojn. Ĉio funkcias per si mem, kvazaŭ per magio.
Sed PostgreSQL-indeksoj havas unu problemon - ili kaj okupas kroman diskospacon kaj reduktas la rendimenton de datum-reakiro kaj ĝisdatigo. Per "blovi" mi celas senefike konservi la indeksan strukturon. Ĉi tio povas - aŭ eble ne - rilati al la rubopoj kiujn ĝi forigas (dankon al Peter Gaghan pro la informo))). Indeksa ŝvelaĵo estas precipe videbla en laborŝarĝoj kie la indekso aktive ŝanĝiĝas.
PostgreSQL 12 multe plibonigas la rendimenton de B-arbaj indeksoj, kaj eksperimentoj kun komparnormoj kiel TPC-C montris, ke averaĝe 40% malpli da spaco nun estas uzata. Nun ni pasigas malpli da tempo ne nur pri konservado de B-arbaj indeksoj (t.e. pri skribaj operacioj), sed ankaŭ por retrovi datumojn, ĉar la indeksoj estas multe pli malgrandaj.
Aplikoj kiuj aktive ĝisdatigas siajn tabelojn - tipe OLTP-aplikoj () - multe pli efike uzos diskon kaj prilaboros petojn. Ju pli da diskospaco, des pli da spaco la datumbazo devas kreski sen ĝisdatigi la infrastrukturon.
Kelkaj ĝisdatigaj strategioj postulas rekonstrui B-arban indeksojn por utiligi tiujn avantaĝojn (ekz. ne rekonstruos indeksojn aŭtomate). En antaŭaj versioj de PostgreSQL, rekonstrui grandajn indeksojn sur tabeloj rezultigis signifan malfunkcion ĉar ŝanĝoj ne povis esti faritaj intertempe. Sed PostgreSQL 12 havas alian bonegan funkcion: nun vi povas rekonstrui indeksojn paralele kun la komando por tute eviti malfunkcion.
Estas aliaj plibonigoj al la indeksa infrastrukturo en PostgreSQL 12. Alia afero kie estis iom da magio - , alinome WAL (skribi-antaŭa protokolo). Antaŭskriba protokolo registras ĉiun transakcion en PostgreSQL en kazo de fiasko kaj reproduktado. Aplikoj uzas ĝin por arkivado kaj . Kompreneble, la antaŭskriba protokolo estas skribita al disko, kio povas influi rendimenton.
PostgreSQL 12 reduktis la superkoston de WAL-rekordoj, kiuj estas kreitaj de la indeksoj GiST, GIN kaj SP-GiST dum indekskonstruado. Ĉi tio disponigas plurajn palpeblajn avantaĝojn: WAL-rekordoj okupas malpli da diskospaco, kaj datumoj estas reluditaj pli rapide, kiel ekzemple dum katastrofa reakiro aŭ momenta reakiro. Se vi uzas tiajn indeksojn en viaj aplikaĵoj (ekzemple, geospacaj aplikaĵoj bazitaj en PostGIS multe uzas la GiST-indekson), ĉi tio estas alia funkcio, kiu signife plibonigos la sperton sen ajna peno viaflanke.
Dispartigo - pli granda, pli bona, pli rapida
PostgreSQL 10 enkondukita . En PostgreSQL 11 ĝi fariĝis multe pli facile uzebla. En PostgreSQL 12 vi povas ŝanĝi la skalon de sekcioj.
En PostgreSQL 12, la rendimento de la dispartiga sistemo fariĝis signife pli bona, precipe se estas miloj da sekcioj en la tabelo. Ekzemple, se demando influas nur kelkajn subdiskojn en tabelo kun miloj da ili, ĝi efektiviĝos multe pli rapide. Efikeco ne estas nur plibonigita por ĉi tiuj specoj de demandoj. Vi ankaŭ rimarkos kiom pli rapidaj INSERT-operacioj estas sur tabloj kun pluraj subdiskoj.
Registrado de datumoj uzante - Cetere, ĉi tio estas bonega maniero kaj jen ekzemplo — dividitaj tabloj en PostgreSQL 12 ankaŭ fariĝis pli efikaj. Kun COPY ĉio jam estis rapida, sed en PostgreSQL 12 ĝi absolute flugas.
Dank'al ĉi tiuj avantaĝoj, PostgreSQL permesas vin stoki eĉ pli grandajn datumajn arojn kaj faciligi ilin reakiri. Kaj neniu peno viaflanke. Se la aplikaĵo havas multajn sekciojn, kiel registrado de temposerio-datumoj, simpla ĝisdatigo signife plibonigos ĝian rendimenton.
Kvankam ĉi tio ne estas ĝuste "ĝisdatigo kaj ĝuu" plibonigo, PostgreSQL 12 permesas al vi krei fremdajn ŝlosilojn, kiuj referencas dividitajn tabelojn, igante la dispartigo plezuro labori kun.
KUN demandoj nur multe pliboniĝis
Kiam (alinome CTE, alinome KUN demandoj), mi ne povis atendi skribi artikolon pri . Ĉi tiu estas unu el tiuj funkcioj, kiuj akcelos la aplikon. Krom se, kompreneble, vi uzas CTE.
Mi ofte trovas, ke novuloj pri SQL amas uzi CTE-ojn; se vi skribas ilin laŭ certa maniero, vere sentas, ke vi skribas imperativan programon. Persone, mi ŝatis reverki ĉi tiujn demandojn por ĉirkaŭiri sen CTE kaj pliigi produktivecon. Nun ĉio estas malsama.
PostgreSQL 12 permesas vin enlini specifan tipon de CTE sen kromefikoj (SELECT), kiu estas uzata nur unufoje proksime de la fino de la peto. Se mi spurus la CTE-demandojn, kiujn mi reverkis, la plej multaj el ili falus en ĉi tiun kategorion. Ĉi tio helpas programistojn skribi klaran kodon, kiu nun ankaŭ funkcias rapide.
Plie, PostgreSQL 12 optimumigas SQL-ekzekuton mem, sen ke vi devas fari ion ajn. Kaj kvankam mi verŝajne ne bezonos optimumigi tiajn demandojn nun, estas bonege, ke PostgreSQL daŭre laboras pri demandoptimumigo.
Just-in-Time (JIT) - nun defaŭlte
Sur PostgreSQL 12-sistemoj kun subteno JIT-kompilo estas ebligita defaŭlte. Antaŭ ĉio, vi ricevas subtenon por iuj internaj operacioj, kaj due, demandoj kun esprimoj (la plej simpla ekzemplo estas x + y) en elektitaj listoj (kiujn vi havas post SELECT), agregaĵoj, esprimoj kun WHERE-frazoj kaj aliaj povas uzi JIT por plibonigi rendimenton.
Ĉar JIT estas ebligita defaŭlte en PostgreSQL 12, rendimento pliboniĝos per si mem, sed mi rekomendas testi la aplikaĵon en PostgreSQL 11, kiu enkondukis JIT, por mezuri demandan rendimenton kaj vidi ĉu vi bezonas agordi ion.
Kio pri la ceteraj novaj funkcioj en PostgreSQL 12?
PostgreSQL 12 havas multon da bonegaj novaj funkcioj, de la kapablo ekzameni JSON-datumojn per normaj SQL/JSON-vojesprimoj ĝis plurfaktora aŭtentigo kun parametro. clientcert=verify-full, kreis kolumnojn kaj multe pli. Sufiĉas por aparta afiŝo.
Kiel PostgreSQL 10, PostgreSQL 12 plibonigos ĝeneralan rendimenton tuj post la ĝisdatigo. Vi kompreneble povas havi vian propran vojon - provu la aplikaĵon en similaj kondiĉoj en la produktadsistemo antaŭ ol ebligi plibonigojn, kiel mi faris kun PostgreSQL 10. Eĉ se PostgreSQL 12 jam estas pli stabila ol mi atendis, ne maldiligentu en la testado. aplikoj ĝisfunde, antaŭ ol liberigi ilin en produktadon.
fonto: www.habr.com