Dnes se dozvíte, proč byste měli používat DBMail, Email systém s SQL
backendem.
25.5.2005 06:00 | Radim Kolář | czytane 8443×
RELATED ARTICLES
KOMENTARZE
Kde se vzali?
Nejen u IBM toužili ukládati maily přímo do databáze. V širém Internetu se
našlo pár jedinců, kteří by si to také rádi vyzkoušeli. Jelikož je to velký
úkol, vyžili tedy Síť a spojili své síly. Člověk by si řekl, že se
vyrekrutovali z řad znuděných databázových adminů, kteří trpí profesionální
deformací ukládát vše možné i nemožné do Databáze aby porazili Filesystém.
Jako vždy, tak i zde by se hluboce mýlil....
DBMail
Jak již nejen přechozí díl, ale i název napovídá - Jedná se o poštovní systém
s SQL backendem. Podle oficiálních informací je systém vyvíjen firmou IC&S Linux Professionals společně s vývojáři
rozmístěnými po světě. Neoficiálními se tu nebudeme zabývat.
Domácí stránkou projektu je www.dbmail.org.
Mrkneme se tam a podíváme se, co nám tam píší. Po přečtení úvodních announcí
nám bude jasné, že Ilja Booij je vedoucí celého pojektu neboli THE MAN a že
projekt přešel z nekonzistentního systému pro správu verzí CVS na jeho
zmodernizovanou podobu zvanou SVN.
Proč používat DBMail
1. Oddělení mail uživatelů od zbytku systému
Největší praktická výhoda. Mailoví uživatelé Vám nejen nezaclání v
/etc/passwd a tudíž v systému ani nevlastní žádné soubory a homediry, ale
nepotřebují ani účet v databázi. Jelikož nejsou v systému zaevidováni,
nemohou se tam nějakým konfiguračním omylem dostat např. pokud se při
upgrade systému přesune /bin/nologin do /usr/bin/nologin a podobně. Jsou
tedy "Převážně neškodní". Celému DBMailu tak stačí jediný databázový
uživatel. Nejnovější verze DBMailu umí uživatele autorizovat i přes
LDAP.
2. Škálovatelnost
Pokud máte mnoho uživatelů, tak databáze zvládají lépe práci s větším
objemem dat než filesystém. Problémy s wasted space, způsobené ukládáním
každé zprávy do samostatného souboru, jsou tak automaticky vyřešeny, což
přinese značné úspory diskového prostoru.
3. Lepší zálohování
Databázi lze také snadněji zálohovat. Za dobu existence databází byly
vyvinuty různé zálohovací strategie (online backup, offline backup,
replikace, archive log). Tyto metody lze nyní aplikovat i na poštovní systém
a záloha bude i vždy konzistentní. Navíc s využitím databázové replikace lze
systém přestěhovat během plného provozu z jednoho počítače na druhý.
4. Lepší administrace
Administrativní zásahy se provádějí změnou databáze. Tyto změny lze provádět
odkudkoliv, ačkoliv nejčastější metodou bude použití administrativního
rozhraní napsaného v PHP. Jakmile jsou změny zanesené do databáze, stávají
se hned aktivní. Odpadají tak starosti se zapomenutým restartnutím serveru.
5. Skriptovatelnost
Jelikož maily jsou uložené v SQL databázi, dají se administrativní
zásahy provádět také za pomocí různých sql scriptů. Můžete tak velmi
snadno a rychle odmazávat velké maily nebo staré maily.
6. Eliminace vícenásobného ukládání zpráv
Pokud máte na systému mnoho uživatelů, velmi často se stává, že
je jich více přihlášeno do jednoho mailing listu. Narozdíl od klasických
implementací, DBmail ukládá každou zprávu jen jednou, nikoliv
po jedné kopii pro každého uživatele. Úspora místa je tak znatelná.
7. Robustnost
Databáze již od nepaměti implementují mechanizmy nutné ke zvýšení
odolnosti uložených dat před zničením. Jmenujme např. referenční
integritu, transakce, triggery. DBmail 2.0 zatím ještě transakce
ani tiggery nevyužívá.
8. Rychlost
Rychlost se projevuje pouze ve spojení s MySQL backendem, jelikož PostgreSQL je
využíván značně neoptimálně. Kromě již zmíněné nepodpory transakcí, což u PGSQL
vynáší flush po každém SQL příkazu, je další hlavní brzdou v PGSQL nepodpora
prepared statementů a uložených procedur.
Nicméně MySQL backend dosahuje velmi svižných výsledků. Testování hovoří o
250 přijatých mailech/sekundu. Naopak PostgreSQL v té nejnepříjemnější
konfiguraci (fsync, ATA disk s write cache off, FreeBSD, Exim, ClamAV)
dosahuje zhruba 5 ks/sec. Ačkoliv to není mnoho, pro necelou stovku
uživatelů to plně dostačuje.
Na zvyšování rychlosti pomocí mírných optimalizací SQL dotazů se i nadále
pracuje. Do development verze byla přidána podpora pro embedded databázi
SQLite v2 (To je ta rychlejší a jednouživatelská), takže si její příznivci
přijdou na své.
9. Kvalitní podpora IMAP4
DBMail obsahuje kvalitní podporu IMAP4rev1. Podporuje následující extenze:
- OK dbmail imap (protocol version 4r1) server 2.0.4 ready to run
1 capability
- CAPABILITY IMAP4 IMAP4rev1 AUTH=LOGIN ACL NAMESPACE SORT
1 OK CAPABILITY completed
1 logout
- BYE dbmail imap server kisses you goodbye
1 OK completed
přičemž na dalších (THREAD, QUOTA, IDLE) se pracuje. Imap je bezproblémový
zejména ve vztahu k Microsoftím klientům. Naopak poslední
development verze muttu 1.5.9 přestala umět otevírat vnořené foldery,
starší 1.5.6 pracuje ok.
Tu se vzali!
Projekt DBMail je šířen pod licencí GNU. Tento fakt a řada dalších (nepodpora
Oracle, transakcí, stored procedur, triggerů, views, rolí) již nazačuje, že
se jeho developent team nebude skládat z DB adminů.
DB administrátoři totiž zásadně neprogramují hračky ve volném čase v jazyce C.
Místo toho používají jazyk SQL, přičemž vedlejším efektem je zdokonalování se.
Největší bouchači v tomto oboru patří do tzv. 7x24 kategorie (select přes 24
tabulek na 7 stránek) a produkují takové perly jako například piškvorky
naprogramované za použití jednoho rekurzivního selectu, s kterými se pak
předvádí na Obfustrated SQL Contest.
Team DBMailu se skládá primárně z poskytovatelů služeb v oblasti Internetu.
Ti ho mají rádi kvůli jeho low administration cost. To je i můj důvod pro
jeho použití.