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@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@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.
_______________________________________________ QGIS-it-user mailing list QGIS-it-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-it-user
