Portál AbcLinuxu, 1. května 2025 05:11
20.10.2007 17:24
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
. Kámoš z toho chce kompletního klienta, ty server - dohodněte se pánové 
20.10.2007 17:45
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Databáze nejsou zrovna úsporný prosředek k ukládání dat.
Otázka je, jestli se vyplatí vymýšlet vlastní optimální formát (a pak už vám nejspíš nezbyde čas nastudovat a naprogramovat všechny ty možné optimalizace, které už mají databáze naprogramované), nebo je lepší použít už hotovou databázi, která bude sice o něco méně efektivní, ale zase dostanete „zadarmo“ spoustu promyšlených optimalizací. Cena diskového prostoru bude dnes pravděpodobně daleko menší, než cena programátora, který zvládne naprogramovat efektivní databázový stroj…
To znamená, že člověk nepotřebuje blbosti typu QL parser a query optimizer a podobně, protože ví, co se s těmi daty bude dělat (přidej email, smaž email č. 13242, najdi emaily podle subjectu...). A těch věcí podle mě není hodně. Ostatně některé mailery to tak řeší, ne? Evolution s mboxem používá indexové soubory, jestli se nepletu.
21.10.2007 07:29
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
přidej email, smaž email č. 13242, najdi emaily podle subjectu...
...Vyhledávej v nich fultextem, seřaď relevantní emaily do stromu podle odkazů, hledej podle autora, data, čehokoliv, vyhledej maily daného autora v rozmezí datumů a jen s daným topicem...
Nene, stále mám pocit, že na toto se víc hodí SQL než souborová hash DB.
A co jako mám použít na ten fulltext? MySQL, které je podstatně pomalejší než Ruby+Ferret?
21.10.2007 18:36
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Prostě nevěřím tomu, že způsob jak to dělají mail klienti je nějak časově efektivní. Je mi jasné, že jejich vývojáři si často říkali něco ve smyslu, "hmm O(n^2), sakra, jak dlouho to bude trvat pro 100 položek? Jo je to hned, necháme to tak." Musí to jít rychleji, jen se to pro jejich počty nevyplatí implementovat. Fulltext nemusí být nutně 
20.10.2007 17:21
ALTER TABLE `xxx` ADD FULLTEXT..., ale i tohle zkusím.
21.10.2007 20:59
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Je mi jasné, že jejich vývojáři si často říkali něco ve smyslu, "hmm O(n^2), sakra, jak dlouho to bude trvat pro 100 položek? Jo je to hned, necháme to tak.Jestli to tak v konkrétním případě opravdu je, tak bych to autorovi otřískal o hlavu. Připomíná mi to obludně velké weby, kdy jen k zobrazení homepage je potřeba načíst 3 MB dat ("na mém připojení je to rychlé").
A těch věcí podle mě není hodně. Ostatně některé mailery to tak řeší, ne? Evolution s mboxem používá indexové soubory, jestli se nepletu.Třídění podle různých kritérií a hlaviček, fulltextové vyhledávání, statistiky… To že si to (téměř) každý klient řeší po svém a má vlastní index a keš uloženou někde lokálně je podle mne největší slabina dnešních e-mailových klientů.
21.10.2007 18:37
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
příliš náročné na výkon.
Tím si nejsem příliš jist, google dokazuje, že to jde. Bohužel pouze na web rozhranní.
A co jiného by klient měl dělat? To už rovnou můžeme vymyslet IMAPv5 s podporou všech těchhle věcí, protože jinak nevidím moc možností, jak to opravdu udělat standardní.Když ten IMAPv5 nebude mít vlastní TCP/IP protokol, ale bude fungovat přes HTTP, dostáváme se už pomalu k tomu, jak bych si to představoval. Že jsou e-maily uložené na serveru a pak ještě jednou na každém klientovi, aby v nich klient mohl vyhledávat, to opravdu nepovažuji za šťastné řešení. Zvlášť když se uživatel přihlašuje pokaždé jinde (jako třeba ve škole) – pak si buď musí index při každém přihlášení okopírovat ze sítě a při odhlášení zpět (srdečné pozdravy cestovním profilům Windows), nebo musí mít index připojený jako síťový disk – takže na serveru jsou ty e-maily jednou ve formátu pro IMAP server, jednou pro poštovního klienta. Nějak se mi tu ztrácí význam té zaklínací formulky „použij IMAP a e-maily máš na serveru“.
Jenomže většina poskytovatelů e-mailu tohle stejně nebude poskytovat - příliš náročné na výkon.Zatímco mít tohle a nad tím jako nadstavbu ještě webové rozhraní, to náročné na výkon není? Kdyby měl GMail zdokumentované rozhraní, přes které si to jejich AJAXové rozhraní povídá se serverem, je to už téměř ono (téměř proto, že je to zajisté proprietární věc, a pro standardizaci by bylo nutné mírně to zobecnit). Ostatně většina poskytovatelů ať si poskytuje co uzná za vhodné, já si vyberu takového, který tohle poskytovat bude. Resp. si to budu poskytovat sám, když bude k dispozici příslušný software. Jenom mi současné řešení zatím nevadí tolik, abych se sám pouštěl do psaní příslušného serveru i klienta – server bych si třeba i napsal, ale použitelný klient, který si poradí s kdejakým v HTML zpraseným e-mailem, nepatří k věcem, které bych toužil psát…
Zvlášť když se uživatel přihlašuje pokaždé jinde (jako třeba ve škole) – pak si buď musí index při každém přihlášení okopírovat ze sítě a při odhlášení zpětTo "ze sítě" tuším již dnes může znamenat z IMAP serveru, ne? Index bude proti všem mailům trapně malý, takže to ani nevadí. Navíc nemusí být "fyzicky" vcelku, takže se zpátky nemusí nahrát celý, ale jen rozdíl (a jednou za čas to slít vše dohromady). Stejně je myšlenka serverového vyhledávání podle mě trochu mimo, páč přecejen ideálem pro mě je všechna pošta šifrovaná.
To "ze sítě" tuším již dnes může znamenat z IMAP serveru, ne?Možná pro PINE, o něm se většinou tvrdí, že umí s IMAPem všechno
Ale pochybuji o tom, že by ten index byl přenositelný mezi různými klienty.
Index bude proti všem mailům trapně malý, takže to ani nevadí.Pro gigové schránky už to nějakých pár desítek mega bude.
Stejně je myšlenka serverového vyhledávání podle mě trochu mimo, páč přecejen ideálem pro mě je všechna pošta šifrovaná.To ale zároveň znamená přístup k poště jen z jednoho míst anebo několika málo míst. Pak vám samozřejmě lokální uložení pošty nemusí vadit. Někdo jiný ale zase chce mít poštu dostupnou odkudkoli se stejným komfortem, a nešifrovaná data na serveru mu nevadí. Dnes existuje jediná možnost, jak tohle zařídit – webové rozhraní. A to zrovna ten nejkomfortnější styl práce. Navíc i to fulltextové vyhledávání by šlo zařídit tak, že klient e-mail rozšifruje, vytvoří z něj seznam slov a ten pošle zpátky na server pro zařazení do indexu. Sice by pak na serveru bylo možné zjistit, jaká slova v e-mailu byla, ale už by nešlo získat přesnou podobu e-mailu.
).
Mít seznam slov z mailu díky nešifrovanému indexu je podle mě až moc. Navíc to předpokládá, že index nebo jeho části si budou klient a server nějak standardizovaně vyměňovat (což jsem teda požadoval i já, ale bylo mi to předloženo jako nevýhoda ).
Ono navíc ne všude, kde si chci přečíst mail nebo ho napsat, musím nutně chtít i vyhledávat, spíš bych řekl, že to se děje ve velké menšině případů, takže zdaleka ne vždy by se musel index mezi serverem a klientem přenášet.
20.10.2007 19:58
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
20.10.2007 20:02
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
.
20.10.2007 20:00
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
20.10.2007 20:19
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
) zacházet jako s plnohodnotným emailem, potřebuji je jen někam uložit, hlavně smazat ty soubory z disku (už jsou týden pryč) a následně nad nimi vyhledávat. Takže ani email server, ani klient. Prohlížeč.
bych zkusil nejaky virtual maildir filesystem pro fuse
Je to v plánu. Mám pocit, že už někdo nad fuse psal FS s daty v MySQL, ale tvrdil, že to bylo pomalé.
Jestli nechces klienta, ktery si indexuje hlavicky...
Jediná cesta je to napsat sám. Klientů jsem vyzkoušel hodně. Dal jsem na rady všech okolo, "tenhle je nejrychlejší, zkus ho". Možná byl. Pro prvních 30 000 mailů. Jediný kdo zvládal tehdy 400 000 emailů byl KMail, nad maildirem* a pop3. TB nad IMAPem je nepoužitelný. TB je vcelku nepoužitelný
*) jako on to není špatný způsob ukládání, přístup k jednotlivým emailům je rychlý, spousta metadat je ve jménu souboru a když se použije velikost bloku 512B, tak to nezabírá ani moc místa. Jenže zkuste si ty soubory pak zkopírovat. Nedočkáte se.
sqlite
Nevím proč, ale k podobným knihovnám mám averzi. Nechápu, proč nepoužít rovnou server. Výkonnostně si polepším.
Je to v plánu. Mám pocit, že už někdo nad fuse psal FS s daty v MySQL, ale tvrdil, že to bylo pomalé.FS nad databazi samozrejme bude mit bezne operce velmi pomale, ale pro specialni pripad, kdy budou pozadovane specialni operace by to nemuselo byt tak spatne. obecne Je problem s rychlosti cteni/zapis. Tam je asi nejlepsi reseni pouzit FS, ktery umi zpracovat mnoho souboru a stejne je ukladat na nem, ale ne vsechny v jednom adresari, ale radeji nejaky squid styl.
Jediná cesta je to napsat sám. Klientů jsem vyzkoušel hodně. Dal jsem na rady všech okolo, "tenhle je nejrychlejší, zkus ho". Možná byl. Pro prvních 30 000 mailů. Jediný kdo zvládal tehdy 400 000 emailů byl KMail, nad maildirem a pop3. TB nad IMAPem je nepoužitelný. TB je vcelku nepoužitelnýTo by mne hlavne zajimalo, jake nejcastejsi a casove kriticke operace se s temi 400k maily delaji a jestli jsou treba tridene a podobne. Protoze ja sice mam radove 100k mailu, ale vetsina jich je bokem, protoze mne zajimaji jednou za nekolik uherskych let.
Nevím proč, ale k podobným knihovnám mám averzi. Nechápu, proč nepoužít rovnou server. Výkonnostně si polepším.Protoze sqlite databaze se dobre prenasi a pro jednoduche veci ala INSERT/SELECT bohate staci a napr driver v QT4 je univarzalni nezavisle na platforme. Pokud chci neco robustniho a sloziteho, tak to samozrejme radeji vrazim do postgresu (vcetne toho, ze je tam vestaveny velmi slusny fulltext)
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
20.10.2007 18:49