Dotaz: Ukládání mailů do databáze

[(*.*)]

Jak se dají ukládat e-maily do databáze MySQL? Na stránkách postfixu je hodně howto, které ale ukládají maily na na disk do adresářů pod vmail uživatelem. Chtěl bych ukládat maily přímo do databáze. Stačil by mi i odkaz nějakého howto užití tohoto + amavis .... Vyplatí se to vůbec? Jak se to celkově zpomalí?

Odpovědi

[Heron]

Jo, tohle by mě taky zajímalo. Už to řeším pár měsíců. Nenašel jsem ani konvertor MBOX (nebo MB) na SQL.

Podlě mě se to totiž nezpomalí, ale výrazně zrychlí.

[(*.*)]

Jednou už jsem něco takového viděl, ale zamák to nemůžu najít a to už to hledám pěkně dlouho. Hodil by se i komplexnější návod.

[Marek Pasovsky]

Ono to nebude jen o tom domunit 'local delivery' aby misto na disk psal do db. Jeste je potreba sehnat pop3/imap server, ktery bude ochoten e-maily misto z disku cist z db, aby je take dodal uzivatelum .. myslim, ze bude stacit najit takovy pop3/imap server a u nej bude lezet i how-to jak tuhle vlastnost vyuzit
osobne jsem vsak skepticky, nejen nad existnci, ale i nad smysluplnosti takoveho reseni ... zejmena kdyz tak koukam na sve uzivatele, kde prumerny mbox ma pres 1GB v nekolika tisicich e-mailech tak pri par stech uzivatelich s tim bude mit db dost starosti
no, proti gustu zadny disputat - myslim, ze bude stacit nejaky pop3/imap server, ktery tohle podporuje a je to vyresene

Marek

[h7]

KOukni na www.dbmail.org nebo www.oryx.com

[Zdeněk Burda]

Dle mého názoru to nemá smysl, akorát si do budoucna zaděláš na problémy.

Co očekáváš od toho, že budeš mít emaily v databázi? Jak velký objem dat očekáváš?

[(*.*)]

No zatím maily ukládám do maildiru, což mi přijde přehlednější, ale při větším počtu uživatelů a jejich zpráv by to mohlo dělat problémy. Od databáze očekávám hlavně rychlost, přehlednost a snadnost při spravování ´´učtů.

[Martin Hudec]

Predstav si tri polgigove mailboxy v databaze.. Okej, to este ide :).. ale aku databazu chces vyuzit? A kolko RAM bude mat spominany server?

[Heron]

Email není od toho, aby se do něj ukládali GB data. Průměrný email má pár kB.

[Zdeněk Burda]

Jaké problémy u Maildiru očekáváš?

S tou snadností spravování účtů si polepšíš, pokud budeš mít například konfiguraci uživatelů (účty, hesla, antivir, antispam...) v databázi (provozuju to tak a mám i docela dost instalací za sebou), ale data nechávej klidně na disku v Maildiru.

[(*.*)]

Tady na abclinuxu i na jiných diskuzích jsem se dočetl, že filesystem takové množství souborů nesnese. Snad jen xfs a to jestli.

[Luboš Doležel (Doli)]

Kolik těch mailů plánujete? Teď mám na svém Reiseru skoro 700 000 souborů a problém s tím není.

[(*.*)]

Tolik asi ne. Tak je to asi vyřešeno. Jen bych se chtěl zeptat, když budu mít uživatele uloženy v mysql, se spamassassinem je to jasný, spamy se budou ukládat do user/Maildir/.Spam ,ale po projití amavisem by se ukladáli do /var/virusmail, to už asi nejde uložit jo do třeba user/Maildir/.Virus ?

[Zdeněk Burda]

Uživatelům se viry nedávaj. Pošle se jim upozornění že email obsahoval virus a komentář ve smyslu "jestli fakt chceš toho vira, tak mi napiš, tvůj admin" a je to.

[Heron]

Já udělal test s 3mil soubory a to rozumně nezvládal žádný FS. Naproti tomu 5mil záznamů v DB není žádný problém.

[Kyosuke]

Pořebuješ souborový systém, který je efektivně databáze. ReiserFS, by měl mít stejnou asymptotickou rychlost přístupu k položce jako databáze s B-Tree secondary access method, ne? Přinejmenším je to strom. Přiznávám ale, že jsem se v jeho vnitřnostech zatím nevrtal.

Jinak řečeno, principielně přeci není důvod, proč by to nešlo ve filesystému. Nejvyšší čas, aby se kvalitní FS začaly používat.

[Heron]

No nenašel jsem ho. Zkoušel jsem reiser, ext3, jfs, xfs. Žádný nefungoval tak efektivně jako DB, která je na vysoký počet záznamů a co nejrychlejší select stavěná (na rozdíl od FS, který má za hlavní úkol jiné věci, než efektivně prohledat miliony souborů).

Nevím, ukládání mailů do DB mi přijde naprosto logické. Naopak mi přijde nelogické mít 3GB textový soubor (MBOX) se statisíci emaily.

[Kyosuke]

Myslím, že je celkem jedno, jestli ten soubor má 300 MB nebo 3000 MB. Jestli je archivační, vůbec na tom nesejde, mazání bude zřídkavé a compacting se dá udělat celkem snadno. Na hledání může být index stejně jako k databázi - a měl by být! Mám pocit, že třeba Evolution si ho dělá, dokonce fulltextový.

To neříkám na obhajobu MBOXu, jen mi přijde, že většina problémů je spíš s implementací než s konceptem.

Ve světle OS/400 a VMS RDB nevidím jediný důvod, proč by databází nemohl být souborový systém...problémem je snad jen fakt, že Unix je na takové věci příliš nechápavý... Ale iniciativy typu Reiser4 tomu snad učiní přítrž. Přeci jen v mezích zákona by k nějakému mírnému pokroku dojít mohlo, ne?

[Filip Jirsák]

Myslím, že je celkem jedno, jestli ten soubor má 300 MB nebo 3000 MB. Jestli je archivační, vůbec na tom nesejde, mazání bude zřídkavé a compacting se dá udělat celkem snadno. Na hledání může být index stejně jako k databázi - a měl by být! Mám pocit, že třeba Evolution si ho dělá, dokonce fulltextový.

Aby mohl server pracovat s e-maily efektivně, musí si k mboxu nebo maildiru vytvořit metadata, která popisují jednotlivé části e-mailu (aby se nemusel pokaždé znovu parsovat) a zaindexovat. Pak se takové poštovní schránky chopí Evolution nebo Thunderbird, který je zaměřen hlavně na POP3 a IMAP používá jen tak "bokem", všechny e-maily (nebo aspoň většinu) si stáhne do offline cache a zaindexuje si je. Uživatel se samozřejmě ke své poštovní schránce nepřipojuje jen z jednoho počítače, ale putuje po celé síti. Takže, v lepším případě, má e-maily na specializovaném poštovním serveru, ale přistupuje k nim skrze kopii e-mailů na souborovém serveru. V horším případě (cestovní profily Windows) má e-maily na serveru, a kopii celé schránky i s indexy si při každém přihlášení stahuje po síti a při odhlášení odesílá zpět. Mně to teda připadá padlé nahlavu.

Mimochodem, to ukládání e-mailů do mailboxů/maildirů jde proti koncepci Unixu, kdy každý program dělá jen jednu věc. Protože na hledání může být index stejně jako k databázi - a měl by být, a tak si poštovní server naimplementuje svou malou databázi…

[Heron]

Mimochodem, to ukládání e-mailů do mailboxů/maildirů jde proti koncepci Unixu, kdy každý program dělá jen jednu věc. Protože na hledání může být index stejně jako k databázi - a měl by být, a tak si poštovní server naimplementuje svou malou databázi…

Přesně tohle mě napadlo, když jsem si vybíral (a nevybral) emailovýho klienta

[Filip Jirsák]

Jenže ResiserFS ten strom používá nejspíš pro hledání sektoru začátku souboru dle čísla inode. Souborový systém může ještě tak maximálně strom používat k hledání názvu souboru. Obsah souboru ale IMHO žádný souborový systém neindexuje (tedy s výjimkou WinFS, nebo jak se má jmenovat ten zázrak, co měl být ve Windows Vista a bude až později). Databáze oproti tomu může strom používat k vhledávání v libovolném sloupci tabulky.

Navíc i kdyby filesystémové stromy mohly něco urychlit, nemá k nim aplikace přístup. Když potřebuje (třeba IMAP) otevřít třetí soubor v pořadí, nemůže zavolat žádnou funkci open(3rd), ale musí si načíst seznam všech souborů, seřadit je a najít třetí a n a ten pak dát open(file_name). Pro tu nejkritičtejší operaci (najít 3. prvek) by se sice strom FS dal použít, ale aplikace ho nemá k dispozici.

[Kyosuke]

"Jenže ResiserFS ten strom používá nejspíš pro hledání sektoru začátku souboru dle čísla inode"

A není tohle nesmysl? Operace nalezení prvního sektoru podle inode je snad otázkou jednoho diskového fetche, alespoň v tradičním unixovém FS. Problémem je hledání čísla inode u velikých adresářů ve filesystémech, které adresář implementují jako prostý lineární vektor dvojic (název, inode).

Jestliže bude v adresáři třetí soubor mít název "0000003", aplikace ho otevře pod tímto názvem. Následně FS musí najít inode, což je u tradičního unixového FS obecně O(N) operace, pokud hledám náhodný soubor v adresáři s N soubory, ale pokud FS udržuje mapování z názvů na inody ve stromu (Reiser, tuším...), pak je to O(log N). Takže aplikace má ten strom k dipozici, poněvadž adresuje soubory podle názvů.

Nebo mi něco uniklo?

[Kyosuke]

Hmm, jestli jsem to pochopil správně, tak Reiser bude mít pomalejší hledání inode podle čísla, ale i tak, 2xO(log N) by mělo být rychlejší než O(1)+O(N), alespoň tedy u toho velkého adresáře...

Že já blb si ještě nenašel čas si ty papery projít...

[Heron]

Tohle je sice pravda a je dobré, že moderní filesystémy jdou touto cestou, ale FS si neporadí a z principu ani nemůže poradit např. s vyhledáním všech emailů od autora X ne starší než Y dnů. Tohle je na jeden SELECT do DB.

[Kyosuke]

"moderní filesystémy"

Jsou různé dimenze modernosti... Podle některých z nich není z linuxových FS moderní ani jeden. Pro některé dnes již bohužel zapomenuté (nebo nepříliš běžně používané) by totiž tahle indexace zřejmě nebyla problém. Ach jo, jak já se těším na Reiser4.

Zrovna to řeší kamarád, co vyvíjí über-programovací jazyk, že tradiční FS je moc omezený a že ho do svého operačního systému nechce. Perzistentní heap by byla docela sranda.

[Kyosuke]

Jinak teda pokud je dnešní situace tak tristní, co takhle implementovat mysqlfs, přidat rozhraní pro dotazování a vystrčit na Billa prostředníček?

[Heron]

Jinak teda pokud je dnešní situace tak tristní

Tristní... Těžko říct. Častěji než bych byl rád narážím na problémy u věcí, kde bych čekal, že jsou dávno vyřešené (no možná že jsou, ale firmy na to mají patenty a není to open source ).

[Libor Klepac]

neco takoveho uz myslim existuje, pro FUSE ...

[Kyosuke]

Mno jo, ale FUSE zní nebezpečně... Kdo by chtel používat FS, jehož jedna implementační vrstva se jmenuje ROZBUŠKA?

[Heron]

Zrovna to řeší kamarád, co vyvíjí über-programovací jazyk,

Mno až vystřízlivým z oslav po státnicích, tak se vrhnu na MBOX2SQL. A udělám nad tím pár testů. Na netu jsem to nikde nenašel, pokud někdo něco podobného zná, tak prosím, dejte sem link.

Perzistentní heap by byla docela sranda.

Tak to zcela určitě

[Kyosuke]

Taky nenašel, i když jsem dneska hledal, ale vzhledem ke struktuře MBOXu by to mělo být za chviličku, ne?

Jo a grafuluju!

[Heron]

Dík.

Mno, za chviličku to určitě nebude.

Nechci vzít MBOX a všechny emaily dát do jedné tabulky. To bych si moc nepomohl. Například by bylo dobrý dát odesílatele (kontakty) do vlastní tabulky a do hlavní tabulky emailů dát jen jejich ID -> rychlejší vyhledávání podle kontaktu. Atd. Toho se tam najde víc, zatím jsem nad tím moc nepřemýšlel.

[Josef Kufner]

Ale tak to je snad základní věc, když se na něco používá databáze

[Heron]

Ano to je.

Mno ale viděl jsem tabulky ... no škoda mluvit. Každý zná dost odstrašujících případů.

[Filip Jirsák]

"Jenže ResiserFS ten strom používá nejspíš pro hledání sektoru začátku souboru dle čísla inode"

A není tohle nesmysl? Operace nalezení prvního sektoru podle inode je snad otázkou jednoho diskového fetche, alespoň v tradičním unixovém FS. Problémem je hledání čísla inode u velikých adresářů ve filesystémech, které adresář implementují jako prostý lineární vektor dvojic (název, inode).

Měl jsem na mysli hledání souboru ve velkém adresáři, moc jsem to zjednodušil

Jestliže bude v adresáři třetí soubor mít název "0000003", aplikace ho otevře pod tímto názvem. Následně FS musí najít inode, což je u tradičního unixového FS obecně O(N) operace, pokud hledám náhodný soubor v adresáři s N soubory, ale pokud FS udržuje mapování z názvů na inody ve stromu (Reiser, tuším...), pak je to O(log N). Takže aplikace má ten strom k dipozici, poněvadž adresuje soubory podle názvů.

Pokud bude mít uživatel ve složce 1000 e-mailů a rozhodne se třetí smazat, soubory 000004 až 001000 se přečíslují? Děkuji nechci A zrovna IMAP musí umět vyhledat e-mail podle jeho "absolutního čísla" – identifikátoru, který se nemění (pokud je to možné), i podle pořadí e-mailu ve složce. A to ještě nemluvím o vyhledávání podle obsahu…

[Filip Jirsák]

Objem dat v řádu gigabajtů by snad pro databázi neměl být žádný problém, ne? Navíc u databáze můžu s východou použít indexy pro různé třídění a vyhledávání – to musí IMAP server buď řešit také (a mít nějaký vlastní index), a nebo pokaždé prohledávat maildir (a to pak výkonostně asi nebude nic moc).

Jak dnes vůbec řešíte mailové schránky? Uživatelé jsou zvyklí na gigové schránky z freemailů, poštu nemažou ale archivují… Mně osobně to moc nejde dohromady s klasickým pojetím schránek – maildir, nad tím IMAP server a poštovní klienti, kteří si stejně minimálně část dat z IMAP serveru lokálně cachují, lokálně nad tím vyhledávají – to pro gigové schránky moc použitelné není…

[h7]

Kdyz jsme u fs v db , kouknete na http://www.noofs.org/ ,ma nekdo odvahu?

[(*.*)]

Jak vás tady pozoruji, dám tam asi ověřenej xfs a maily budu mít v maildiru

[Marek Pasovsky]

pokud pomineme, ze SGI (autor xfs) zkrachovalo, tak je rozhodne lepsi volba nez ta db

Marek

[Kyosuke]

Ještě nezkrachovalo... XFS by taky crashnout nemělo...

[(*.*)]

Co máte proti xfs? Na internetu jsou o tomto fs přímo ody, že je nejlepší na velký počet malých souborů a že i nástrojů na stpravování to má mnoho.

[David Watzke]

To je pravda, to je jeho výhoda. Nevýhoda je ta, že je hodně citlivý na výpadky.

[Kyosuke]

Jak, něco proti XFS? Já proti XFS nemám vůbec nic, to bych nemohl provozovat IRIX.

[(*.*)]

A sakra, to je teda velkej problém s těmi výpadky. Kterej fs je na výpadky nejméně citlivý? Zatim jsem zkoušel reiserfs a ext3 a neměl jsem s nima problémy.

[VícNežNic]

Myslím, že výpadky by se dít neměly. Vypadává proud? Pořiď si UPSku. Nestabilní hardware? Nový stojí pár korun… Nestabilní software? To už není vůbec co řešit. Vypadnout to samozřejmě může a stane se to, ale nemělo by. Když už, je třeba vyřešit příčinu a ne shánět něco odolnějšího proti výpadkům, to je krajní varianta.

[(*.*)]

No ten server bude ve skole v reku, tedy uz je, ale ne z databazi, upska se do reku nevesla a tak je na nem, cas od casu prijde uklizecka a omylem vytahne kabel, to jsou ty vypadky.

[Josef Kufner]

Tak to musis ten kabel lip uklidit.

[Jesus Jimenez]

Nebo parkrat slusne a jednou velmi neslusne (resilo se to tenkrat az v reditelne) tu uklizecku napomenout, ze sem mi proste s hadrem nepoleze. Tak jsem to onehdy udelal ja a byl klid :)

[David Watzke]

Ext3 je v pohodě.

[(*.*)]

A co si mam vlastne predstavit pod tim nachylny na vypadky? Vzyt je to journal ne? To jako jednou vyxtahnu napajeni a muzu znova instalovat?

[Kyosuke]

Žurnál je PPZ (prostředek poslední záchrany). Navíc povětšinou chrání metadata...tj. když už o něco přijdeš, abys nepřišel o všechno.

[David Watzke]

Změny to prostě dlouho drží na disku. A nevím jestli pro to existuje option něco jako commit pro ext3, ale nejspíš ne.

[David Watzke]

's/na disku/v paměti/' - achjo

[Pavel Stárek]

Existuje, viz dokumentace k ext3. Můžeš zkusit polaborovat.

[Zdeněk Burda]

XFS drží hodně informací v paměti, ale neboj se. Používám ho už hodně dlouho na různých strojích (notebook, domácí stroj, mailserver, fileserver) a každý z nich několikrát vypadl (došel proud a podobně). Na notebooku jsem měl špatnou základní desku tak jsem ho taky resetnul třeba 10x za sebou a nepřišel jsem o nic.

Každopádně kabel prostě ukliď nebo zakaž uklízečce přístup k racku ať si vybereš jakýkoliv FS.

[(*.*)]

Ta ona uklízečka to udělala jen jednou, ty kabely jsou dobře schované, ale jistota je jistota. Nikdy nevím, kdy přijde nějaká nově přijatá 80-letá uklízečka, kterou napadne odtáhnout rack aby tam vytřela prach