Newsgroup: it.comp.os.linux.software
Titolo: Re: (x Nemesis) XPN: Maildir is a specific one-file-per-message

 nessuna parte (vuoi che sia "lite", vuoi che sia "heavy")
Un RDBMS porta sempre da qualche parte, soprattutto quando si
manipolano dati testuali, numerici o date (ovvero, il 95% dei dati che
vengono manipolati con un RDBMS). Utilizzare Maildir equivale a tornare
ad una gestione simile a quella che si aveva in XPN 1.0.0, ovvero
avresti una scansione di *tutti* i file presenti nel gruppo in modo da
mostrarti gli header, e poi il caricamento del file scelto. Velocizzare
questa situazione, quindi, significherebbe doversi creare un indice
apposito (cosa che fanno sia Thunderbird con il formato mailbox, sia i
server IMAP con il formato maildir). Ma a questo punto, visto che
indicizzare dei dati su di un RDBMS e` una stronzata immane, e che un
RDBMS e` lo strumento piu` indicato per gestire una grossa mole di dati
testuali, perche`si dovrebbe preferire una soluzione custom?
Enrico
P.S. tieni presente che Pan e Thunderbird si sono trovati a dover
seguire una scelta implementativa dettata in precedenza, e quindi si
sono adeguati
P.P.S. avevamo gia` fatto questo discorso, ed era uscito praticamente
quello che sto dicendo adesso. Cosa ti succede, il caldo ti sta
facendo invecchiare precocemente?

 [...]
Manlio Perillo

 superiori a quelle di un RDBMS.
Attenzione che, ad essere pignoli, SQLite *non* è un RDBMS.
E' un semplice database basato su alberi binari, con una macchina 
virtuale e interfaccia SQL per programmarla ad alto livello:
http://sqlite.org/arch.html
Manlio Perillo

 E' Pan gestisce lo scoring anch'esso... ma fa tutto in ASCII.
Si, ma vuoi mettere che un database SQL ho la possibilità di fare delle 
query SQL custom?
Non è una cosa che di solito serve, ma ti viene gratis.
Manlio Perillo

 E ancora parliamo di sqlite?
Dovrei leggere i sorgenti di XPN, probabilmente non è ottimizzato (o è lo 
schema del database a non essere ottimizzato).
Manlio Perillo 

 [...]
P.S: anche io cerco di usare il filesystem quando posso, invece di 
     (ab)usare un database relazionale.
Manlio Perillo

 Deve essere la versione beta 1.5 (la 1.0 non la provare nemmeno)
Sto leggendo i sorgenti, ma direi che il codice non è organizzato al 
meglio.
Innanzitutto non rispetta il PEP 008 (i nomi dei moduli non dovrebbero 
cominiare con lettere maiuscole), infine non usa il pattern Model/View, 
per cui il codice di backend è abbastanza accopiato con la parte di 
presentazione.
Comunque il caricamento degli headers mi sembra ok, non è che magari la 
colpa dell'inefficienza è da attribuire all'algoritmo usato per generare 
i threads?
Hai provato a disabilitare l'opzione:
/MainMenuBar/View/view_group_opts/show_threads
?
Manlio Perillo

 [...]
Manlio Perillo

 rari i casi un cui si hanno problemi di questo tipo.
Non sono esperto di filesystem, non saprei fare commenti.
Magari i limiti sono sul filesystem di Windows...
Comunque, nel caso di XPN, la questione mail-dir vs sqlite non c'entra 
nella questione dell'efficienza.
Pan usa mail-dir solo per salvare gli articoli, ma nel nostro caso le 
operazioni che ci interessano sono:
1) Scaricamento lista articoli dal server
2) Aggiornamento indice articoli per gruppo
   Qui XPN usa sqlite, mentre Pan usa un file di testo.
3) Visualizzazione e threading.
L'ultima fase potrebbe causare una differenza di prestazioni se il 
threading è abilitato.
Anche la seconda fase potrebbe causare differenze, se le insert non sono 
ottimizzate.
Innanzitutto farle in una unica transazione, e poi aumentare la cache
PRAGMA cache_size.
Poi proverei anche a modificare l'opzione 
PRAGMA synchronous; 
Manlio Perillo

 casi un cui si hanno problemi di questo tipo.
Adamo, questa e` una *grossissima* stronzata, e lo sai benissimo. I
limiti del file system non sono solo a livello di performance, ma anche
a  livello di gestione. Vogliamo fare un po' di esempi? Ext3 gestisce
massimo 32768 sottodirectory, mentre il numero di file dipende dal
numero di inode impostati al momento della formattazione. Per XFS ho dei
problemi di performance nella creazione e nella cancellazione di
directory. Sia per NTFS che Per ReiserFS ho massimo 2^32 files per
directory. Per FAT32 ho una dimensione massima dei files di 4Gb
per directory
Enrico

 superiori a quelle di un RDBMS.
Te lo ripeto: secondo te a cosa serve la direttiva INDEX presente nel
parametro mail_location di Dovecot?
Enrico
P.S. tra l'altro, di tutto questo a Postfix (e altri MTA) non frega
nulla, in quanto lui si limita a memorizzare il file o in formato mbox o
in formato Maildir, o a redirigerlo su di un MDA

 
ora prova a fare una ricerca sul testo contenuto in quei 1000 file.

 anche DBMail, che si appoggia ai soliti MySQL e PostgreSQL
a voi risulta che Cyrus usi un db per memorizzare i messaggi?
e tra l'altro anche proprietario?
a me sembrava che utilizzasse Berkley DB per memorizzare i metadati e basta.

 sigaretta, fatti una passeggiata e poi torna. Lo trovi ancora li'.
Ora non esagerare però, un gruppo di 5000 articoli lo apre in 3/4
secondi.
Detto questo non metto in dubbio che Pan sia più veloce ... ma XPN è
più completo :-P
Una piccola digressione poi sul formato di salvataggio degli articoli.
Assodato che quello di Pan è più efficiente di quello di XPN ... cio'
non basta per dire che l'indice ASCII batte sqlite ... perchè
semplicemente il mio formato di salvataggio potrebbe non essere quello
migliore.
Io sono passatao ad Sqlite cercando però di mantenere buona parte
delle infrastrutture che avevo gia realizzato, per non essere
costretto a riscrivere tutto, questo potrebbe aver limitato in qualche
misura le prestazioni. Ma per il momento mi andava bene così, ho avuto
un incremento di prestazioni senza dover riscrivere molto codice, e
visto che il tempo mi manca, questo era quello che cercavo.

 Per un singolo gruppo non c'è niente da parallelizzare-
appunto, ... anche se a voler essere perfettini, una volta introdotti i thread
è possibile spezzettare il download degli articoli anche da un singolo gruppo
in più thread che scaricano batch diversi.
-- 
Work is the curse of the drinking classes.
 _  _                  _
| \| |___ _ __  ___ __(_)___
| .` / -_) '  \/ -_|_-< (_-<
|_|\_\___|_|_|_\___/__/_/__/ 
http://xpn.altervista.org

 singolo gruppo in più thread che scaricano batch diversi.
Si, hai ragione, ma non sono sicuro valga la pena.
Manlio Perillo

 
skiplist è sempre un formato tipo BerkleyDB.
per quanto riguarda la citazione, una frase non basta a capire, Cyrus non
memorizza i messaggi in un database. 
"Using a database as the main message store for Cyrus is not currently
supported. According to discussions on the mailing list, there is little
benefit in adding such support (given typical IMAP access patterns,
optimizations in the current mail store that make it fast, and the amount
of effort involved to retrofit a different mailstore into the backend), so
it's unlikely to ever be written.
The Cyrus mail store is a normal directory tree, with mailboxes stored as
directories and messages stored as individual files. Some additional
information, eg index data, is kept in the "cyrus.*" files in the
mailboxes.
Cyrus DOES have the option of using databases of various types for storing
some other information, such as authentication data, mailbox lists, etc.
There may be reasons to add a SQL backend to these databases in the future
(in addition to flat, skiplist, and berkeley)."
http://cyrusimap.web.cmu.edu/twiki/bin/view/Cyrus/CyrusMailStoreInDatabase
più chiaro?

 
non ti confermo un bel nulla. qui si parla di imap, e solo di imap. tu non
puoi generalizzare applicando il ragionamento all'universo.
il primo motivo che viene addotto come motivo per non sviluppare un backend
sql è "given typical IMAP access patterns", che in sostanza, per me, vuol
dire che una casella imap viene molto più spesso listata che cercata.
maildir è meno performante nella ricerca rispetto a mbox, ad esempio, perché
deve aprire molti file invece che uno solo.
un newsreader è cosa diversa. io non vedo neanche il senso di scaricare
10000 e passa messaggi per ogni gruppo. uso knode e faccio scadere in
automatico i messaggi dopo 30gg. se voglio fare una ricerca nell'archivio
mi viene più facile usare googlegroups (che usa sql).

 a voi risulta che Cyrus usi un db per memorizzare i messaggi?
Sinceramente non lo so, non ho mai usato Cyrus e mi sono affidato a cio`
che e` stato scritto
Enrico

 che si deve fare un DB sql.
Fammi capire, quindi uno si deve scrivere ad hoc un sistema di
indicizzazione dei dati quando ha un backend che ben si adatta alla sua
situazione e che ha gia` dei sistemi di indicizzazione builtin? Tu si
che sei furbo...
Enrico

 
prova ad usare Opera come newsreader.
apre istantaneamente i.c.o.l.s (10000 header). 
prova a fare una ricerca sul newsgroup, chessò, i messaggi scritti da te. in
un secondo hai il risultato, salvato in una vista. se lo chiudi e lo riapri
la vista è ancora lì, disponibile in un secondo.
indovina? Opera mail salva i messaggi (tutto il messaggio) in un database.
come te lo spieghi?

 
per rsync, che fai, mi porti rancore?
stai facendo un gran casino tra server, client e protocolli diversi.
parlavi di newsreader, limitati a quello. pan usa maildir ed è veloce a
listare, opera usa un database ed è molto veloce a listare e anche a fare
ricerche, xpn usa un database ed è lento. tu sei sicuro che la lentezza di
quest'ultimo dipenda dall'uso di un db invece che di maildir in base alla
tua impressione d'uso, senza uno straccio di bench, non una riga di analisi
del codice, però non dici come mai opera è veloce (non dovrebbe, se il tuo
assioma fosse corretto).

 
non mi ci trovo. 
come ho già detto non tengo molti messaggi memorizzati su knode, quindi per
me non è lento, e poi uso kontact dove ho tutto integrato, mail,
calendario, news e rss. 
però riconosco che se in kmail, che uso con maildir, devo fare una ricerca
tra i messaggi, ci impiega molto più tempo di opera. lo stesso se voglio
salvare come visualizzazione una ricerca, kmail ogni volta riparte da zero,
opera no.

 Si, hai ragione, ma non sono sicuro valga la pena.
Molto dipende da quanti articoli si vanno a scaricare ovviamente, altrimenti
inizia a pesare l'overhead introdotto dall'operazione.
-- 
I hate music, especially when it's played.


 altrimenti inizia a pesare l'overhead introdotto dall'operazione.
Si, per questo dicevo che probabilmente non vale la pena.
Manlio Perillo

 non so come si faccia nel caso di inserimento multiplo.
metti un set_autocommit = off, fai trenta/quaranta insert, e poi fai
commit
Enrico
P.S. ovviamente sto usando pseudocodice e numeri buttati a caso, ma la
ma la sostanza e` quella

 Adesso come fai? Un commit dopo ogni insert?
Adesso faccio tanti insert ... e poi alla fine un unico commit.



Ok, allora è già ottimizzato.
Probabilmente allora la causa della lentezza riportata da Romolo è dovuta 
al threading degli articoli (gli ho chiesto di rifare il test 
disabilitando il threading sia su Pan che su XPN ma non mi ha fatto 
sapere niente).
Ciao  Manlio

 sapere niente).
Non che ci voglia molto in effetti a farla ... comunque mi pare che
qualche misura l'avevo fatta, nno era la ricostruzione dei thread la
parte più pesante, ma il ricarimento dei dati.
Attualmente comunque i tempi sono quelli, diciamo un 3 sec per un
gruppo da 5000 articoli, un po' in più invece ci vuole per la
sottoscrizione del gruppo, in effetti gli insert sembra che portino
via un po' di tempo.


Non sempre. Dipende da cosa stai facendo, e da che problema vuoi
risolvere.
Ad esempio, essendo un FS di natura gerarchico, se un'altra struttura
dati si adatta meglio a risolvere i pattern di accesso tipici che ti
servono, un FS è la scelta peggiore.
Ad esempio, una flat hierarchy è praticamente irrealizabile su FS.


Tu non sai nulla di organizzazione dati, vero?

 Cambia strada, e vedi che i primi risultati buoni si vedranno....
Adamo, in tutto questo macello, c'e` una cosa che veramente non riesco a
capire: a te, usare Pan o XPN cosa ti cambia? Ti interessano le
prestazioni pure? Usa Pan e vivi felice. Ti interessano le
funzionalita`? Allora tieni XPN e fregatene che per visualizzare un
gruppo ci mette piu` tempo
Enrico

 scattare il commit.
Se la connessione e` aperta in modalita` autocommit, allora si, l'INSERT
fa scattare automaticamente il commit. Se non ricordo male, ne parlammo
via mail
Enrico

 [...]
Manlio Perillo


Chi altri lo usa? :)
Più che altro è il miglior nr GTK+-only che ho trovato. 

Enrico 'Henryx' Bianchi wrote:

Si può darsi, e mi pare che verificai che il default di SQLite non è
l'autocommit.
-- 
Know how to listen, and you will profit even from those who talk badly.


 avvengano i commit). Ma non e' che fa anche dei "flush privileges"?
Hmm direi di no.
-- 
I told my psychiatrist that everyone hates me. He said I was being
ridiculous - everyone hasn't met me yet.


 Più che altro è il miglior nr GTK+-only che ho trovato. 
e diciamolo ;-)
-- 
It's not the voting that's democracy, it's the counting.


 Chi altri lo usa? :)
Io? ;)
Enrico
P.S. peccato per i.f.t.mdg... :(

 E io saltuariamente ;)
Tu non hai mai frequentato i.f.t.mdg :P
Enrico


Vero ^^


it.fan.tv.mai-dire-gol, originariamente it.fan.mai-dire-gol.
Per un lungo periodo, un ritrovo per gli ammiratori di Yane e delle
fiorentine alte 2 dita (tranne me che ero trattato a erba).


Ma ne hanno tanti altri strutturali.

 fiorentine alte 2 dita (tranne me che ero trattato a erba).
Non direi, era anche un ritrovo in cui il cazzeggio regnava sovrano. Il
problema e` che quando c'e` molto cazzeggio e poca sostanza, alla fine
la gente si stufa e se ne va. Se poi consideri che non vi e` stato un
ricambio generazionale...
Enrico

> Per un lungo periodo, un ritrovo per gli ammiratori di Yane e delle

Beh, le due cose che ho scritto rientrano nel cazzeggio :P
Il vero problema č il secondo, piů che altro.
E un po' l'esaurirsi del fenomeno usenet in generale...


Per certi usi molto specifici.


Per l'appunto: per usi specifici.

Caretaker wrote:
Mitico Renato che usa XPN! Sta diventando il newsreader per i reduci di
i.f.t.mdg :-)
-- 
There is no pleasure in having nothing to do; the fun is in having lots
to do and not doing it.



Ti sfugge vero?
Proviamoci: organizzare mail in maniera gerarchica *č* un uso specifico.


Non è SQL, ma è un DBMS. 
Ergo, un DBMS è una soluzione valida anche per le e-mail.

 portabilita' estrema.
Ma io infatti non ci perdo affatto tempo, è proprio quello il bello.
Devo solo fare qualche rinuncia per mantere le cose semplici ;-)
-- 
My Grandmother is over eighty and still doesn't need glasses. Drinks
right out of the bottle.


 Poi: 
http://www.sqlite.org/lockingv3.html
Avevo conservato questo articolo con il proposito di riguardarlo con calma ...
... è passato un po' ma l'ho fatto.
Ebbene da una rapida lettura hai link ed un primo test veloce ..
con la sola clausola
PRAGMA synchronous = OFF;
il tempo di sottoscrizione di un gruppo con 5000 articoli passa da 60 sec a 8
sec.
Per il momento mi sembra un buon inizio ;-)
-- 
Between two evils, I always pick the one I never tried before.
