Bon vennari à tutti ! Manca sempre menu tempu prima chì u corsu lancia , cusì oghje spartemu a traduzzione di un altru materiale utile nantu à u tema.
In u stadiu di sviluppu Ci hè statu un travagliu impressiunanti fattu per migliurà a particionazione di a tavola. Tavule di partizione - Questa hè una funzione chì esisteva in PostgreSQL per un bellu pezzu, ma, per dì cusì, essenzialmente ùn esiste micca finu à a versione 10, in quale hè diventata una funzione assai utile. Avemu dichjaratu prima chì l'eredità di a tavola hè a nostra implementazione di partizioni, è questu hè veru. Solu stu metudu hà obligatu à fà a maiò parte di u travagliu manualmente. Per esempiu, sè vo vulete chì tuples sò inseriti in sezzioni durante l'INSERT, avete da cunfigurà triggers per fà questu per voi. A partizione per l'eredità era assai lenta è difficiuli di sviluppà funzionalità supplementari in cima.
In PostgreSQL 10, avemu vistu a nascita di "partizione dichjarativa", una funzione pensata per risolve parechji prublemi chì ùn sò micca solu solu cù u vechju metudu di eredità. Questu hà purtatu à un strumentu assai più putente chì ci hà permessu di split data horizontally!
Comparazione di caratteristiche
PostgreSQL 11 introduce un inseme impressiunanti di funzioni novi chì aiutanu à migliurà u rendiment è rende e tabelle partizionate più trasparenti per l'applicazioni.
1. Using Limiting Exceptions
2. Adds solu nodes
3. Solu per una tavula partizionata chì riferisce à una tavula micca partizionata
4. Indici deve cuntene tutte e culonni chjave di a partizione
5. Restrizzione di a seccione in i dui lati deve cuncordà
Produttività
Avemu ancu una bona nutizia quì! Un novu metudu aghjuntu . Stu novu algoritmu pò determinà e sezioni adattate fighjendu a cundizione di dumanda WHERE. L'algoritmu precedente, à u turnu, hà verificatu ogni sezione per stabilisce s'ellu puderia scuntrà a cundizione WHERE. Questu hà risultatu in un aumentu supplementu di u tempu di pianificazione cum'è u numeru di sezioni aumentava.
In 9.6, cù a particione via eredità, u routing di tuple in partizioni hè stata tipicamente fatta scrivendu una funzione di trigger chì cuntene una serie di dichjarazioni IF per inserisce a tupla in a partizione curretta. Queste funzioni ponu esse assai lente per eseguisce. Cù a partizione dichjarazione aghjuntu in a versione 10, questu funziona assai più veloce.
Utilizendu una tavula partizionata cù 100 partizioni, pudemu evaluà u rendiment di carica 10 milioni di fila in una tavola cù 1 colonna BIGINT è 5 colonne INT.
Prestazione di dumandà sta tavola per truvà un registru indexatu è eseguisce DML per manipulà un registru (aduprendu solu 1 processore):
Quì pudemu vede chì u rendiment di ogni operazione hè aumentatu significativamente da PG 9.6. E dumande SELECT vede assai megliu, soprattuttu quelli chì sò capaci di escludiri parechje partizioni durante a pianificazione di query. Questu significa chì u pianificatore pò saltà assai travagliu chì duverebbe fà prima. Per esempiu, i camini ùn sò più custruiti per rùbbriche innecessarii.
cunchiusioni
U particionamentu di a tavola hè cuminciatu à diventà una funzione assai putente in PostgreSQL. Permette di visualizà rapidamente e dati in ligna è pigliallu offline senza aspittà chì l'operazioni DML lenti è massive finiscinu.. Questu significa ancu chì e dati cunnessi ponu esse guardati inseme, vale à dì chì i dati chì avete bisognu ponu accede assai più efficaci. I migliuramenti fatti in questa versione ùn saria micca pussibule senza i sviluppatori, i revisori è i committers chì anu travagliatu incessantemente in tutte queste funzioni.
Grazie à tutti! PostgreSQL 11 pare fantasticu!
Eccu un articulu cusì curtu ma assai interessante. Condividi i vostri cumenti è ùn vi scurdate di iscrizzione , in quale u prugramma di u cursu serà delineatu in dettagliu.
Source: www.habr.com