Ing. AndreaFortibuoni - PostgreSQL

Transcript

1 Ing. AndreaFortibuoni PostgreSQL PostgreSQL è un ORDBMS (Object Relational Database Management System), ovvero è un sistema di gestione di database relazionali ad oggetti molto noto e molto potente, che estende alle basi di dati il paradigma di programmazione a oggetti consentendo quindi di sopperire alle mancanze del semplice modello relazionale (come SQLServer o MySQL), cioè gestire ed utilizzare dati di tipo strutturato. E' un prodotto OpenSource, mantenuto da un team mondiale di sviluppatori ed esperti. STORIA La storia di PostgreSQL (chiamato anche Postgres) parte nel lontano 1970 presso l'università di Berkeley in California, dove iniziò lo sviluppo di un database relazionale chiamato Ingres. Alcuni anni dopo Ingres fu trasformato in un prodotto commerciale dalla società Relational Technologies, società che in seguito cambiò nome in Ingres Corporation, per poi essere successivamente acquisita dalla Computer Associates. Nel 1986, il capo progetto di Ingres, il prof. Michael Stonebraker, che alcuni anni prima aveva lasciato il team di sviluppo di Berkeley per seguire la commercializzazione del prodotto, decise di ritornare all'accademia per dare vita ad un nuovo progetto postingres, che ne superasse i limiti. In particolare, puntava a fornire un supporto completo ai tipi di dati e la possibilità di definirne nuovi (UDF, User Defined Types): il team di sviluppo non fece altro che aggiungere delle caratteristiche objectoriented ad Ingres, e il nuovo progetto fu chiamato Postgres. Come il suo predecessore anche Postgres fu ben presto commercializzato e nel 1988 venne rilasciato il primo prototipo funzionante. In totale furono rilasciate 4 versioni dal 1988 al 1993, anno di terminazione del progetto. Ma sebbene il progetto fosse ufficialmente abbandonato, la licenza BSD (Berkeley Software Distribution) dava comunque modo agli sviluppatori Open Source di ottenere una copia del software per poi migliorarlo a loro discrezione. Fu così che nel 1994 due studenti del Berkeley, Andrew Yu e Jolly Chen, aggiunsero a Postgres un interprete SQL, per rimpiazzare il vecchio linguaggio di interrogazione ( Quel ) e il nuovo software fu rilasciato col nome di Postgres95. Nel 1996 fu nuovamente aggiornato e per evidenziare il supporto al linguaggio SQL si decise di rinominarlo in PostgreSQL. Il primo rilascio di PostgreSQL è stata la versione 6. Da allora ad occuparsi del progetto è una comunità di sviluppatori volontari provenienti da tutto il mondo che si coordina attraverso Internet, e la sua evoluzione non si è più fermata: alla prima versione seguirono nel 2005 la 8.0, nel 2006 la 8.2, nel 2008 la 8.3, nel 2009 la 8.4, nel 2010 la 9.0, fino ad arrivare alla attuale versione 9.1.

2 COSTI E LICENZE PostgreSQL utilizza una licenza in stile BSD (Berkeley Software Distribution), la quale richiede soltanto che il software mantenga le informazioni di licenza e di proprietà intellettuale del codice. Questa licenza certificata da OSI è unanimemente apprezzata per la sua natura flessibile e businessfriendly, in quanto non limita l'impiego di PostgreSQL con applicazioni proprietarie e commerciali. Insieme al supporto multiazienda e alla proprietà diffusa e pubblica del codice, questa licenza rende PostgreSQL molto popolare tra quei produttori che intendono incorporare il database all'interno dei loro prodotti specifici senza alcun timore di incappare in costi, forme di lockin o cambi nei termini e nelle condizioni di licenza. Diversamente da Oracle e SQL Server, che sono DBMS di tipo commerciale e necessitano il pagamento della licenza per utilizzarli, o da MySQL che anche se possiede una licenza GPL (General Public License) pone comunque limitazioni agli sviluppatori, la licenza BSD di Postgres non impone nessun tipo di vincoli, ma d altro canto non offre nessuna garanzia all'utente finale (come invece fa la GPL). PostgreSQL è indipendente al 100%: non è gestito da nessuna azienda, non appartiene a nessuno e non soffre di politiche aziendali o problemi di mercato. È nato come un esperimento e continua ad esserlo dopo oltre 20 anni. Viene sviluppato da una grande comunità di programmatori ed è finanziato da molte aziende interessate al progetto. Essendo un DBMS OpenSource, gli eseguibili e il codice sorgente sono disponibili gratuitamente online ( ). INSTALLAZIONE E PORTABILITÀ PostgreSQL gode di un ottima portabilità essendo un DBMS multipiattaforma e quindi compatibile con tutti i principali sistemi operativi: GNU/Linux, sistemi UNIXlike (come FreeBSD, Mac OS X, Solaris, ecc ) e a partire dalla versione 8.0 anche su Windows. L installazione di Postgres al giorno d oggi non presenta grosse difficoltà, basta scaricare dal sito principale ( l installer automatico relativo al proprio sistema operativo, lanciarlo e seguire le relative istruzioni. In passato invece si potevano scaricare solo i sorgenti e si dovevano poi compilare da terminale sulla propria macchina. L installer include oltre al database server: l applicativo client pgadmin che consente di amministrare il database in modo semplificato tramite interfaccia grafica, e lo StackBuilder ovvero un wizard utile per scaricare e installare componenti aggiuntivi, driver e varie applicazioni a completamento dell installazione. Durante l installazione è stato creato un utente postgres del sistema, che per PostgreSQL equivale all utente root (superutente); siamo noi a dover impostare la password per l utente postgres, e la porta sulla quale il server si mette in ascolto (di default è la 5432). Successivamente posso connettermi al database in 2 modi: da terminale usando il client psql, oppure sfruttando il client grafico pgadmin. I parametri da specificare per connettersi al database sono: nome del database (scelto a piacere, ad esempio: dbms_locale ), nome o indirizzo dell host (ad es: localhost ), il numero di porta, il nome utente e la relativa password. Una volta creata la connessione sarà possibile creare database, tabelle, inserire dati, creare utenti, effettuare query, ecc È importante ricordare che PostgreSQL gestisce un cluster di database, ovvero una collezione di più database possono risiedere sullo stesso host e sono gestiti da una singola istanza di un processo server in esecuzione. Appena installato, il cluster mette a disposizione un database vuoto, usato come template per la creazione di

3 altri database, detto template1. Tutte le caratteristiche di questo template possono essere modificate dall'utente, e saranno riflesse in ogni nuovo database creato (esiste anche una copia di sicurezza del template1, detto template0, che non può essere acceduto). In termini di file system, un cluster di database sarà una singola directory nella quale tutti i dati saranno salvati, e sarà creato dal processo initdb. Se si effettua l installazione tramite installer grafico, tale processo viene lanciato in automatico e la directory che rappresenta il cluster viene in generale chiamata data e posizionata nella directory principale di Postgres, mentre nell installazione tramite compilazione dei sorgenti da terminale può essere scelta la locazione di tale cartella. E possibile tuttavia definire dei TABLESPACES, che consentono un allocazione fisica diversa da quella che propone PostgreSQL e associata allo USER stesso, scelto durante la creazione/modifica di un database. Un esempio di cosa contiene la directory data del cluster: COMPATIBILITÀ CON STANDARD SQL/92 PostgreSQL è totalmente compatibile con lo standard SQL/92. Grazie ad alcuni comandi di questo standard può implementare molte funzioni che altri DBMS, come MySQL, non hanno. In particolare: implementare le viste attraverso il comando CREATE VIEW/DROP VIEW; le viste non solo consentono di proteggere parte dei dati da occhi ed accessi indesiderati, ma anche di rafforzare il controllo sull'integrità dei dati; creare tabelle temporanee che sono visibili solo dal client e sono automaticamente rimosse quando il client chiude la connessione; implementare le SELECT annidate. Postgres inoltre supporta ampiamente lo standard SQL/99 e anche lo standard SQL2003, consentendo la portabilità delle applicazioni e l uso di: Complex queries, Foreign keys, Triggers, Views, Transactional integrity (ACID), Multiversion concurrency control (MVCC). PostgreSQL supporta tutti i tipi di dato di questi standard ma non solo: li estende implementandone altri nuovi, come i dati geometrici e spaziali, binari, Large Objects, o definiti dall utente (UDT). Stessa cosa anche per le funzioni (UDF). Postgres, sin dalle sue origini, ha considerato l estendibilità un requisito base per poter far fronte alle nuove esigenze di gestione dati, e la sua caratteristica più rilevante è che, se non può essere reperito un qualcosa del quale si ha bisogno, è possibile aggiungerlo una volta trovato su Internet. Ecco una tabella riassuntiva dei tipi di dato compatibili con lo standard:

4 ARCHITETTURA Si utilizza il modello clientserver: i dati sono gestiti in modo centralizzato (server) e messi a disposizione di più fruitori (client). Essi possono coesistere sulla stessa macchina o possono risiedere su macchine distinte connesse con rete TCP/IP. In pratica un processo server accetta connessioni al database dalle applicazioni client, ed esegue azioni per mezzo dei client stessi. Un processo (detto anche programma) server è chiamato postgres, e si occupa di gestire le query ed i comandi dei client. Le applicazioni client (dette frontend ) possono essere di natura molto diversa: un client potrebbe essere uno strumento testuale, un'applicazione grafica, un server web che ha accesso al database per visualizzare pagine web, oppure uno strumento specializzato per la manutenzione del database. Alcune applicazioni client vengono fornite con la distribuzione di PostgreSQL, come quello a riga di comando (psql) e quello a interfaccia grafica(pgadmin). Altre possono essere sviluppate dagli utenti e sono reperibili online, come quello a interfaccia web basata sul PHP e chiamato phpgadmin, o come quello basato su Java e chiamato xpg. Poiché è impossibile conoscere in anticipo quante connessioni verranno fatte, è presente un processo server principale che è il padre di ogni processo, che si occupa della gestione delle connessioni e che genera

5 (ovvero forka ) un nuovo processo server postgres ogni volta che viene richiesta una connessione. Questo processo principale è chiamato postmaster e rimane in ascolto (nella specifica porta TCP / IP) di connessioni in entrata: le applicazioni client (dette frontend ) che desiderano accedere ad uno dei database gestiti dal postmaster ricorrono a funzioni appartenenti alla libreria libpq, la quale invia le richieste di accesso al postmaster. A questo punto il postmaster genera un nuovo processo server postgres (detto anche backend ) per ogni client, al fine di servire più clienti in modo efficiente. Da questo momento in poi frontend e backend continuano a comunicare senza ulteriori interventi del postmaster, il quale rimane sempre in esecuzione, aspettando nuove richieste di connessioni. La comunicazione tra frontend e backend consiste nello scambio di pacchetti di richiesta e risposta, e per gestirla nel modo più adeguato Postgres utilizza un protocollo implementato su TCP/IP e sockets UNIX. Quando il frontend desidera disconnettersi invia un pacchetto appropriato e termina, senza attendere risposta dal backend. Per modificare a piacimento alcuni parametri come politiche di accesso, configurazioni del server, impostazioni di connessione e di autenticazione dei client o altre simili, basta agire sui file di configurazione postgresql.conf e pg_hba.conf presenti all interno della directory del cluster (ovvero data ). A fronte di una richiesta di query da parte del frontend, il backend esegue i seguenti passi: passa la stringa rappresentante la query al Parser, che la analizza sintatticamente; il Traffic Cop decide se il comando deve essere ottimizzato (ho una complex Query ) o meno (comandi di utility); nel caso debba essere ottimizzato il Rewriter considera le regole e riscrive la query corretta; l'ottimizzatore calcola il percorso migliore; infine l'executor esegue la query e ritorna il risultato. La creazione del cluster genera quindi: il catalogo di sistema, le directory che andranno ad ospitare i file specifici dell istanza server e i due database template0 e template1. Il catalogo di sistema è costituito da un insieme di tabelle e viste, comuni a tutti database del cluster, e dal dizionario dati. Il dizionario dati si occupa del parsing dei comandi SQL a fronte di una query e viene adoperato dall ottimizzatore (detto anche planner ) per la risoluzione del piano di esecuzione. Quando si crea un database (a partire dal template1), esso contiene uno o più schemi identificati con nomi, che a loro volta contengono le tabelle che si vogliono creare, e anche altri tipi di oggetti come tipi di dati, funzioni, viste ecc... Diversamente da come avviene per i database, gli schemi non sono separati rigidamente: un utente può accedere ad oggetti in qualunque schema presente nel database al quale è connesso, se ne ha i privilegi. Se si creano tabelle senza specificare alcun nome di schema, per impostazione predefinita queste tabelle (e gli altri oggetti) vengono automaticamente inseriti in uno schema chiamato "public". Oltre allo schema public e a

6 quelli creati dall'utente, ogni database ha uno schema pg_catalog caratteristico del catalogo di sistema e che contiene tutte le tabelle di sistema e tutti i tipi di dati predefiniti, funzioni,viste ecc... Le principali viste di sistema sono: pg_user: vista della tabella pg_shadow, che fornisce informazioni sugli utenti; pg_tables: fornisce informazioni sulle tabelle del cluster; pg_settings: fornisce informazioni sui parametri runtime dell'istanza server; pg_database: fornisce informazioni sui database presenti nel cluster; pg_statistic: contiene le statistiche degli oggetti del cluster. ALLOCAZIONE DATI L unità base per l archiviazione dei dati in PostgreSQL è la pagina, di dimensioni 8 Kb. Ogni oggetto del cluster, dai vari database alle tabelle, è identificato da un numero che viene chiamato Object identifier (OID). Tipicamente un database è rappresentato da una directory (con lo stesso nome dell OID

7 corrispondente), mentre una tabella è memorizzata fisicamente come un singolo file (con lo stesso nome dell OID corrispondente), strutturato logicamente come un insieme contiguo di pagine: La pagina contiene una serie di puntatori lineari (linear pointer o linp ) che indirizzano le tuple contenute nella pagina stessa. All'interno della pagina la singola tupla è acceduta per mezzo di un offset, ma indirettamente per consentire una migliore gestione: l'offset della tupla infatti non identifica la tupla stessa, ma il puntatore linp. In questo modo è possibile spostare la tupla (es: compattazione dello spazio) senza doverne cambiare l'offset. Le tuple sono organizzate a stack: ogni nuova tupla viene inserita in fondo subito prima delle altre mentre il linp viene inserito all'inizio dopo gli altri. La struttura di una tupla è la seguente:

8 Per motivi essenzialmente prestazionali, è possibile partizionare le tabelle, secondo una delle seguenti modalità: Range partitioning: ogni partizione contiene un certo range di chiavi List partitioning: vengono elencate esplicitamente le chiavi per ogni partizione Uno dei vantaggi di avere tabelle partizionate è quello di poter restringere l insieme dei dati da esaminare per risolvere una query. Ne consegue un notevole risparmio di risorse. Il tutto si basa su una caratteristica objectrelational di PostgreSQL, ovvero l ereditarietà o TABLE INHERITANCE. Tale caratteristica risponde a necessità di modellazione che non sono naturalmente soddisfatte dal modello relazionale: l'ereditarietà infatti consente a una tabella di ereditare alcuni dei suoi attributi di colonna da una o più altre tabelle, creando una relazione padrefiglio. Questo fa sì che la tabella figlio abbia, oltre le sue, anche le stesse colonne e vincoli della tabella (o tabelle) padre ereditata. L'ereditarietà delle tabelle è tipicamente stabilita quando la tabella figlia viene creata, usando la clausola INHERITS del comando CREATE TABLE. Ecco un esempio: CREATE TABLE name population altitude ); cities ( text, real, int CREATE TABLE capitals ( state char(2) ) INHERITS (cities); In questo caso, una riga della tabella capitals eredita tutte le colonne (name, population, and altitude) dal suo genitore, cities. Se effettuo una query per trovare tutte le città che non sono capitali e per esempio sono situate ad un'altezza maggiore di 500 piedi, dovrò usare la clausola ONLY, la quale indica che la query deve essere applicata solo sulla tabella cities, e non sulle tabelle sotto cities nella gerarchia di ereditarietà: SELECT name, altitude FROM ONLY cities WHERE altitude > 500;

9 Alternativamente, ad una tabella che è già definita in modo compatibile, è possibile aggiungere una genitore, usando la variante INHERIT di ALTER TABLE. Per fare questo la nuova tabella figlia deve già includere colonne con lo stesso nome e tipo delle colonne del genitore. Inoltre un collegamento di ereditarietà può essere rimosso da un figlio usando la variante NO INHERIT di ALTER TABLE. Un modo comodo per creare una tabella compatibile che successivamente diventerà una nuova figlia è di usare la clausola LIKE nel CREATE TABLE. Questo crea una nuova tabella con le stesse colonne della tabella sorgente. Una tabella genitore non può essere eliminata finché una delle sue figlie esiste. Nemmeno le colonne delle tabelle figlie possono essere eliminate o modificate se sono ereditate da tabelle genitrici. Se si desidera rimuovere una tabella e tutte le sue discendenti, un modo semplice è eliminare la tabella genitrice con l'opzione CASCADE. Da tener conto che tutti i vincoli CHECK e NOTNULL su una tabella genitore sono automaticamente ereditati da i suoi figli, mentre altri tipi di vincoli (come: unique, chiave primaria e chiave esterna) non sono ereditati. Inoltre non tutti i comandi SQL riescono a lavorare con le gerarchie di ereditarietà: quelli che la supportano sono i comandi usati per le query, per la modifica dei dati o la modifica degli schemi (ad esempio: SELECT, UPDATE, DELETE, molte varianti di ALTER TABLE, ma non INSERT e ALTER TABLE con RENAME). Le pagine dati caricate sono contenute in una zona di memoria detta shared memory, condivisa da tutti i processi backend: PostgreSQL non cambia direttamente le informazioni su un disco ma le scrive sullo shared buffer cache. Le informazioni vengono prelevate dal disk buffer cache o direttamente dal disco. I processi di backend accedono allo shared buffer e se ad esempio bisogna effettuare un processo di lettura allora la lettura avviene tutta in RAM. Lo shared buffer deve avere la giusta dimensione per consentire agli altri programmi di girare senza intoppi. Se lo shared buffer è troppo grande, allora il sistema operativo inizierà il processo di swap per richiedere memoria per gli altri programmi in esecuzione, e si avrà rallentamento. La configurazione di default alloca in genere 1000 buffer condivisi, ognuno di dimensione 8 Kb. Aumentare il numero di buffer aumenta le probabilità di trovare nella cache le informazioni di cui i backend hanno bisogno, evitando così una costosa richiesta del sistema operativo.

10 Per accedere in maniera rapida ai dati si sfrutta il concetto di indice. Postgres memorizza gli indici in modo disgiunto dalla tabella alla quale puntano (indici secondari ). Un indice viene memorizzato e gestito come una normale tabella, e quindi è presente nel catalogo di sistema ( pg_index ) e viene acceduto e gestito dal buffer manager. Ogni indice memorizza una coppia <key, TIDs> dove i Tuple Identifiers sono coppie <numero_blocco_dati, offset_linp> per recuperare la pagina dati e la tupla all'interno della pagina dati. In Postgres i principali tipi di indici sono 4, ognuno dei quali si basa su un diverso algoritmo: BTree: sono quelli di default, vengono usati per query di uguaglianza e di intervalli dati con operatori del tipo: <, =, >. Esempio: CREATE INDEX nomeindice ON nometabella (elencocampi); Hash: indicato quando si confronta l uguaglianza fra due campi. Anche in questo caso è necessario specificare, in fase di creazione, il tipo di indice: CREATE INDEX nomeindice ON nometabella USING HASH (elencocampi); GiST: Generalized Index Search Tree, forniscono una interfaccia per l'integrazione di indici userdefined (es. indici multidimensionali RTree ) e sono usati nelle query che utilizzano gli operatori spaziali e geometrici ~=, &&, ecc ); GiN: Generalized Inverted Index, sono indici invertiti che possono gestire valori che contengono più di una chiave, per esempio gli array. Utilizzano una coppia <chiave, posting_list> con i posting_list pointer che puntano ai documenti che contengono la chiave. Un indice può essere definito su più campi. In questo caso è necessario indicare per primi quelli che vengono utilizzati più spesso nelle query. Postgres non fa eccezione, se ad esempio, si definisce un indice su tre colonne c1, c2, c3; questo viene utilizzato nel caso in cui nella condizione di where vengano utilizzate le colonne c1, c2, c3 oppure c1,c2 o c1. Nel caso c1, c3, verrebbe utilizzato l indice solo per la colonna c1. Esistono alcune limitazioni all uso degli indici definiti su più campi: sono supportati solo dai BTree e sono utilizzati solo con l operatore AND; inoltre il numero di colonne può essere al massimo 32 (ma in genere più di 3 colonne sono poco performanti e quindi inutili). È anche possibile definire indici unici, cioè che non contengono valori ripetuti (escluso il NULL), ma solo per indici di tipo BTree: CREATE UNIQUE INDEX nomeindice ON nometabella (elencocampi).gli indici unici sono creati automaticamente per le primary key. In Postgres è possibile definire indici basati sul risultato di una funzione applicata ad una o più colonne della tabella. Per esempio supponiamo di dover eseguire spesso una query di questo tipo: select * from tabella where upper(col1) = valore. Un indice definito sul campo col1 non verrebbe utilizzato in quanto la funzione upper ne modifica il valore che non è quindi confrontabile con quello memorizzato nell indice. In questo caso è necessario definire un indice calcolato con la funzione upper: CREATE INDEX nomeindice ON nometabella (upper(col1)). Questo tipo di indice è sempre composto da una sola colonna.

11 È possibile inoltre definire indici parziali, che servono a escludere valori comuni o valori di scarso interesse per le query. Esempio: CREATE INDEX nomeindice ON nometabella (campo) WHERE campo >= condizione. Anche se in Postgres gli indici non richiedono manutenzione, è comunque importante controllare quali indici vengono realmente usati nei cicli di lavoro delle query. L'esame di utilizzo degli indici per una singola query viene fatto con il comando EXPLAIN, che illustra il piano di query generato dal pianificatore: EXPLAIN [ ANALYZE ] statement, dove ANALYZE se è attivato permette di aggiornare le statistiche che l ottimizzatore di query utilizzerà per svolgere i suoi compiti. Ad esempio il commando: EXPLAIN SELECT * FROM mytable; producerà in output: QUERY PLAN Seq Scan on mytable (cost= rows=10000 width=244) Il costo di accesso tramite indice viene effettuato mediante la stima del numero di tuple restituite e dell'operatore applicato, assieme alle statistiche sulle colonne coinvolte. Gli operatori utilizzati per l accesso ai dati possono essere: sequential_scan: accetta come parametro di input una tabella e restituisce le sole righe specificate dalla clausola where. Ha il vantaggio di lavorare in stream, ovvero durante l esecuzione del sequential scan le righe ritrovate sono già disponibili per il successivo operatore oppure per la restituzione al backend. Questo operatore lavora per sottrazione. Legge ogni riga della tabella ed eventualmente scarta quelle che non corrispondono alla clausola di where. index_scan: accetta come parametro di input un indice definito su di una o più colonne di tabella e restituisce le sole voci di indice specificate dalla clausola di where. Ha il vantaggio di lavorare per intervallo (range), ovvero definito un valore massimo e un minimo nella condizione where, l indice viene attraversato solo per quei valori. A differenza del sequential_scan, l index_scan restituisce i dati già ordinati.

12 bitmap_scan: esegue una lettura sequenziale delle pagine index ma senza seguire l indice. La lettura avviene in maniera simile ad un sequential_scan. Una volta in memoria gli indici vengono trasformati in bitmap e sommati per trovare le occorrenze che soddisfano il filtro. join: accetta due set di righe in ingresso e restituisce un unica riga prodotta dall affiancamento delle righe in ingresso. Si suddivide in: Nested Loop Join, Merge Join, Hash Join. sort: accetta come input un set di dati e li restituisce ordinati. Non lavora in stream, ovvero richiede l intero set per poter ordinare. limit: accetta come input un set di dati e restituisce solo i primi x specificati nella clausola di avvio. unique: accetta come input un set di dati e scarta i valori duplicati. Quando si va a leggere una tabella attraverso un index_scan i blocchi di indice vengono letti in maniera ordinata. Quando viene trovata una corrispondenza Postgres carica nello shared_buffer la pagina corrispondente alla corrispondenza ed estrae la riga trovata. Andando avanti nella lettura dell indice magari la successiva corrispondenza si trova su di un altra pagina che deve essere caricata anch essa in memoria per la lettura della riga. In questo modo ogni volta che viene trovata una occorrenza nell indice si rischia di dover caricare una pagina nello shared_buffer producendo un elevato flusso I/O a causa del buffer manager. Dunque per tabelle piccole il sequential_scan è sempre più conveniente poiché, in genere, con un singolo accesso al disco permette di portare l intera tabella nello shared buffer. Per tabelle più grandi il costo del sequential_scan cresce, mentre quello dell index_scan, se limitato a valori singoli resta più o meno costante e risulta quindi più conveniente.

13 TRANSAZIONI PostgreSQL protegge i dati e coordina gli accessi concorrenti multiutente attraverso le transazioni, attivate con i classici comandi BEGIN e COMMIT/ROLLBACK, e possibilità di innestarle (sottotransazioni). È possibile controllare le istruzioni in una transazione in modo granulare tramite l'utilizzo di savepoint. I savepoint consentono di scartare selettivamente parti della transazione, confermando il resto: dopo aver definito un savepoint con SAVEPOINT, si può tornare indietro al savepoint con ROLLBACK TO. Tutte le modifiche al database poste tra la definizione del savepoint ed il ritorno ad esso vengono scartate, mentre le modifiche precedenti il savepoint sono mantenute. Dopo essere tornati indietro ad un savepoint, lo stesso continua ad essere definito, per cui si può tornare indietro ad esso diverse volte. Al contrario, se non si è sicuri di voler tornare ancora indietro ad un particolare savepoint, esso può essere rilasciato, in modo che il sistema possa liberare alcune risorse. Postgres assicura tutte le proprietà ACID delle transazioni: l integrità dei dati è infatti garantita secondo le regole dei livelli di isolamento delle transazioni. Rispetto allo standard SQL, che definisce quattro livelli di isolamento delle transazioni, Postgres implementa internamente solo i livelli di isolamento Read Committed (cioè isolamento a livello di comando) e Serializable (cioè isolamento a livello di transazione). Così se si sceglie il livello Read Uncommitted in realtà si otterrà Read Committed, e quando si sceglie Repeatable Read in realtà si otterrà Serializable. Il livello di isolamento effettivo potrebbe quindi essere più stretto di quello scelto. La ragione per la quale Postgres fornisce solo due livelli di isolamento è che questo è l'unico modo sensato per gestire i livelli di isolamento standard nell'architettura di controllo concorrente. Di default si usa il Read Committed: una query SELECT vede i dati che sono stati sottoposti a commit, prima che la query stessa partisse; essa non vede mai né i dati non sottoposti a commit, né i cambiamenti sottoposti a commit da transazioni concorrenti durante l'esecuzione della query. Ad ogni modo, la query vede gli effetti di update precedenti eseguite all'interno della propria transazione, anche se non sono ancora stati sottoposti a commit: questo può causare inconsistenza, rendendo così la modalità Read Committed inadatta a comandi che coinvolgono condizioni di ricerca complesse. Per ovviare a questo problema si utilizza il livello Serializable, che emula l'esecuzione di transazioni seriali, ovvero è come se le transazioni fossero state eseguite una dopo l'altra in maniera seriale invece che concorrentemente. I livelli di isolamento si possono impostare sia a livello di configurazione nel file postgresql.conf (modificando il parametro default_transaction_isolation ), sia runtime con il comando: SET default_transaction_isolation = serializable.

14 Il modello utilizzato da PostgreSQL per implementare l'isolamento nelle transazioni si basa sul MVCC (MultiVersion Concurrency Control). Concettualmente ogni transazione vede uno snapshot (ovvero un istantanea) del database e agisce su quello snapshot. Lo snapshot è costruito considerando solo le transazioni precedenti la corrente che hanno effettuato il commit. Il vantaggio principale dell'uso del modello di controllo concorrente MVCC piuttosto che i meccanismi di lock tradizionali (comunque gestiti da Postgres), è che nel MVCC i lock acquisiti per interrogare dati (lettura), non vanno in conflitto con i lock acquisiti per scrivere dati, e così la lettura non blocca mai la scrittura e la scrittura non blocca mai la lettura. Se MVCC non fornisce il comportamento desiderato è possibile prevenire i problemi di concorrenza attraverso l uso appropriato di lock espliciti. PostgreSQL supporta diversi tipi di locking, sia a livello di tabella sia a livello di riga: Share (condivisi): prevalentemente comandi di lettura che possono anche aggiornare, ovvero ACCESS SHARE (pura lettura) o ROW SHARE (lettura/modifica, es. SELECT FOR UPDATE) Exclusive (esclusivi): scrittura o alterazione della struttura, ovvero ACCESS EXCLUSIVE (alterazione, ALTER TABLE) o ROW EXCLUSIVE (scrittura, INSERT/UPDATE) L'uso di lock espliciti può incrementare la probabilità di deadlock, in cui due (o più) transazioni mantengono entrambe lock che gli altri vogliono. Postgres riconosce automaticamente situazioni di deadlock e le risolve annullando una delle transazioni coinvolte, permettendo all'altra/e di completarsi (è difficile predire esattamente quale transazione sarà annullata). Postgres fornisce inoltre dei mezzi per la creazione di lock che hanno significati definiti dall'applicazione. Questi vengono chiamati lock consultivi, e dato che il sistema non impone il loro utilizzo è compito dell'applicazione usarli correttamente. I lock consultivi possono essere utili per strategie di locking che sono poco maneggevoli per il modello MVCC. Una volta acquisito, un lock consultivo viene tenuto fino a che non viene rilasciato esplicitamente o se la sessione termina. A differenza dei lock standard, i lock consultivi non rispettano la semantica transazionale: un lock acquisito durante una transazione che successivamente è sottoposto a rollback sarà ancora trattenuto seguendo il rollback, e anche un unlock entra in vigore anche se le la transazione chiamante successivamente fallisce. Un elenco completo dei lock consultivi legati è presente nella vista di sistema pg_locks. Le transazioni seguono la numerazione delle tuple: ogni transazione è identificata da un numero intero positivo e progressivo denominato XID. Lo XID è un intero a 4 byte (32 bit). L'età di una transazione è stabilita in modo relativo rispetto ad un'altra transazione: uno XID minore indica una transazione iniziata prima e quindi più vecchia. Lo stato delle transazioni avviate (ed eventualmente completate) è memorizzato in modo permanente in un log chiamato pg_clog. Le transazioni possono essere in uno dei seguenti quattro stati (identificati quindi da 2 bit): In progress (transazione avviata ma non completata) Committed (transazione completata con successo) Aborted (transazione completata con rollback forzato o manuale) Subcommitted (sottotransazione/savepoint passato con successo) Le transazioni sono memorizzate secondo l'ordine dato dal loro XID. Ne consegue che, sapendo la dimensione della pagina dati, sapendo che il blocco di una singola transazione è lungo 2 bit, e sapendo l'id della transazione è possibile risalire al dato circa il suo stato.

15 Internamente il database deve registrare non solo le informazioni utente (i dati veri e propri) ma anche i metadati per la gestione dell'mvcc. Ogni tupla viene quindi estesa con 4 campi particolari, usati per i controlli del sistema MVCC: xmin: indica il minimo valore di transazione che ha accesso ai dati (sostanzialmente la transazione che ha creato la tupla) xmax: indica il massimo valore di transazione che ha accesso ai dati (sostanzialmente l'id dell'ultima transazione che ha cancellato/modificato la tupla) cmin: indica il minimo valore di comando che ha accesso ai dati cmax: indica il massimo valore di comando che ha accesso ai dati Esempio: La tupla con xmin e xmax impostati ha subito una delete (o un update) e quindi non è più valida. Tutte le transazioni successive alla numero 20 non potranno vedere quella tupla, che però esiste ancora nel database. Di conseguenza il database può rimanere pieno di tuple non più valide: per questo motivo si può eseguire (manualmente o automaticamente) un comando di utilità, denominato VACUUM, che controlla una tabella o un database alla ricerca delle tuple che non sono più visibili da nessuna transazione e le cancella. In questo modo i dati si ricompattano e il database riduce il suo spazio: L'esecuzione di vacuum è un'operazione pesante, perché il sistema deve acquisire un lock esclusivo sull'oggetto. Vacuum può essere usato per eliminare le tuple espirate (vacuum full), oppure per aggiornare le statistiche di sistema (vacuum analyze). Può essere abilitato di default nel file postgresql.conf.

16 Per mantenere le informazioni sull'andamento delle transazioni si utilizza il Write Ahead Log (WAL). E' fisicamente archiviato all'interno della directory pg_xlog, e a differenza dei log in pg_clog non mantiene solo lo stato finale di una transazione, ma anche le informazioni (progressive) sui dati toccati. La teoria vuole che il WAL sia scritto prima dei dati, ma questo produrrebbe un sovraccarico di scritture. Per ovviare al problema Postgres divide i WAL log in segmenti (LSN). A questo punto i log WAL sono mantenuti in memoria, e ogni volta che si scrive una pagina di dati sporca la si fa precedere dalla scrittura di tanti segmenti di log fino al raggiungimento del numero LSN corrispondente alla pagina. Analogamente, durante un recovery tutte le transazioni con XID inferiori al LSN che si sta attualmente analizzando sono da considerarsi stabili (ripristinate completamente). La scrittura del WAL avviene secondo lo schema seguente: 1) acquisizione di un PIN e del lock sulla pagina dati da modificare (pin indica che la pagina non deve essere scartata dalla memoria) 2) modifica della pagina dati 3) la pagina viene marcata come dirty (sporca) 4) si richiama xloginsert per inserire la pagina di log e si imposta il LSN nella pagina dati al valore risultante dall'insert Le pagine WAL contengono modifiche in modo incrementale. Il sistema mantiene dei checkpoints, ossia ogni n transazioni forza una scrittura di una pagina dati completa nel WAL: alla prima modifica di una pagina sotto la condizione LSN < checkpoint si scrive la pagina dati completa nel WAL. Postgres può sfruttare i log WAL per effettuare un backup del sistema ad un determinato momento. L'idea è quella di archiviare i log e di indicare al sistema che deve effettuare nuovamente le transazioni archiviate. Una volta in possesso dei log è possibile ordinare al database di fare un ReDo delle transazioni. Questa procedura viene detta Point In Time Recovery (PITR) ed è composta dai seguenti passi: 1) stop del postmaster (e quindi del cluster) 2) pulizia delle directory del cluster, in particolare pg_xlog 3) copia dei log dentro a pg_xlog 4) creazione di un file recovery.conf nella root del cluster 5) avvio del postmaster (e quindi del cluster)

17 SICUREZZA L accesso alla base di dati viene permesso attraverso un sistema di autenticazione. I sistemi di autenticazione consentiti possono essere diversi e dipendono dalla configurazione di Postgres fatta all atto della compilazione dei sorgenti. Il file di configurazione pg_hba.conf (Hostbased authentication), che si trova nella directory del cluster ( data ), serve per controllare il sistema di autenticazione una volta installato Postgres. L autenticazione degli utenti può avvenire in modo incondizionato ( trust ), dove ci si fida del nome fornito come utente del DBMS senza richiedere altro, o può essere semplicemente disabilitata nel senso di impedire qualunque accesso incondizionatamente. L accesso può essere controllato attraverso l abbinamento di una parola d ordine agli utenti di Postgres. Il formato del file pg_hba.conf può essere semplificato nei due modelli sintattici seguenti, tenendo conto che esistono comunque altri casi: Nel primo caso si intendono controllare gli accessi provenienti da programmi clienti avviati nello stesso sistema locale, utilizzando un socket di dominio Unix per il collegamento; nel secondo si fa riferimento ad accessi attraverso la rete (connessioni TCP). Il campo base_di_dati serve a indicare il nome del database per il quale autorizzare l accesso; in alternativa si può usare la parola chiave all, in modo da specificare tutte le basi di dati in una sola volta. Il campo utente_dbms serve a indicare il nome dell utente del DBMS da autorizzare; in alternativa si può usare la parola chiave all, in modo da rendere indifferente chi sia l utente. I campi indirizzo_ip e maschera_degli_indirizzi rappresentano un gruppo di indirizzi di nodi che hanno diritto di accedere a quella base di dati determinata. Il campo autenticazione_utente rappresenta il tipo di autenticazione attraverso una parola chiave (tra le più importanti: trust, reject, password, crypt, ident, sameuser). L ultimo campo autenticazione_utente dipende dal penultimo. Nel caso di autenticazione ident, si utilizza quasi sempre la parola chiave sameuser per indicare a Postgres che i nomi usati dagli utenti nei sistemi remoti da cui possono accedere, coincidono con quelli predisposti per la gestione del DBMS. Nel caso di autenticazione password, l ultimo campo potrebbe rappresentare il nome del file di testo contenente le parole d ordine. Ad esempio: host all all trust concede a tutti gli utenti di accedere localmente, ma tramite un socket di dominio Internet (l indirizzo e normalmente quello di ogni nodo di rete, dal punto di vista locale), senza bisogno di alcun riconoscimento. Un altro esempio: local all all ident sameuser concede a tutti gli utenti di accedere localmente (tramite un socket di dominio Unix) a qualunque base di dati, sulla base del riconoscimento fatto dal sistema operativo (si intende che ci si affida ai privilegi che ha ottenuto il programma usato per accedere). Infine: host mydb pippo password concede all utente pippo di accedere alla base di dati mydb, da un nodo della rete qualunque tra quelli che hanno indirizzi del tipo *.*, attraverso l indicazione di una parola d ordine, che viene trasmessa in chiaro. Quando si creano delle tabelle in un database, tutti gli altri utenti che sono stati registrati nel sistema del DBMS, potrebbero accedervi e fare le modifiche che vogliono. Per controllare questi accessi, l utente proprietario delle relazioni (di solito è colui che le ha create), può usare le istruzioni GRANT e REVOKE. La prima permette a un gruppo di utenti di eseguire operazioni determinate, la seconda toglie dei privilegi.

18 L esempio: REVOKE ALL ON Presenze, Indirizzi FROM PUBLIC; GRANT ALL ON Presenze, Indirizzi TO tizio; toglie a tutti gli utenti (PUBLIC) tutti i privilegi sulle relazioni delle presenze e degli indirizzi; successivamente vengono ripristinati tutti i privilegi solo per l utente tizio. È possibile anche effettuare copie di sicurezza di un database o dell intero cluster, utilizzando i comandi: pg_dump e pg_dump_all. Queste producono un file SQL che contiene i comandi per la creazione del database,dello schema e dei dati. Grazie poi al comando pg_restore posso ricostruire il database o lo schema o i dati partendo da quel file. È possibile usare le funzionalità di backup interne a Postgres (con pg_hotbackup ) per produrre hot backup a sè stanti, sfruttando il meccanismo del WAL. Questi sono backup che non possono essere usati per recuperi di istanti nel tempo, sono tipicamente molto più veloci a svolgere backup e ripristino rispetto ai dump fatti con pg_dump. STORED PROCEDURES Postgres permette di costruire delle Stored Procedures interne al database in vari linguaggi. Il capostipite è il linguaggio procedurale (pl/) pgsql che è già presente nel sistema, ma previa installazione nel database è possibile programmare le proprie procedure anche nei seguenti linguaggi: pl/java pl/python pl/perl pl/tcl pl/php pl/ruby pl/r Prendendo ad esempio pgsql, la sintassi per creare una stored procedures è la seguente:

19 CREATE FUNCTION nome_funzione RETURNS tipo_funzione AS $$ [ <<label>> ] [ DECLARE declarations ] BEGIN statements END [ label ]; $$ LANGUAGE plpgsql; dove ogni dichiarazione e ogni istruzione all'interno di un blocco è terminata da un punto e virgola. Una label è necessaria solo se si vuole identificare il blocco per usarlo in altre istruzioni, o per qualificare i nomi delle variabili dichiarate nel blocco. PosgreSQL permette di automatizzare delle operazioni attraverso i Trigger, ovvero funzioni attivate da eventi di insert,update e delete sulle tabelle. La sintassi per la creazione dei trigger è: CREATE TRIGGER nome_trigger { BEFORE AFTER } { event [ OR... ] } ON table [ FOR [ EACH ] { ROW STATEMENT } ] [ WHEN ( condition ) ] EXECUTE PROCEDURE nome_funzione ( arguments ) Postgres offre sia trigger a livello di riga (perriga) che trigger a livello di funzione (peristruzione). Se è del tipo perriga, la funzione trigger viene invocata una volta per ogni riga che è coinvolta dall'istruzione che ha lanciato il trigger. Al contrario, se è peristruzione viene invocato solo una volta quando un'istruzione adatta viene eseguita, a prescindere dal numero di righe coinvolte dall'istruzione. Postgres inoltre mette a disposizione un potente sistema di regole, che è integrato nell elaborazione delle istruzioni SQL. Il sistema di regole di Postgres opera a valle della fase di parsing e a monte di quella di ottimizzazione. La sintassi generale è: CREATE RULE nameas ON event TO table[ WHERE condition] DO [ALSO INSTEAD] {NOTHING command (command;command...)} È possibile inoltre impostare cursori per restituire in modo efficiente grandi insiemi di righe da funzioni. La sintassi generale è: DECLARE nome_cursore [ [ NO ] SCROLL ] CURSOR [ ( arguments ) ] FOR query; La clausola FOR può essere sostituita da IS per compatibilità con Oracle. Sei viene specificato SCROLL, il cursore sarà capace di scorrere all'indietro, no altrimenti; se non appare nessuna delle due specifiche, dipenderà dalla query se saranno permesse ricerche all'indietro. Se specificato, arguments è un elenco separato da virgole di coppie name datatype che definisce i nomi da sostituire con i valori dei parametri nella

20 query data. Le operazioni per manipolare i cursori sono le stesse di SQLServer (clausole OPEN, FETCH INTO, MOVE, CLOSE, ecc...). INTERFACCIA Come già detto durante la fase di installazione, posso connettermi al database in 2 modi: da terminale usando il client psql, oppure sfruttando il client grafico pgadmin. Ma è possibile anche scaricare altri applicativi a interfaccia grafica che svolgono gli stessi compiti due programmi precedenti (un esempio è phpgadmin). L interfaccia a riga di comando di psql è la seguente (nell esempio mi sono connesso a un database): Per interagire con questo tipo di interfaccia bisogna utilizzare i comandi classici di SQL per poter creare quello che voglio o formulare query, oppure utilizzare quelli forniti da psql che cominciano con il carattere / e consentono di conoscere la struttura del database e dei suoi oggetti. Ad esempio: \d fornisce l'elenco degli oggetti nel database, \d nome_tabella fornisce la struttura di una tabella, \df fornisce l'elenco delle stored procedure, ecc

21 Se invece voglio utilizzare l interfaccia grafica di pgadmin per interagire con la base di dati, tutto risulterà più facile e visivamente preferibile rispetto al terminale. La schermata principale di pgadmin (nell esempio sono connesso a un database) è la seguente: Risulterà anche più intuitivo creare nuovi database o oggetti, oppure fare query e sfruttare al meglio tutte le altre utilità supportate da Postgres.

22 PRESTAZIONI Il miglioramento delle prestazioni di un database server è il cosiddetto tuning, e in Postgres abbiamo visto che avviene per esempio attraverso l uso di clausole come EXPLAIN, ANALYZE, VACUUM, l utilizzo dello Shared Buffer Cache per velocizzare l accesso ai dati e l uso degli indici. Ma le prestazioni di un database server dipendono anche dal sistema operativo sul quale esso gira, e quindi è strettamente collegato alla CPU. Quando la dimensione del database supera i 5 GigaByte, le prestazioni delle macchine con cpu a 32 bit decadono rapidamente e quindi è fortemente consigliato l'uso di macchine a 64 bit. Il vantaggio di una macchina a 64 bit, è che si può avere un grandissimo spazio di indirizzamento di memoria, e il sistema operativo può supportare file system molto estesi, può fornire migliori prestazioni con grandi database, può supportare memoria (RAM) molto maggiore, ha maggiori funzionalità, ecc.. Siccome nelle prestazioni incidono anche il bilanciamento del carico e la possibilità di adattarsi e risolvere eventuali malfunzionamenti o errori, assume un ruolo rilevante la replicazione del database server o clustering. In pratica più server di database possono lavorare insieme per consentire a un secondo server di rilevare rapidamente in caso di errore il server primario (high availability), o per consentire a computer diversi di servire gli stessi dati (bilanciamento del carico). Per garantire scritture e letture coerenti su tutti i server replicati è importante il concetto di sincronizzazione: i server che possono modificare i dati in lettura/scrittura vengono chiamati server primari o master, mentre i server che tengono traccia delle modifiche nel master sono chiamati server di standby o slave. Alcune soluzioni sono sincrone, ovvero una modifica di dati delle transazioni non è considerata completata fino a quando tutti i server hanno completato la transazione. In caso di lentezza delle sincrone, si possono utilizzare soluzioni asincrone che consentono un certo ritardo tra il momento del commit e la sua propagazione agli altri server, ma così facendo aumenta la possibilità che alcune transazioni potrebbero andare perse nel passaggio ad un server slave. Una soluzione che adotta Postgres è il warm standby : ci crea un cluster HA (high availability) in cui uno o più server sono in standby e pronti a prendere il posto del server primario in caso di suoi malfunzionamenti.

23 Esistono tante altre soluzioni adottate da Postgres grazie a vari moduli aggiuntivi, tra i più importanti: Slony1: consente la replicazione asincrona Master/MultiSlave con granularita' a livello di tabella. Quindi è possibile configurare tabelle che vengono replicate dal Master verso uno o più Slave su cui i dati sono accessibili in lettura. L'implementazione è basata su trigger e trasmissione asicrona. PGCluster: supporta il multi master e la replicazione sincrona, ma rispetto al precedente ha un peso computazionale maggiore. pgpool: supporta il bilanciamento del carico e la replica mediante l implementazione di un proxy che duplica tutti gli aggiornamenti a tutti gli slave (fa da middlewere).

24 Tenendo conto delle seguenti caratteristiche della mia macchina operativa: misuro le performance di Postgres 9.1, effettuando i seguenti benchmark: EMP7: utilizzando il client pgadmin ed eseguendo 10 volte la query del test Emp7 si calcola un tempo medio circa pari a 17,6 secondi. TPC B : è costituito da un unico tipo di transazione che esegue selects, updates e inserts su quattro tabelle distinte nel sistema create sfruttando il programma pgbench (tabelle: accounts, tellers, branches e history). Si misura il numero di transazioni al secondo. Per ogni run identica posso ottenere risultati diversi (non è costante nei numeri). Ecco un esempio di output generato:

25 Nell esempio, per un singolo cliente vengono svolte 10 transazioni e facendo anche più run in media si hanno circa 30 transazioni al secondo. Cambiando i valori di c per il numero di clienti e t per il numero delle transazioni per cliente, ottengo risultati diversi. In particolare tenendo costante il numero di clienti (es: 10) e aumentando man mano il numero di transazioni per cliente, ottengo un aumento delle transazioni al secondo:

26 Posso anche pensare di cambiare il fattore di scala s, mettendo così in relazione il numero di transazioni al secondo con le dimensioni del database. In genere ottengo un andamento simile al seguente: