PostgreSQL 9.1 Caratteristiche
In questo articolo si esplorano le caratteristiche introdotte nella recente versione 9.1 di PostgreSQL. Per una panoramica più ampia sulle funzionalità di PostgreSQL e sulla sua storia, si consulti “PostgreSQL - la storia finora”.
L'uscita di PostgreSQL 9.1 il 12 settembre 2011 ha inaugurato una nuova era per la comunità di PostgreSQL, per gli sviluppatori in generale e per 2ndQuadrant in particolare. Sono state infatti introdotte una serie di funzionalità che hanno visto la luce per la prima volta a livello mondiale, nel solco di una tradizione iniziata nelle versioni più recenti che vede PostgreSQL definire lo stato dell'arte nell'ambito dei sistemi di database relazionali (RDBMS).
La funzionalità principale introdotta nella 9.1 è la Replica Sincrona.
Disegnata e sviluppata dal CTO di 2ndQuadrant Simon Riggs, la Replica Sincrona risolve un problema diverso rispetto alla Replica Asincrona in Streaming introdotta nella 9.0, utilizzando al contempo il lavoro svolto in precedenza da Simon su Hot Standby. La replica sincrona permette di confermare che le modifiche effettuate da una transazione sono state trasferite su un secondo server sincrono, estendendo il livello standard di durabilità offerto dalla nozione di finalizzazione (_commit_) di una transazione. La durabilità, la ‘D’ in ACID (un acronimo per un insieme di concetti fondamentali per la gestione affidabile delle transazioni, molto popolare tra i sistemi di database), si riferisce alla proprietà che le transazioni finalizzate siano permanenti, sopravvivendo ad esempio a uno spegnimento imprevisto del server dovuto a una interruzione di energia elettrica.
La Replica Sincrona, per sua natura, ha un costo maggiore in termini di prestazioni rispetto alla Replica Asincrona; il server principale deve ricevere conferma che la transazione sia stata finalizzata sul server sincrono. Pertanto le prestazioni della Replica Sincrona sono sensibili alla latenza della connessione, specialmente su grandi distanze dove il limite teorico della velocità della luce diventa percettibile.
Tradizionalmente, il concetto generale di Replica Sincrona si applica a casi d'uso che richiedono un livello elevato di durabilità e al contempo possono tollerare agevolmente il costo in termini di prestazioni; un esempio classico sono i sistemi designati per la speculazione finanziaria, che impiegano costosi switch a bassa latenza.
Primo a livello mondiale tra i sistemi di database, PostgreSQL 9.1 consente all'applicazione di usare la Replica Sincrona in modo selettivo: è possibile stabilire il livello di durabilità a livello di utente, connessione, o persino di singola transazione, in base al valore dell'informazione trattata. Ad esempio, i dettagli del cliente o le transazioni finanziarie possono richiedere la durabilità massima offerta dalla Replica Sincrona; i dati di minor valore, come ad esempio gli archivi delle chat, possono invece evitare il costo intrinseco della Replica Sincrona, ingiustificato in tali casi.
Considerando che in generale la durabilità massima è richiesta soltanto da un piccolo insieme di dati estremamente importanti, diventa quindi evidente il valore di questa incredibile innovazione. Con PostgreSQL 9.1 la Replica Sincrona esce quindi dai confini tradizionali, che ammettevano solo casi d'uso molto specifici in cui era giustificabile il pagamento sistematico del costo elevato di latenza.
La Replica Sincrona richiede che l'utente specifichi una lista ordinata per priorità di uno o più server in standby. In caso di mancata disponibilità del server in standby sincrono, il server successivo nella lista è automaticamente promosso al ruolo di standby sincrono. Così facendo, il cluster mantiene le sue garanzie in termini di durabilità in modo affidabile e robusto.
Un'altra importante funzionalità in PostgreSQL 9.1 è l'aggiunta del supporto alle Estensioni, scritta da Dimitri Fontaine di 2ndQuadrant. Le Estensioni consentono agli utenti di installare software scritto da terze parti tramite un solo comando SQL, e di disinstallare o gestire tale Estensione con la stessa semplicità. Una Estensione è analoga a un pacchetto, e rappresenta un insieme di funzionalità che risolvono un particolare problema. Due esempi: un nuovo tipo di dato che rappresenta i codici ISBN; un insieme di funzioni crittografiche di uso comune.
In realtà PostgreSQL è da sempre estremamente estendibile, e questa caratteristica è stata già usata in una miriade di modi innovativi; ciò che mancava era la possibilità di gestire gli oggetti relativi a una estensione come una sola entità logica nel database. Questa funzionalità innovativa costituisce la base del progetto PGXN, sostenuto dalla comunità, che mira alla costruzione di un archivio centralizzato di estensioni di PostgreSQL. PGXN vuole fornire alla comunità PostgreSQL dei servizi simili a quelli forniti da CPAN alla comunità Perl: un software automatizzato per l'installazione di software prelevato da una repository centralizzata autorevole.
In PostgreSQL 9.1 continuano i miglioramenti incrementali, apportati dal consulente 2ndQuadrant Gregory Smith, alle prestazioni in scrittura e alla configurabilità del server, sotto la guida della sua vasta esperienza nell'ottimizzazione di carichi di lavoro molto intensi in scrittura. Greg ha lavorato nell'eliminare alcune chiamate a fsync() superflue (in cui si richiede al sistema operativo di finalizzare alcuni buffer su disco, in modo da soddisfare i requisiti di durabilità), migliorando notevolmente le prestazioni nei casi sopra menzionati. Greg ha inoltre semplificato la configurazione del server, implementando una formula euristica semplice e al contempo estremamente efficace per impostare automaticamente il parametro wal_buffers.
L'implementazione in PostgreSQL 9.1 di SQL/MED (Management of External Data), una parte dello standard SQL che describe come i database dovrebbero interagire con i dati memorizzati all'esterno, ha molte applicazioni utili. SQL/MED consente all'utente di definire “Foreign Tables” - tabelle che possono essere interrogate come le altre, ma che di fatto rappresentano arbitrarie sorgenti esterne di dati, come ad esempio un file CSV, una tabella in un diverso RDBMS, o persino un feed Twitter.
In PostgreSQL 9.1 sarà poi introdotta la serializzabilità vera; anche in questo caso si tratta di un primato mondiale. A partire da questa versione, il livello SERIALIZABLE di isolamento delle transazioni (il più alto possibile) in PostgreSQL si comporterà in modo seriale secondo la più rigorosa definizione matematica: la percezione dell'esecuzione delle transazioni sarà seriale per ciascun osservatore. In particolare, non sono più possibili occorrenze di alcune “lacune” nella percezione dell'esecuzione seriale, e precisamente dell'anomalia nota come “write-skew”, la quale può invece verificarsi in versioni precedenti di PostgreSQL, o in altri sistemi MVCC come ad esempio il database Oracle®. Grazie al lavoro di Kevin Grittner, amministratore di database dei Tribunali dello Stato del Wisconsin (USA), di Dan Ports, studente del Massachusets Institute of Technology (USA), e alla ricerca innovativa di Michael James Cahill, l'implementazione di PostgreSQL raggiunge questo obiettivo in modo significativamente efficiente, senza bloccare le transazioni oltre il necessario o causare deadlock, a differenza della implementazione precedente del livello SERIALIZABLE di isolamento delle transazioni.
Le query di tipo WITH, note anche come query con Common Table Expressions (CTE), vengono migliorate in PostgreSQL 9.1, raggiungendo un livello non visto né anticipato in alcun altro RDBMS, open source o meno. Le query di tipo WITH sono uno strumento utile, previsto dallo standard SQL, tramite il quale è possibile definire tabelle intermedie, che non persistono oltre il comando in cui vengono generate, in modo da scomporre una query complicata in più parti. Tali query, che possono essere impiegate per eseguire calcoli sofisticati di tipo ricorsivo su strutture ad albero, hanno inoltre trovato molte applicazioni innovative.
Marko Tikkaja di 2ndQuadrant ha migliorato le query WITH in modo da consentire comandi in scrittura, introducendo le CTE In Scrittura. Diventa quindi possibili impiegarle in svariati modi utili, come ad esempio lo spostamento di record da una tabella all'altra nell'ambito di un singolo comando, eseguito in modo atomico, e di una stessa snapshot. Tecniche di questo tipo sono ampiamente applicabili, ad esempio nella gestione delle tabelle partizionate, quando occorre spostare un gran numero di record in una nuova partizione.
