PostgreSQL, The Big, The Fast and The Ugly

PostgreSQL, The Big, The Fast and The UglyIl piu’ avanzato database open source come big data player

Federico Campoli

Brandwatch.com

25 Ottobre 2014

Federico Campoli (Brandwatch.com) PostgreSQL, The Big, The Fast and The Ugly 25 Ottobre 2014 1 / 34

Sommario

1 PostgreSQL, una storia di eccellenza

2 The Big

3 The Fast

4 The Ugly

5 Conclusioni


Sommario


2 The Big

3 The Fast

4 The Ugly

5 Conclusioni


PostgreSQL, una storia di eccellenza



Creato all’universita’ di Berkeley nel 1982 dal Prof. Stonebraker

Nel 1994 Andrew Yu e Jolly Chen aggiungono l’interprete SQL

Nel 1996 diventa un progetto Open Source prendendo il nome di PostgreSQL

Totalmente ACID compliant

Alta scalabilita’ con MVCC

Tablespace

Disponibile per numerosi unix flavours

Dalla versione 8.0 e’ nativo su *cough* MS Windows *cough*

High Availability fornita da hot standby e streaming replication

Federation verso fonti dati eterogenee

Numerosi linguaggi procedurali (pl/pgsql, pl/python, pl/perl...)

Supporto per tipi dato schemaless come HSTORE e JSON








Tablespace














Tablespace














Tablespace









Sviluppo

Programmato in linguaggio C

Numerose versioni supportate

Versioni supportate a lungo termine (almeno 5 anni)

Espandibile con l’uso di librerie esterne

Supporto per le estensioni (dalla versione 9.1)



Limiti

Dimensione massima database. Illimitata.

Dimensione massima singola tabella, 32 TB

Dimensione massima singola riga 1.6 TB

Numero massimo di righe per tabella. Illimitate.

Numero massimo di campi per tabella, 250 1600 a seconda del tipo dati.

Numero massimo tabelle. Illimitato.



Insieme ai tipi dato comuni, PostgreSQL fornisce alcuni tipi decisamente esotici.

Range

Dati geometrici

Indirizzi di rete

XML

JSON

HSTORE (extension)

Gli ultimi due sono oggetto della presentazione in quanto molto popolarinell’universo NOSQL.


Sommario


2 The Big

3 The Fast

4 The Ugly

5 Conclusioni


The Big

Image by Caitlin - https://www.flickr.com/people/50194168@N00


The Big

JSON - JavaScript Object Notation

JSON supportato come tipo nativo dalla versione 9.2

La 9.3 introduce numerose funzioni di supporto

Lo storage e’ praticamente testo

La sintassi JSON viene validata al volo

La struttura JSON viene gestita dal database

Dalla versione 9.4 appare JSONB (binario) che migliora notevolmente leperformance


The Big

JSON - EsempiDa record a JSON

postgres=# SELECT row_to_json(ROW(1,’foo’));row_to_json

---------------------{"f1":1,"f2":"foo"}

(1 row)

Espansione di JSON in elementi key to value

postgres=# SELECT * from json_each(’{"a":"foo", "b":"bar"}’);

key | value-----+-------a | "foo"b | "bar"

(2 rows)


The Big

HSTORE e’ un tipo dato per elementi key to value

Supportato come estensione

I dati sono memorizzati come testo

Una libreria condivisa transforma il testo nel tipo HSTORE

Simile a json ma senza elementi annidati


The Big

HSTORE - EsempiDa record a HSTORE

postgres=# SELECT hstore(ROW(1,2));hstore

----------------------"f1"=>"1", "f2"=>"2"

(1 row)

Espansione di HSTORE in elementi key to value

postgres=# SELECT * FROM each(’a=>1,b=>2’);key | value

-----+-------a | 1b | 2

(2 rows)


The Big

C’e’ una differenza sottile tra HSTORE e JSON. Poiche’ HSTORE e’ unestensione la manipolazione del dato avviene grazie ad una libreria esterna.

Questo, combinato con il modo in cui PostgreSQL trasforma il datum quandoviene caricato in memoria, puo avere effetti anche drammatici sulle performance.


Sommario


2 The Big

3 The Fast

4 The Ugly

5 Conclusioni


The Fast

Image by Hein Waschefort -http://commons.wikimedia.org/wiki/User:Hein waschefort


The Fast

PostgreSQL memorizza i dati in blocchi di dimensione fissa chiamate pagine. Ognipagina e’ solitamente di 8kb con un header usato per garantire la durabilita’.

Figure : Data page

Dopo l’header c’e’ una lista di puntatori alle tuple fisiche. Ogni tupla e’strutturata come un array di dati il cui tipo e’ inizialmente sconosciuto.


The Fast

Lo stream di dati in tale stato e’ chiamato datum. Una volta caricato in memoriaPostgreSQL risolve il tipo memorizzato usando il catalogo di sistema.

Figure : Tuple structure

Lo header di tupla e’ parte dell’implementazione MVCC.


The Fast

Per ogni tupla caricata in memoria il dato viene trasformato da datum a tiporeale. Le routine di conversione variano a seconda del tipo effettivo.

Un elemento nativo come JSON esegue quindi le routine che sono codificateinternamente al motore di database.

Di contro una trasformazione HSTORE genera un accesso alla libreria esterna perogni tupla esaminata in memoria.


The Fast

Nonostante JSON sia un dato nativo non e’ detto che le sue performance sianomigliori di HSTORE. La validazione e il parsing al volo sono un potenzialebottleneck se la quantita’ di dati e’ importante.

Questo problema viene risolto dal nuovo tipo binario JSONB introdotto conPostgreSQL 9.4. Tutte le routine di validazione e trasformazione avvengonodurante le DML.


Sommario


2 The Big

3 The Fast

4 The Ugly

5 Conclusioni


The Ugly

Image by D. Gordon E. Robertson -http://commons.wikimedia.org/wiki/User:Dger


The Ugly

Un caso reale, Brandwatch

Social media analytics

Dati real time e storici

Core database PostgreSQL

Big Data!!!!!


The Ugly

Tanto tempo fa in un datacentre lontano lontano...(Ottobre 2012)

1 database per analytics

Dimensione di “soltanto” 1.2 TB

Struttura denormalizzata

Storage schemaless con HSTORE


The Ugly

Qualche tempo dopo, Giugno 2014...

10 shards per l’analisi dei dati

Dimensione complessiva di 25 TB

HSTORE e denormalizzazione

Sistemi costantemente sovraccarichi

Crescita storage di 300 GB al giorno


The Ugly

Il problema... HSTORE

Sovraccarica la CPU

Storage poco efficiente

Dati a volte incoerenti

Difficile da manutenere

Estremamente pratico


The Ugly

La soluzione... il buon vecchio storage columnar

Riduzione dello spazio del 30%

Carico di CPU ridotto ai minimi termini

Dati consistenti

Crescita ridotta a soli 50 GB al giorno

HSTORE usato solo come input per le procedure

Apertura a successivi miglioramenti


Sommario


2 The Big

3 The Fast

4 The Ugly

5 Conclusioni


Conclusioni

I dati schemaless sono molto comodi, permettono grande flessibilita’ seimplementati correttamente.

L’assenza di scalabilita’ orizzontale in PostgreSQL ne limita l’utilizzo se laquantita’ di dati e’ importante.

Un promettente progetto in tal senso e’ PostgreSQL XL -http://www.postgres-xl.org/


Domande

Domande?

Per favore siate semplici, dopo tutto sono soltanto un elettricista...


Contatti

Twitter: 4thdoctor scarf

Blog su PostgreSQL: http://www.pgdba.co.uk

PostgreSQL Book:http://www.slideshare.net/FedericoCampoli/postgresql-dba-01

Lavoro: http://www.brandwatch.com/


Licenza

Licenza CC Attribuzione - Non commerciale - Condividi allo stesso modo 3.0

http://creativecommons.org/licenses/by-nc-sa/3.0/it/deed.it


PostgreSQL, The Big, The Fast and The UglyIl piu’ avanzato database open source come big data player

Federico Campoli

Brandwatch.com

25 Ottobre 2014


Technology

PostgreSQL, The Big, The Fast and The Ugly