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 [email protected] https://lists.osgeo.org/mailman/listinfo/qgis-it-user
