ogr2ogr DBMS Transactional

[a.furieri]

magari non interessa a tutti, ma sicuramente e'
un dettaglio tecnico che potra' interessare diversi
power users che si trovano a manipolare grosse
quantita' di dati con ogr2ogr

ho scoperto (abbastanza casualmente) che ogr2ogr
e' incredibilmente lento quando il target di
destinazione e' uno Spatial DBMS Transactional:
quanto segue e' misurato su SpatiaLite, ma immagino
che anche PostGIS (Oracle, SQL Server ...) abbiano
esattamente il medesimo problema.

la causa di questa mortale lentezza in scrittura
va identificata nel fatto che ogr2ogr invoca una
operazione di COMMIT TRANSACTION troppo frequentemente,
mandando continuamente in stallo l'I/O del DBMS

tuttavia esiste un piccolo, oscuro argomento che
permette di configurare flessibilmente questo aspetto;
peccato che la documentazione di ogr2ogr non lo metta
nella debita edivenza avvertendo della criticita'.

-tg 65536 [capisce anche l'alias -gt, =Group Transaction]

spiegazione ultra-veloce: by default ogr2ogr assume
-tg 200; cioe' ogni 200 INSERT (oppure quando cambia
layer) effettua una COMMIT
specificando esplicitamente -tg 65536 invece si chiede
ad ogr2ogr di effettuare una COMMIT ogni 65536 INSERTs

test case
----------
input: un file GML topologico da 2,8 GB (grosso bestione)
output: SpatiaLite 3.0.0 con Spatial Index abilitati
        (100+ layers, molti milioni di features)

test #1 (default): 4 ore e mezza
test #2 (-tg 65536): 1 ora :-)

... quella che si chiama una "differenza apprezzabile" :-P

ciao Sandro



_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
540 iscritti al 4.11.2011

[Stefano Iacovella]

In operazioni di caricamento così onerose può essere utile
disabilitare gli indici spaziali prima del caricamento e riabilitarli
subito dopo.
In Oracle, ma credo anche in PostGIS e altri RDBMS, si nota un
vantaggio evidente.

Stefano

---------------------------------------------------

http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas



Il 05 dicembre 2011 12:22,  <[hidden email]> ha scritto:

> magari non interessa a tutti, ma sicuramente e'
> un dettaglio tecnico che potra' interessare diversi
> power users che si trovano a manipolare grosse
> quantita' di dati con ogr2ogr
>
> ho scoperto (abbastanza casualmente) che ogr2ogr
> e' incredibilmente lento quando il target di
> destinazione e' uno Spatial DBMS Transactional:
> quanto segue e' misurato su SpatiaLite, ma immagino
> che anche PostGIS (Oracle, SQL Server ...) abbiano
> esattamente il medesimo problema.
>
> la causa di questa mortale lentezza in scrittura
> va identificata nel fatto che ogr2ogr invoca una
> operazione di COMMIT TRANSACTION troppo frequentemente,
> mandando continuamente in stallo l'I/O del DBMS
>
> tuttavia esiste un piccolo, oscuro argomento che
> permette di configurare flessibilmente questo aspetto;
> peccato che la documentazione di ogr2ogr non lo metta
> nella debita edivenza avvertendo della criticita'.
>
> -tg 65536 [capisce anche l'alias -gt, =Group Transaction]
>
> spiegazione ultra-veloce: by default ogr2ogr assume
> -tg 200; cioe' ogni 200 INSERT (oppure quando cambia
> layer) effettua una COMMIT
> specificando esplicitamente -tg 65536 invece si chiede
> ad ogr2ogr di effettuare una COMMIT ogni 65536 INSERTs
>
> test case
> ----------
> input: un file GML topologico da 2,8 GB (grosso bestione)
> output: SpatiaLite 3.0.0 con Spatial Index abilitati
>        (100+ layers, molti milioni di features)
>
> test #1 (default): 4 ore e mezza
> test #2 (-tg 65536): 1 ora :-)
>
> ... quella che si chiama una "differenza apprezzabile" :-P
>
> ciao Sandro
>
>
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> Non inviate messaggi commerciali.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 540 iscritti al 4.11.2011

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
540 iscritti al 4.11.2011

[a.furieri]

On Mon, 5 Dec 2011 12:52:56 +0100, Stefano Iacovella wrote
> In operazioni di caricamento così onerose può essere utile
> disabilitare gli indici spaziali prima del caricamento e riabilitarli
> subito dopo.
> In Oracle, ma credo anche in PostGIS e altri RDBMS, si nota un
> vantaggio evidente.
>

certo, e' proprio cosi': ma dimensionare opportunamente il
perfido -tg fa una differenza ancora piu' rilevante e massiccia
(almeno, misurato su SpatiaLite)

ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
540 iscritti al 4.11.2011