[QGIS-it-user] R: Digest di QGIS-it-user, Volume 101, Numero 15

Mar 30 Apr 2024 08:39:30 PDT

Grazie mille per la condivisione

saluti

Il giorno mar 30 apr 2024 alle ore 15:22 Francesco Fiermonte via
QGIS-it-user <qgis-it-user a lists.osgeo.org> ha scritto:

> Ciao,
>
> ho avuto una bella e piacevole chiaccherata con *Alessandro Furieri* (che
> legge in CCN e che ringrazio davvero moltissimo).
>
> Penso sia utile condividere con la lista un "estratto" dei punti che sono
> emersi da questo sostanzioso scambio di e-mail (grazie, Sandro, per rendere
> disponibile il Tuo pensiero).
>
> Per la leggibilità, il testo è stato "adattato", intervenendo anche sulla
> formattazione.
>
> --------------------------------------------------------------
>
> *WAL *= Write-Ahead Logging mentre *SHM *= Shared Memory
>
> e' tutta roba interna di *SQLite*. la spiegazione completa la puoi
> leggere qua:
>
> https://www.sqlite.org/wal.html
>
> -----------------------------------------------
>
> ***** *GPKG-WAL*: Questo file contiene il LOG DI SCRITTURA ANTICIPATA
> (WAL) per la connessione corrente. In pratica, registra lo stato
> transazionale del database tra le operazioni di COMMIT o ROLLBACK. In altre
> parole, tiene traccia dei cambiamenti apportati al database durante una
> sessione di lavoro. *****
>
> invece nel modo *classic *per gli stessi identici compiti viene creato un
> file con suffisso *-journal* che pero' ha una struttura del tutto
> differente e che lavora in tutt'altro modo.
>
> nota che in entrambi i casi questi logfiles devono stare nella solita
> cartella dove si trova il DB.
>
> andiamo un po' a vedere cosa succede in caso di disastro, p.es. dopo una
> caduta di tensione o un crash di sistema.
>
> quando prima o poi andrai ad aprire quel DB che e' rimasto azzoppato,
> SQLite si accorgera' dalla presenza del file di log che ci sono operazioni
> pendenti da sanare. comincia quindi a sbobinarsi a ritroso tutto il log, ed
> alla fine il tuo DB tornera' immacolato e pulito come se nulla fosse
> accaduto.
>
> ovviamente avrai perso tutte le operazioni che non erano ancora arrivate
> ad un COMMIT, ma almeno ritorni al punto da cui eri partito.
>
> -----------------------------------------------
>
> ***** *GPKG-SHM*: Questo file gestisce l’accesso concorrente al database
> tramite un indice verso il file WAL. In sostanza, aiuta a garantire che più
> utenti possano accedere al database contemporaneamente senza causare
> conflitti. *****
> corretto: una *shared memory* e' solo un blocco di memoria che puo'
> essere condiviso tra processi diversi, che cosi' possono scambiarsi
> direttamente le informazioni. insomma, visto che non e' possibile avere una
> vera architettura *client-server* si cerca di aggirare il problema
> facendo cooperare i vari processi passando per la *shared memory*.
>
> -----------------------------------------------
>
> in pratica sono dei meccanismi abbastanza sofisticati che servono proprio
> per dare a SQLite un certo livello di multiutenza. che non sara' comunque
> mai perfetto visto che l'architettura generale non e' intesa per quello, ma
> sicuramente sono un bel passo avanti rispetto al vecchio modo tradizionale
> con cui lavora SQLite.
>
> personalmente li uso pochissimo, perche' ogni rosa ha le sue spine, che in
> questo caso significa che se puta caso qualcosa va storto fare ripartire
> SQLite senza perdere dati protrebbe anche essere una gran bella rogna.
>
> inoltre potrebbero nascere dei conflitti se piu' processi operano sul
> medesimo DB, alcuni in modo *WAL* ed altri in modo *classico*.
>
> se *QGIS* ha deciso di optare per il* WAL* mode dovrebbe significare che
> sono abbastanza sicuri di essere riusciti a mettere in piedi un ragionevole
> sistema di multiutenza.
>
> nota bene che comunque *SQLite* non ama affatto gli accessi remoti via
> rete, per cui in pratica tutti i processi concorrenti dovrebbero girare
> sempre sulla solita macchina dove e' installato di DB ... che ovviamente
> limita pesantemente la condivisione dei dati tra i vari processi.
>
> (...)
>
> quei files temporanei vengono creati autonomamente da *SQLite*, ed
> ovviamente devono stare nella stessa cartella dove si trova il DB quindi tu
> non vedrai mai nulla se lavori su di una macchina diversa da quella dove
> sta il DB, e' consequenziale.
>
> il vero problema sta tutto in questa idea di accedere ad un DB che e'
> fisicamente collocato in un altro PC tramite condivisione di rete.
>
> per quanto mi risulta i ragazzi di *SQLite *non si stancano mai di
> ripetere che e' una ricetta garantita ed assicurata per disastri che
> potrebbero anche arrivare alla "frittura" complete del DB e di tutti i dati
> che contiene.
>
> funziona e funziona bene, ma solo fin quando sia il DB che tutti i
> processi che accedono a quel DB stanno tutti su di un'unica macchina,
> altrimenti e' come giocare alla roulette russa, a volte va liscia ma a
> volte invece no :-P
>
> giusto per entrare un pelo nel tecnico; un buon sistema operativo e' in
> grado di assicurare un rigoroso sincronismo delle operazioni. se qualcosa
> dovesse andare male (crash, caduta di corrente etc) avrai sempre un solido
> punto di ripristino da cui ripartire. magari scoprirai che avrai perso le
> ultimissime operazioni ancora non concluse, ma tutto il resto verra'
> correttamente ripristinato.
>
> ma se nel mezzo ci infili una rete con tutti i suoi tempi di latenza non
> c'e' piu' modo di garantire la sincronicita' complessiva, perche' in caso
> di crash qualche informazione assolutamente critica potrebbe essere ancora
> in transito sulla rete e dunque andra' persa per sempre in modo del tutto
> non recuperabile.
>
> conclusione: se per te lavorare in parallelo sul solito DB da piu'
> postazioni client e' assolutamente indispensabile passare a *PostGIS*,
> che avendo una vera architettura client/server ti garantisce una ripartenza
> certa anche nei casi piu' incresciosi. *SQLite *e' meraviglioso, ma non
> e' progettato per questi ambienti, ed e' inutile tentare di tirarlo per la
> coda.
>
> (...)
>
> ****** *SQLITE non è pensato per gestire l'editing concorrente* *****
>
> assolutamente no.
>
> ci sono diversi trucchetti per tentare di aggirare il problema, ma per
> l'appunto sono semplicemente dei trucchetti (e pure rischiosi). per gli
> accessi concorrenti c'e' *PostGIS *che e' fatto apposta.
>
>
> ***** *Ma allora, i due piccoli files ( "GPKG-WAL" & "GPKG-SHM") sono
> davvero necessari? E se si, a cosa servono? ******
>
> e' semplicemente una scelta degli sviluppatori; se tu apri il DB *SQLite *in
> un certo modo lui attiva diligentemente il *WAL *mode, altrimenti lavora
> nel modo classico ... ma questo ovviamente non significa affatto che poi le
> cose funzioneranno come ci si aspetta.
>
> questa e' una responsabilita' che cade interamente sulle spalle degli
> sviluppatori e dei loro utenti. che magari dovrebbero essere ben
> consapevoli del fatto che il *WAL mode *su rete ha i suoi lati oscuri e
> pure pericolosi.
>
> giusto per capirsi; io personalmente ho usato con buon successo il *WAL *mode
> su un *WEB server *dove avevo un unico processo abilitato in scrittura e
> millantamila processi che accedevano solo in lettura ... cosi' funziona di
> sicuro e funziona pure bene, ma se si pretende di scrivere simultaneamente
> da parte di piu' utenti si sta sicuramente andando in cerca di guai.
>
> ****** Visto che è bene operare in regime di "single-user" (ciascuno
> gestisce, in locale, il proprio database), i due files temporanei sono
> "inutili". Ma, se così fosse, perché mantenerli? Sbaglio a pensare?******
>
> dipende ... io personalmente uso sempre i buoni vecchi *journal-files *e
> mi sono sempre trovato benissimo.
>
> altri sviluppatori potrebbero avere idee o esigenze diverse in cui magari
> il *WAL *e' piu' performante. dipende dai casi (e pure dai gusti
> personali).
>
> ****** Usando un GPKG in QGIS i due files TMP vengono creati perché - in
> linea teorica - il DB supporta l'editing concorrente ma è meglio non usarlo
> a meno che dati e processi non risiedano tutti sulla stessa macchina. ******
>
>
> *P.S.* giusto per la curiosita' di saperlo. nel mio lavoro (...) sui *server
> *uso molto spesso dei *DB SQLite* belli ciccioni da* diversi GB* ;-)
>
> volano come i missili e ci accedono per la consultazione via *WEB *un
> casino di utenti ... ma sono tutti *in sola lettura* ;-)
>
> i dati "freschi" entrano sempre tramite *Postgres*, e solo a cose fatte
> vado ad estrarre i db di lavoro *SQLite * che alimentano i servizi *WEB *di
> consultazione.
>
> ... e detto per inciso, uno* SQLite *ben ottimizzato rispetto a *Postgres
> *e' come vedere una moto super sport che gareggia con un TIR :-P
>
> ma il nostro ciclo di lavoro e' molto particolare, la programmazione dei
> servizi cambia solo 1-2 volte al mese, per il resto del tempo tutto resta
> invariato.
>
> per l'appunto, dipende da caso a caso.
>
> --------------------------------------------------------------
> ---
> Un Caro Saluto,
> Francesco
> <https://www.dist.polito.it/personale/scheda/(nominativo)/francesco.fiermonte>
> --------------------------------------------------------
> This message and its attachments are private and confidential. If you have
> received this message in error, please notify the sender and remove it and
> its attachments from your system.
> -----------------------------------------
> e.o.f.
>
> _______________________________________________
> QGIS-it-user mailing list
> QGIS-it-user a lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-it-user
>

-- 
*Salvatore Fiandaca*

Questo documento, allegati inclusi, contiene informazioni di proprietà di
FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario
in relazione alle finalità per le quali è stato ricevuto. E' vietata
qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso
di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega di
informare tempestivamente il mittente e distruggere la copia in proprio
possesso.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.osgeo.org/pipermail/qgis-it-user/attachments/20240430/275dc667/attachment-0001.htm>