[Python] sqlite executemany ed utilizzo/saturazione della memoria...

Pietro Zambelli peter.zamb a gmail.com
Sab 2 Nov 2013 11:11:32 CET


On Friday 01 Nov 2013 19:34:24 Valerio Maggio wrote:
> > Credo che il problema sia dovuto al "circular reference". Io ho 
scoperto
> > questo problema, questa sera... :-)
> > 
> > Quanto è "pericoloso", avete letture o link consigliati sull’argomento?
> 
> Dalla tua risposta, non credo di aver capito a cosa si riferisca la
> “circular reference”. In particolare, non ho ben chiaro se sia relativa
> agli import dei tuoi moduli, alle reference tra gli oggetti o (come l’avevo
> intesa la prima volta che ho letto il tuo post) al modello dei dati che hai
> realizzato (e implementato in SQLite).

Scusa se non sono stato chiaro, ma imbattendomi per la prima volta in 
questo problema mi sono spiegato male! :-)

La "circular reference" che credo sia alla base del mio problema è dovuta 
alla reference tra gli oggetti. Ho creato delle classi che includono altre 
classi, la cosa funzionava bene per numeri "piccoli", ma evidentemente 
quando vado a creare alcuni milioni di istanze, queste non vengono 
adeguatamente pulite dal garbage collector. 

La libreria ("pygrass") fa il wrap utilizzando ctypes di alcune funzioni C di 
GRASS [0]. Molti degli oggetti che creo, condividono un puntatore alla 
stessa struct, ho il sospetto che questo ne impedisca l'eliminazione da 
parte del garbage collector. Nelle prossime settimane cercherò di capire 
come risolvere la cosa, in ogni caso penso che la libreria necessiti di una 
ristrutturazione più generale... e stavo pensando di utilizzare cython invece 
di ctypes per interfacciarmi a basso livello... Ed è per questo che volevo 
capire qual'è il problema per cercare di evitare di introdurre gli stessi 
errori.


> Se le circular-reference riguardano il codice o gli import dei moduli, se
> cerchi in Google, troverai una marea di discussioni e argomentazioni a
> riguardo. Una su tutte, ti segnalo questo post su Stackoverflow [0], la 
cui
> BA punta ad un post su comp.lang.python da leggere.

Grazie per il link, lo leggerò di sicuro.


> Se, invece, la circular-reference riguarda il modello dei dati, allora ti
> condivido i miei 2 cents. Innanzitutto, le circular reference in un modello
> relazionale sono espresse mediante relazioni ricorsive. Le relazioni
> ricorsive sono ampiamente supportate dal formalismo, ma il loro 
supporto
> “concreto” varia da implementazione (del DBMS) a implementazione. Ora, 
non
> saprei dirti nello specifico se e come SQLite gestisca le relazioni
> ricorsive, ma se proprio non riesci a semplificare il tuo modello e hai
> vincoli tecnologici legati all’uso di un Db-SQL, allora prova alternative
> *migliori* tipo PostgreSQL. In soldoni, la domanda che mi porrei io fossi
> in te è: "la normalizzazione dei dati è necessaria? Mi da qualche
> vantaggio?"
> 
> Se, al contrario, SQLite è la “prima” soluzione di memorizzazione che ti è
> venuta in mente di usare e potresti in linea di principio rimpiazzarla con
> altro, io andrei di HDF5 o di MongoDB.

No in questo caso stavo scrivendo nel DB una Tabella completamente 
scollegata dalle altre, quindi mi sento di escludere che il problema possa 
essere stato generato da sqlite...


> La /rule of thumb/ da seguire, imho, è la seguente: se vuoi rimanere su
> memorizzazione file-based, senza dover mettere su server e servizi, HDF5
> [1] è la soluzione. Inoltre, HDF5 ti dà l’enorme vantaggio di essere
> *molto* più efficiente rispetto a MONGO in termini di storage (i.e., spazio
> su disco), considerando che si possono anche applicare algoritmi di
> compressione sul file.
>
> Al contrario, MongoDB [2] vince su HDF5 in termini di performance 
(query
> time - insert/select/update).

Anch'io, quando posso, preferisco HDF5, però mi hai incuriosito su 
MongoDB che proverò alla prima occasione! ;-)

Grazie per aver condiviso la tua esperienza!

Buona giornata

Pietro


-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20131102/0ef70df8/attachment-0001.html>


Maggiori informazioni sulla lista Python