[Gfoss] [OT] Architettura Sigmater: era Architettura SIT Open Source

[Andrea P.]

Simpatia e antipatia sono sentimenti giustificati, poiche' investono la 
sfera soggettiva.

Io stesso quando scrivo un programma, nel mio piccolo, in genere dopo 
averlo scritto, mi rimane sempre un po' antipatico, perche' con il senno 
del poi, vedo sempre i difetti e non i pregi, e mi pento regolarmente 
delle scelte fatte nello sviluppo.
(Non hai idea di quanto mi sia antipatico "Castore".)

Nel caso di Sigmater, se anziche' i prodotti commerciali che vi sono 
dentro, avesse avuto come base di sviluppo dei prodotti FOSS, quali ad 
esempio,
Postgres+postgis e GeoServer (o mapserver) e Tomcat (o JBoss) avrebbe 
avuto un'altra percezione verso certe utenze, e forse anche una 
differente possibilita' di utilizzo.

Pero' , non per giustificare chi ha stilato le specifiche
(oltretutto non conosco quali sono state le considerazioni che hanno 
portato a tale architettura.), se posso azzardare delle ipotesi:

all'epoca il db di riferimento OS era senz'altro MySQL, con la 
componente spaziale che conosciamo.
Postgres non aveva ancora un modulo spaziale cosi' evoluto come lo e' ora.
E in prospettiva Oracle dava maggiori garanzie di supporto ed evoluzione.

Per la parte Middleware (OAS) il discorso e' forse piu' sottile.

Si cercava senz'altro una piattaforma enterprise, all'epoca vi era gia' 
JBoss e poteva essere un buon candidato, ma non aveva una gran base di 
installato, e forse era un po' un salto nel buio.
Li' forse, ha prevalso una logica di mercato e la scelta di OAS e' stata 
principalmente dovuta al fatto che era un prodotto abbastanza conosciuto 
da parte di chi avrebbe sviluppato il sistema.
Una prova del fatto che la scelta del middleware sia stata piu' 
soggettiva, e' dettata dal fatto che comunque bene o male,
come faceva notare Ivano, la parte middleware, viene piu' o meno 
regolarmente portata anche su WebSphere e su JBoss stesso.
Segno che si e' cercato sulmiddleware, di mentenere un profilo neutrale, 
senza fare un uso pesante di elementi specifici di un prodotto, cosa che 
lo avrebbe reso senz'altro poco portabile.

Devo comunque spendere una parola tecnica a favore del DB adoperato in 
Sigmater.

Le operazioni che il DBMS e' chiamato a compiere ogni volta che parte un 
aggiornamento sono talmente onerose, che metterebbero alle corde 
qualsiasi DB.
Nel caso specifico di Sigmater e' stata adottata una tecnica molto 
sofisticata, chiamata exchange-partition.
Che si basa sulla atomizzazione dello spostamento di una mole 
considerevole di dati come se fosse una operazione unica.
Mi spiego meglio.
Quando si deve spostare qualche decina di Gbytes, da alcune parti di un 
DB verso altre, questo comporta del tempo. Durante questo lasso di tempo 
gli utenti devono poter accedere analogamente ai dati e non perderli di 
vista.
Per cui l'operazione deve atomizzarsi, ovvero un istante prima ci sono i 
vecchi dati, un istante dopo ci sono i nuovi.
Questo deve essere percepito cosi' nonostante lo spostamento fisico dei 
dati comporti magari qualche ora di tempo. tenendo anche presente che se 
durante questi spostamenti avvengono delle violazioni di FK (cosa non 
infrequente nei dati catastali), anche il rollback deve atomizzarsi.
Questo non si riusciva ad ottenerlo con il semplice comando di commit,
perche' durante l'elaborazione dei dati venivano effettuate delle 
operazioni che per loro natura sono autocommittanti, per cui non era 
possibile avere un unico commit alla fine di tutto, ma si avevano dei 
commit intermedi che a fronte di un errore sui dati verso la fine, non 
sarebbe stato possibile con il rollback tornare allo stato originale, e 
i dati sarebbero rimasti in uno stato ibrido.

Per ottenere questo, in Sigmater, si e' fatto ricorso a una peculiarita' 
di Oracle, la cosidetta operazione di exchange-partition.

Trattasi di una caratteristica che e' propria di oracle enterprise e non 
appartiene al mondo dei DB OS.
Onde per cui probabilmente la scelta e' stata anche motivata dai 
meccanismi che Oracle metteva a disposizione.

Certo potevano essere usate altre soluzioni o altre tecniche, o magari 
mettere in piedi piu' macchine o piu' DB. Ognuna avrebbe avuto i suoi 
pregi e i suoi difetti.


Andrea.

Paolo Cavallini ha scritto:
> 
> Scusate se cerco di metterla piu' sul semplice: a me (cittadino, ancor
> prima che GISsaro) SigmaTer piacerebbe se fosse implementabile anche con
> FOSS. Il fatto che richieda (se interpreto correttamente)
> *necessariamente* un determinato DB proprietario me lo rende antipatico.
> pc