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

From: Paolo Cavallini <cavallini(at)faunalia(dot)it>
To: itpug(at)lists(dot)itpug(dot)org, pgsql-it-generale(at)postgresql(dot)org
Subject: [Fwd: Re: [Gfoss] [OT] Architettura Sigmater: era Architettura SIT Open Source]
Date: 2008-01-31 09:07:34
Message-ID: 47A18FD6.3080608@faunalia.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-it-generale

a me pare una stronzata. che ne dite?
pc

-------- Messaggio Originale --------
...
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.
--
Paolo Cavallini, see: http://www.faunalia.it/pc

Browse pgsql-it-generale by date

  From Date Subject
Next Message rotellaro 2008-02-04 12:27:18 Rilasciato PostgreSQL 8.3
Previous Message rotellaro 2008-01-23 11:34:38 E' disponibile la Release candidate 2 di PostgreSQL 8.3