[Gfoss] problemi con indici spaziali sqlite

[a.furieri a lqt.it]

On Fri, 21 Feb 2014 14:21:34 +0100, Luca Lanteri wrote:
> Io ho iniziato a lavorarci da poco e mi è sembrato uno strumento
> assolutamente fondamentale e dalle ampie potenzialità. Anche con le
> mie scarse capacità grazie a SL sono riuscito a risolvere parecchi
> dei problemi.
> Tempo addietro si parlava di SL come dello shapefile del futuro, ed 
> in
> effetti le potenzialità ci sono, però a leggere questo treadh mi
> viene un po' di depressione.  Insomma, utilizzare SL sembra molto
> più complicato di quello che pare a prima vista e ci sono risvolti
> non da poco da tener conto. In diversi ambiti lavorativi non posso
> permettermi di maneggiare nitroglicerina o scalare ad ampia quota,
> devo affidarmi alla sicurezza e all'affidabilità.
>

Luca,

ogni strumento tecnologico ha pregi e difetti; anzi, per la precisione,
quelli che in un determinato contesto sono pregi possono facilmente
diventare difetti in un contesto diverso e viceversa.

SQLite (e quindi di riflesso SpatiaLite) ha diversi punti di forza
assolutamente degni di nota e che lo rendono praticamente unico:
- e' cosi' tanto leggero e strutturalmente semplice che gira bene
   anche su Android e su altre piattaforme che offrono risorse HW
   risicatissime (smartphone, embedded devices etc)
- ma e' anche decisamente robusto ed affidabile, e spesso (non
   sempre) scala assai bene anche nei piu' classici contesti
   workstation o server
- dato che un DB e' semplicemente un file monolitico con architettura
   universale, permette di scambiare molto facilmente grandi masse di
   dati altamente strutturati tra piattaforme eterogenee tramite una
   banale operazione di copia.
- supporta quasi interamente la sintassi ISO SQL standard
- non ha praticamente bisogno di processi di configurazione e
   manutenzione da parte dell'utente finale

naturalmente ogni rosa si porta sempre dietro qualche spina:
- non e' client server: e soffre di terribili problemi per gli accessi
   concorrenti in scrittura, che risultano di fatto impossibili.
- alcuni dettagli dell'implementazionei SQL  sono significativamente
   differenti da quanto viene normalmente implementato nei piu' comuni
   DBMS client-server (giusto per dire, SQLite non ha i data-types)
- a volte alcuni meccanismi sono decisamente "ruvidi"; funzionano,
   e funzionano in modo efficiente, ma richiedono certamente un qualche
   sforzo extra da parte degli sviluppatori per operare al meglio.
   e' un po' come il cambio della vecchia 500 (per chi ancora se lo
   ricorda); certamente funzionava, ma se non eri bravo a fare la
   "doppietta" ti ci potevi spaccare un polso (oltre a rimanere
   piantanto in folle nel momento meno opportuno) ;-)
- last but not least: dato che e' semplicemente un'unica libreria
   che funge simultaneamente tanto da server quanto da client, e'
   un componente sw altissimamente configurabile.
   credo che le opzioni di build (comprese quello "occulte" che si
   scoprono solo spulciando il codice) siano svariate centinaia.
   ed e' fortemente configurabile tanto in fase di build quanto in
   fase di runtime.
   il che e' di per se sicuramente un'ottima caratteristica fino a
   quando lo si usa direttamente dentro ad una singola app di cui un
   unico gruppo di sviluppo/distribuzione riesce a controllare tutti
   i minimi dettagli.
   e' assai meno ottimale quando si va a costruire un framework 
complesso
   (magari multi-piattaforma e multi-linguaggio) in cui esiste una 
plurarita'
   di componenti indipendenti che pero' devono operare a strettissimo 
contatto.
   il rischio di costruire "un'orchestra stonata" diventa quindi molto
   alto, come purtroppo sanno bene gli utenti QGIS che hanno avuto in 
passato
   la spiecavola esperienza di scoprire che il data-provider da un lato,
   ed i plug-in Python dall'altro stavano usando versioni spaiate delle
   librerie che causavano conflitti insanabili.

insomma, esistono certamente alcuni scenari in cui scegliere 
oculatamente
e' molto facile:
- devi lavorare su micro-devices ?
   non hai alternative: sqlite e' l'unico candidato serio.
- devi gestire cento utenti che lavorano in concorrenza parallela ?
   scordati immediatamente sqlite, sara' un fallimento totale.

tutto quel che cade nel mezzo e' "area grigia", ed evidentemente
la scelta finira' per dipendere da un sacco di fattori variabili
che non e' possibile ridurre a qualche facile formuletta stereotipata
e preconfezionata.

in base ai ritorni d'uso di cui sono direttamente a conoscenza (piu' 
che
altro grazie alla ML di progetto di SpatiaLite), lo spettro degli 
utenti
soddisfatti spazia da organizzazione di livello governativo che hanno
spento con piena soddisfazione svariate istanze di un blasonato (ed 
assai
costoso) Spatial DBMS proprietario per passare a splite, fino ad 
arrivare
ad una pletora di giovani sviluppatori tutti felici e contenti perche'
splite gli consente di sviluppare facilmente apps con un buon livello 
di
supporto Spatial su trespolini ultra-light Android o .NET
nel mezzo ci trovi un pattuglione di ricercatori universitari e/o
professionisti che devono processarsi un sacco di dati geolocalizzati
ma che hanno a ben poco (o nulla) a che fare con i classici paradigmi
GIS, e che preferiscono lavorare quasi esclusivamente tutto a colpi di
SQL (magari appoggiandosi anche su Python o altri linguaggi di 
scripting):
solo alla fine del processo esportano qualche SHP ed utilizzano qualche
GIS "classico" per le operazioni di rendering e stampa degli elaborati.

sporadicamente si e' anche affacciato qualche sviluppatore di video
games (lo Spatial Processing serve ovviamente anche a loro).
il caso d'uso piu' bizzaro di cui sono a conoscenza e' quello di
un artista berlinese che usa spatialite per produrre i suoi quadri
di arte moderna rielaborando via SQL alcune tracce GPS :-)
ma se ti affascinano le stravaganze ti consiglio di seguire la
ML di SQLite, dove scoprirai che esiste un sotto-gruppo molto
attivo interamente dedicato allo sviluppo di un "solutore universale
di Sudoku" tutto integralmente basato su SQL :-D

infine, giusto per concludere questa pur sommaria carrellata, abbiamo
una discreta pattuglia di utenti QGIS che finisce per approdare
dalle parti della ML spatialite in cerca di assistenza e di
conforto quando incontrano qualche osso particolamente duro.

generalizzare e' sempre sbagliato, ma qualche pattern interessante
direi che comunque emerge:
- molti dei problemi riportati nascono da un uso "estremo" delle
   Spatial VIEWs
- seguiti a ruota da analoghi problemi causati da un uso
   altrettanto "spericolato" dei Triggers
   (n.b.: il che e' di per se notevole ed assai indicativo, visto
   che quasi mai gli utenti di tipo piu' ortodosso SQL-oriented
   sollevano problemi relativi a Views e Triggers ... evidentemetne
   c'e' qualche distorsione sistematica all'opera)
- non di rado si riscontrano problemi causati da un uso poco
   oculato di versioni mescolate piu' o meno a caso.
- spesso mi pare di poter notare una scarsa consapevolezza riguardo
   alle mille idiosincrasie specifiche di SQLite e di SpatiaLite ...
   insomma, l'impressione e' che non di rado si navighi un po'
   "ad orecchio" e "per sentito dire", piu' che per approfondita
   conoscenza degli strumenti specifici sqlite/splite.

immagino quindi che gli utenti QGIS spesso finiscano per annaspare
su problemi riconducibili a SQL/sqlite/spatialite piu' che altro
perche' stanno tentando di avventurarsi alla ricerca di non facili
equilibri alchemici che riescano in qualche modo ad aggirare il
classico data-model "flat table" tipico dei layer GIS modellati
a misura di shapefile.
... ma la strada dei workarounds e' sempre notoriamente cosparsa
di spine pungenti ;-)

sinceramente non credo che il problema sarebbe poi molto diverso
se si tentesse di utilizzare PostGIS oppure qualche altro DBMS;
immagino che cambierebbe ben poco.
quel che invece so per certo e' che questo e' un campo di utilizzo
in cui sqlite/spatialite puo' entrare molto facilmente in sofferenza,
perche' i numerosi vincoli e  tutte le specificita'/idiosincrasie
intrinseche in un'implementazione "ultra-light", a volte "scorbutica"
e sostanzialmente "eretica" verrano stiracchiati fino all'estremo.
ed assai verosimilmente, specie in presenza di un know-how specifico
non del tutto adeguato, si finira' per cadere in qualche trappolone.

"semplice" e "leggero" non sempre significa anche "facile", specie
quando si cerca di spingersi agli estremi oltre ai limiti standard
dell'implementazione base .... magari funziona anche, ma quasi di
sicuro tocchera' sudare un bel po' per avere successo ;-)

ciao Sandro