Una giornata di workshop precederà la conferenza il 14 luglio, e un code sprint chiuderà l’evento il 18 luglio.

La conferenza mira a riunire utenti e sviluppatori di tutto il mondo FOSS4G e favorirne la stretta interazione tra le varie comunità europee al fine di condividere le  idee.

Il programma della conferenza si presenta molto interessante:

• la mattinata del 14 luglio dedicata a workshop.  4 ore di corsi pratici tenuti da sviluppatori FOSS4G,
• le giornate del 15, 16 e 17 luglio saranno una vera e propria full immersion di geodata. La conferenza prevede 6 truck differenti: General track, Academic track, Open Data track, Water track, Positioning track, Library track.

Ai Key Note è riservato l’Auditorium 1:

Alessandro ANNONI Head of Unit JRC European Commission ‘Sharing: Why, What and How?’	Georg GARTNER President International Cartographic Association ‘Modern Cartography And The Role Of FOSS4G’	Patrick HOGAN Project Manager NASA  ‘FOSS4G: How We Facilitate Solutions and Increase Value for Life. Can We Do Better?’
Ki Joune LI Professor Pusan National University ‘Exploring Indoor Space – From Macro-Space to Mini-Space’	Jun CHEN President International Society of Photogrammetry  and Remote Sensing ‘GlobeLand30: 30-m resolution open access Earth Land- Cover Map’	Jeff McKENNA President Open Source Geospatial Foundation ‘Looking Ahead: Open Geospatial and the OSGeo Foundation’

2ndQuadrant Italia sarà rappresentata da Giuseppe Broccolo, dottorato di ricerca in Fisica, da sempre appassionato GIS. Ha collaborato in attività di ricerca col CERN di Ginevra.

Oggi consulente PostgreSQL presso 2ndQuadrant Italia.

Giuseppe presenterà  due semplici esempi di operazioni utilizzando l’ente geometrico e/o geografico più semplice con cui si possa avere a che fare in un database geospaziale: il punto. Verranno considerati i vari tipi di dato con cui PostgreSQL tratta i punti, partendo dal semplice punto 2D non georeferenziato, fino ad arrivare ai punti LiDAR, oltre i possibili indici messi a disposizione dal DBMS Open Source, al fine di comprendere quali sono i più adatti sulla base della ricerca svolta. Infine verranno mostrate le performance raggiungibili trattando con “nuvole di punti” di diverse dimensioni (da 1M fino a 1G).

Non mancheranno i momenti di network. A partire dalla sera del 15 luglio dove i partecipanti potranno rompere il ghiaccio, per finire con la cena sociale prevista la sera del 16 luglio.

Il sempre più forte interesse per le tematiche GIS, ci viene raccontato da questi pochi numeri:

<400 i partecipanti iscritti> <oltre 100 talk> <6 track> <12 workshop>.

Per coloro che avessero voglia di iscriversi oggi, una brutta notizia:  è stato raggiunto il numero massimo degli iscritti, sold out!

Buon geodata a tutti.

Base di dati di test

Utilizziamo come base di dati le recensioni degli utenti di Amazon del 1998 in formato JSON. Il file customer_reviews_nested_1998.json.gz è scaricabile dal sito di Citus Data.
Il file, una volta decompresso, occupa 209 MB e contiene circa 600k record in formato JSON, con una struttura simile a quella seguente:

{
    "customer_id": "ATVPDKIKX0DER",
    "product": {
        "category": "Arts & Photography",
        "group": "Book",
        "id": "1854103040",
        "sales_rank": 72019,
        "similar_ids": [
            "1854102664",
            "0893815381",
            "0893816493",
            "3037664959",
            "089381296X"
        ],
        "subcategory": "Art",
        "title": "The Age of Innocence"
    },
    "review": {
        "date": "1995-08-10",
        "helpful_votes": 5,
        "rating": 5,
        "votes": 12
    }
}

Dimensioni

I dati possono essere caricati in un database PostgreSQL usando il tipo di dati JSONB con i seguenti comandi:

CREATE TABLE reviews(review jsonb);
\copy reviews FROM 'customer_reviews_nested_1998.json'
VACUUM ANALYZE reviews;

La tabella risultante occuperà circa 268 MB, con un costo aggiuntivo di memorizzazione su disco di circa il 28%. Se proviamo a caricare gli stessi dati usando il tipo JSON, che li memorizza come testo, il risultato sarà una tabella di 233 MB, con un incremento di spazio di circa l’11%. Il motivo di questa differenza è che le strutture interne di JSONB, che servono ad accedere ai dati senza analizzare ogni volta tutto il documento, hanno un costo in termini di spazio occupato.

Accesso ai dati

Una volta memorizzati i dati nel database, per potervi accedere in maniera efficiente è necessario creare un indice. Prima della versione 9.4 di PostgreSQL, l’unica opzione per indicizzare il contenuto di un campo contente JSON era quella di utilizzare un indice B-tree su un’espressione di ricerca specifica. Per esempio, se vogliamo effettuare ricerche per categoria di prodotto utilizzeremo:

CREATE INDEX on reviews ((review #>> '{product,category}'));

L’indice appena creato occupa 21 MB, cioè circa il 10% dei dati originali, e permetterà di eseguire query che abbiano all’interno della clausola WHERE l’espressione esatta “review #>> '{product,category}'”, come ad esempio:

SELECT
    review #>> '{product,title}' AS title,
    avg((review #>> '{review,rating}')::int)
FROM reviews
WHERE review #>> '{product,category}' = 'Fitness & Yoga'
GROUP BY 1 ORDER BY 2;
                       title                       |        avg
---------------------------------------------------+--------------------
 Kathy Smith - New Yoga Challenge                  | 1.6666666666666667
 Pumping Iron 2                                    | 2.0000000000000000
 Kathy Smith - New Yoga Basics                     | 3.0000000000000000
 Men Are from Mars, Women Are from Venus           | 4.0000000000000000
 Kathy Smith - Functionally Fit - Peak Fat Burning | 4.5000000000000000
 Kathy Smith - Pregnancy Workout                   | 5.0000000000000000
(6 rows)

La query impiega circa 0.180 ms per essere eseguita sulla macchina di test, ma l’indice che è stato creato è altamente specifico e non è usabile per ricerche diverse.
A partire dalla versione 9.4, il tipo di dati JSONB supporta l’utilizzo di indici inversi (GIN, General inverted Indexes), che permettono di indicizzare le componenti di un oggetto complesso.
Andiamo quindi a creare un indice GIN sulla nostra tabella reviews con in seguente comando:

CREATE INDEX on reviews USING GIN (review);

L’indice risultante occupa 64 MB su disco, che è circa il 30% della dimensione della tabella originale. Tale indice può essere utilizzato per velocizzare i seguenti operatori:

• JSON @> JSON è un sottoinsieme
• JSON ? TEXT contiene un valore
• JSON ?& TEXT[] contiene tutti i valori
• JSON ?| TEXT[] contiene almeno un valore

La query precedente deve quindi essere riscritta usando l’operatore @> per cercare le righe che contengono '{"product": {"category": "Fitness & Yoga"}}':

SELECT
    review #>> '{product,title}' AS title,
    avg((review #>> '{review,rating}')::int)
FROM reviews
WHERE review @> '{"product": {"category": "Fitness & Yoga"}}'
GROUP BY 1 ORDER BY 2;

La query impiega circa 1.100 ms per essere eseguita sulla macchina di test e l’indice che è stato creato è flessibile ed è possibile usarlo per qualsiasi ricerca all’interno dei dati JSON.

In realtà spesso la sola operazione utilizzata nelle applicazioni è la ricerca per sottoinsieme, in tal caso è possibile usare un indice GIN diverso, che supporta solo l’operazione @> ed è quindi considerevolmente più piccolo. La sintassi per creare questo tipo di indice “ottimizzato” è la seguente:

CREATE INDEX on reviews USING GIN (review jsonb_path_ops);

L’indice risultante occupa solamente 46 MB cioè solo il 22% della dimensione dei dati originale e grazie a questa sua dimensione ridotta viene usato da PostgreSQL con maggiore efficienza. Questo permette di eseguire la query precedente in soli 0.167 ms, con un incremento di prestazioni del 650% rispetto all’indice GIN originale e del 8% rispetto all’indice B-tree specifico usato inizialmente, il tutto senza perdere di generalità per quanto riguarda le possibili operazioni di ricerca.

Conclusioni

Con l’introduzione del tipo JSONB e gli indici GIN costruiti con gli operatori jsonb_path_ops, PostgreSQL unisce l’elasticità del formato JSON a una velocità di accesso ai dati strabiliante.
Oggi è quindi possibile memorizzare e elaborare dati in formato JSON con elevate prestazioni, godendo allo stesso tempo della robustezza e della flessibilità a cui PostgreSQL ci ha abituato negli anni.