sok level tarolasa hogyan

Adatbázis: SQL, XML DB

Adott egy program, ami leveleket (nem fa, hanem email) tarol (folyamatosan jonnek a levelek, legyen mondjuk 10 millio osszesen), es a kerdes az, mi lenne erre a leghatekonyabb es a legbiztonsagosabb struktura/adatszerkezet/whatever? A hatekonysagot teljesitmenyre ertem (=idoegyseg alatt minel tobb level tarolasa*), mig a biztonsagot az adatvesztes elkerulesere ertem (pl. adatbazis crash vagy fsck utan). A levelek tarolas utan mar nem modosulnak.

*: gzip utan blowfish titkositassal

3 dolog jutott eszembe elso korben:

- particionalt InnoDB tabla (mysql, esetleg percona-server)
- valamilyen hazi gyartmanyu binaris adatszerkezet**
- valamilyen (preferaltan journaling) filerendszer, pl. xfs
- sqlite3 db** (de ez ketszer is meggondolando, mert tobb processz nem tudja konkurensen irni, es mar a tesztek alatt is beleszaladtam ebbe, amire workaround-ot kellett talalni)

Te mit hasznalnal?

update:

**: ez(eke)t nem ugy ertem, hogy 10 M level 1 db file-ban lenne, hanem idonkent ujat nyitnek, azaz egy db file-ban pl. 10k level lenne

( b | 2011. 11. 01., k – 20:46 )

- folyamatosan jonnek a levelek
- 10 millio osszesen

Ez egy SQL szeró lesz. Ha van pénz akkor Oracle ha nincs akkor is lol. (MySQL)

--
GPLv3-as hozzászólás.

Postgres. :) Van már benne replikáció is, ami nem elhanyagolható, ha menteni is akarsz vagy pusztán kell egy másodlagos példány is.

Ha InnoDB-zel, akkor a files_per_table-t nem árt belőni ennyi táblához és adathoz. Van aki szerint szentségtörés, de a böszmenagyfile-os db szolúciókban nem tudok igazán megbízni.

Ami igazán érdekes kérdés, hogy diszkkel hogy fogod bírni ezt és mennyi ideig tartod meg?

hat, ha postgresql vs. mysql, akkor nekem az utobbi jobban bejon (de lehet, hogy csak azert, mert azt jobban ismerem). IMHO a 99,9+% insert es select sql muveletekere mar a mysql is elegge kiforrta magat :-)

Ha InnoDB-zel, akkor a files_per_table-t nem árt belőni ennyi táblához és adathoz.

Azt mindig beallitom, de itt a leveleknek 2 db tablajuk lesz (1 a fejlecnek es 1 a body-nak, es esetleg egy kulon tabla a mellekleteknek - deduplication rulez), ezert is sanszos a tablak particionalasa.

Ami igazán érdekes kérdés, hogy diszkkel hogy fogod bírni ezt és mennyi ideig tartod meg?

Ma nezegettem 1-2 pdf-et kulfoldi szabalyozasokrol (GLBA, SOX), es azok 5-7 evet irnak elo, de alapvetoen policy-tol fugg a dolog. Van olyan termek, amelyik a hirleveleket pl. 3 honapig orzi meg az archivumban, aztan torli.

A diszk miatt nem faj a fejem. Majd a felhasznalok annyit vesznek a gepbe, amennyi kell. A Barracuda megoldasa pl. par GB-tal szamol fejenkent.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Engem a MySQL mindíg meg tud lepni valami csellel, amire bazira nem számítok. :)

Ha sok insertet akarsz, akkor érdemes több táblába tenni a fejlecét és a body-t is szerintem. A csatolmányok _annyira_ nem lesznek vészesek, feltéve ha nem base64-el rakod el őket, hanem blob mezőbe. :) Lehet tévedek, de az InnoDB a tranzakciózás miatt egyszerre két insertet ugyanabba a táblába, főleg ha indexet is kell frissíteni, nem fog megcsinálni és feltorlódhatnak a levelek. Az hogy mi alapján legyen több tábla igen nehéz kérdés és rögtön kell egy olyan index tábla ami tudni fogja, hogy melyik email melyik tároló táblákba került.

Az is érdekes kérdés, hogy az MTA-hoz melyik fázisban akarod integrálni vagy csak egyszerűen egy proxy, ami _minden_ be és kimenő emailt elment aztán majd lesz valami velük.

Ha sok insertet akarsz, akkor érdemes több táblába tenni a fejlecét és a body-t is szerintem.

miert? Az InnoDB egy "high-reliability and high-performance storage engine" - doksi szerint

A csatolmányok _annyira_ nem lesznek vészesek, feltéve ha nem base64-el rakod el őket, hanem blob mezőbe.

blob-ba teszem a base64 adatot (ahogy van) tomorites + titkositas utan

Lehet tévedek, de az InnoDB a tranzakciózás miatt egyszerre két insertet ugyanabba a táblába

miert?

főleg ha indexet is kell frissíteni, nem fog megcsinálni

lesznek indexek, de nem ertem, miert ne tudna ezt megcsinalni

Az hogy mi alapján legyen több tábla igen nehéz kérdés és rögtön kell egy olyan index tábla ami tudni fogja, hogy melyik email melyik tároló táblákba került.

mysql eseten ezt particionalassal oldanam meg. Jo talalmany :-)

Az is érdekes kérdés, hogy az MTA-hoz melyik fázisban akarod integrálni

eppen proxy is lehetne, de inkabb egy olyan felallasban gondolkodom (oldja meg mas a spamszurest, per user szabalyok implementalasat, stb.), hogy a mail szerver a journaling feature (kb. mint az always_bcc postfix eseten) segitsegevel atpasszolja az archivalo gepnek (dedikalt gep lenne), majd az a PERIOD (.) utan feldolgozza, es tarolja a levelet, majd visszaadja, hogy 250 OK.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Az always_bcc vagy exim unseen -el az lehet a baj, hogy a rendszer beállítása/hibája (vagy egy bofh admin) szabályozni tudja, hogy mi kerüljön oda. Ha az MX előtt archivál akkor csak a létező fiókok problémakörét kell lezárni, de minimális a külső hatásokra érzékenység. Ha ez nem szempont, akkor persze bőven jó ez, viszont a postfix felhasználók lehet örülnének egy proxy jellegű megoldásnak is (postfix -> content-filter -> mailarchive -> postfix).

Kutattam kicsit a mysql manban és kiderült erősen MyISAM közeliek az emlékeim meg lemaradtam a particiókról is náluk. :) A mentségem, hogy külső kulcsok vagy tranzakciós igény felmerüléskor postgresql volt a következő lépésem, csak 1-2 kivétel fordult elő.

http://dev.mysql.com/doc/refman/5.5/en/concurrent-inserts.html
http://dev.mysql.com/doc/refman/5.0/en/table-locking.html
http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-model.html

A base64-et nem lenne célszerű dekódolni és utána tömöríteni + titkosítani? Elég nagy az overheadje.

"A base64-et nem lenne célszerű dekódolni és utána tömöríteni + titkosítani? Elég nagy az overheadje."
+1

Eloszor azt hittem en is, hogy megbirkozik az azonos entropia mas reprezentalasaval, de nem. A tomoritveny.tar a thunderbird konyvtaram (rajta vagyok egy par levlistan egy ideje, 1.3GB), a .7z ennek a tomoritett valtozata, a .base64 az eredeti base64-el, es a .base64.7z ennek a tomoritettje. Optimalis esetben (esetleg mas tomoritoprogrammal) a .7z es a .base64.7z merete kozel azonos kellene, hogy legyen, de jol lathatoan ez nem teljesul. Szoval ajanlott eloszor visszaalakitani es utana tomoriteni+tenni blob-ba.

nyos@hex:/tmp/x$ du -ks *
1339400 tomoritveny.tar
381228 tomoritveny.tar.7z
1809656 tomoritveny.tar.base64
524016 tomoritveny.tar.base64.7z

--
Az emberek azt állítják, hogy múlik az idő, az idő viszont csak mosolyog, mert látja, hogy az emberek múlnak. - tibeti közmondás

ez engem is meglepett :-) es egy xls file ill. base64 kodolt valtozatan en is lattam a kulonbseget. Viszont meg azt is figyelembe kell venni, hogy ha pl. x darab levelet ki akarunk exportalni, akkor azt vissza is kell majd alakitani base64-be - hogy megint email legyen belole.

Megfontolom a dolgot. Vegul is a dekodolassal egybekotve megejtheto a gzip-peles + titkositas is.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Ez jó kérdés, de lehet hogy valami levlista szerű HTML-ben is jól olvasható forma hasznosabb adott esetben. Ebben elég egy http link a csatolmányra, amit persze ettől még exportálni kell. Olyat is el tudok képzelni, hogy egy csak olvasható IMAP (webmaillel vagy akárhogy) hozzáférés jön létre az exportált levelekhez és szintén url-ben van a csatolmány.

Ez alól kivétel, ha kifejezett elvárás hogy a levelek abszolút változatlan formában legyenek előállíthatóak. Ehhez viszont archiválás, meg szétbontás előtt valamilyen hash-t kell készíteni a mailről és visszaállításkor ellenőrizni kell.

Ha hirtelen 10k emailt akarnak lekérni, az szerintem semmiképpen sem lesz "klikkelünk és megvan" sebességű, főleg ha masszív forgalmat kell közben menteni is.

Az exporthoz valamilyen katalógus jellegű lehetőséget is tervezel?

Ha az MX előtt archivál akkor csak a létező fiókok problémakörét kell lezárni, de minimális a külső hatásokra érzékenység.

Na es mi van a virusokkal, a spamekkel, az esetleges bounce-okkal? Szerintem ezeket inkabb az MX-eknek kellene megoldani. Egyedul az AV-t teszem ezek kozul az archivalo gepre. A BOFH tenyleg egy lehetseges problema, de ezt egyszerubb nem technikai oldalon kezelni.

viszont a postfix felhasználók lehet örülnének egy proxy jellegű megoldásnak is (postfix -> content-filter -> mailarchive -> postfix).

akar igy is lehetne, de en egy dedikalt gepben gondolkozom, mar csak a nagy diszkigeny miatt is. Masfelol, ha tobb MX-ed van, es nyilvan tobb van, akkor problemas lehet az, hogy a mailarchive mas gepeken fut. Nem vetem el azert ezt az otletet, meg alszom ra.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

A dedikált vas eddig is egyértelmű volt nekem. Ahol SOK MX van ott szerintem eleve a szűrő és kézbesítő fázis külön van választva. Ahol pedig nincs ott is relatív könnyen kivitelezhető, ha szeretnének ilyet.

Egy ilyen applikáció mitől lesz jobb, mintha azt mondják maguknak hogy hopp csinálunk egy mindent elkapó szűrőt? Attól eltekintve, hogy ez a belsős dolgoktól független blackbox megoldás és belülről nem manipulálható.

Miert lenne ez problema? A content filternek kell megadni, hogy merre tovabbitsa a levelet. A postfix nem ellenorzi vissza, hogy onnet jott-e vissza a level, mint ahova elkuldte content filterre.
Az amavis pl. asszem azt csinalja, hogy egybol meg is nyitja a tovabbmeno kapcsolatot es nem queue-zik. Neked a mailarchive oldalan kell egy queue-t kezelned, majd visszadobod a postfixnek oda, ahol o a content-filtertol jovo adatot varja.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

szamomra egyszerubbnek tunik az, ha minel kevesebb lancon kell egy levelnek vegig mennie, es csak azok a levelek kerulnek az archivalo gepre, amelyek tenylegesen be is kerultek a user postafiokjaba.

Az amavis pl. asszem azt csinalja, hogy egybol meg is nyitja a tovabbmeno kapcsolatot es nem queue-zik.

tudom :-) a clapf sem tart fenn queue-t

Neked a mailarchive oldalan kell egy queue-t kezelned,...

jopofa vagy, ezzel a mailarchive oldalon sem akarok szorakozni...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

A lancok szama mindenkeppen megvan, itt most a gepekre torteno szetvagasrol beszelgetunk. Az, hogy te a localhost:10021 -es portra utaztatod az amavisbol kijovo leveleket, az senki mast nem zavar, mert mindenki ugy kezeli, mintha egy masik gepre menne, aminek tortenetesen 127.0.0.1 az IP cime. Ennyi erovel viszont a mailarchive gepnek lehet mas is a cime.

Es raadasul, ha az amavissal kuldeted at, akkor csak es kizarolag azok a levelek fognak az archive fele menni, amik amugy is kezbesitodnenek (ennek feltetele, hogy a spam/virus levelek policy-ja DROP legyen SMTP oldalon).
Az archive learchivalja, es szepen visszakuldi a levelet a postfixnek.

Ami miatt a mailarchive oldalon kellene valamilyen szinten queue-t kezelni, az az, hogy az amavist nem jo otlet blokkolni, mert akkor mar torlodas jelentkezhet a postfix content-filter sorban. De ha itt egy olyan smtp szerver van, aminek a deliveryje a mailarchive, akkor ezzel gondod nincs, hiszen az smtp szerver megoldja neked a queue-zast. En pl. ezt ugy implementalnam, hogy irnek egy transport agent-et erre a celra, ami elvegezne az effektiv archivalast + tovabbkuldest, a postfixnek meg megadnam ezt az agent-et mint * a transport map-ben.
A masik megoldas, hogy a mailarchive gepen a postfix-nek szinten content-filternek megadni az archivalo agent-et, mert ekkor minimalis address mapping tortenik; es utana az agent az eredeti szervernek adja at a cuccot. Ez is csak leirva bonyolult.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A masik megoldas, hogy a mailarchive gepen a postfix-nek szinten content-filternek megadni az archivalo agent-et, mert ekkor minimalis address mapping tortenik; es utana az agent az eredeti szervernek adja at a cuccot. Ez is csak leirva bonyolult.

igen, egy ilyesmi megfordult a fejemben

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

>> A csatolmányok _annyira_ nem lesznek vészesek, feltéve ha nem base64-el rakod el őket, hanem blob mezőbe.
> blob-ba teszem a base64 adatot (ahogy van) tomorites + titkositas utan

Nagyon rossz ötlet blob használata, mert nincs olyan rdms, ami hatékonyan tudja kezelni az ilyen adatot.. szemben egy fájlrendszerrel.

>> blob-ba teszem a base64 adatot (ahogy van) tomorites + titkositas utan
> Nagyon rossz ötlet blob használata, mert nincs olyan rdms, ami hatékonyan tudja kezelni az ilyen adatot

Nem teljesen értek egyet; ha keveset töröl és sok újat vesz fel (bejövő levelek), akkor elvileg nem kellene borzasztóan töredeznie, nem pocsékolna sok helyet, és ritkán kellene újraszervezni is.

A file-levél megfeleltetés ekkora mennyiségben eléggé taccsra vágna szerintem bármit, vagy meglehetősen mesterséges könyvtárszerkezet kellene hozzá (tartalom alapján hash (hogy jól is szórjon), a hash néhány byte-os szeletei szerint alkönyvtárak). Csatolmányból mondjuk jóval kevesebb kellene legyen (és nagyobbacskák volnának), tehát a file backed blob akár még a kettő előnyeit is ötvözhetné.

ez a trukkos fajlstruktura teljesen jol mukodik, es annyira nem is trukkos, hasznaltam nagy kornyezetben (>100M file), nem voltak listazas gondjaim. (mondjuk mi nem a hash elso 4 karaktere, hanem az elso 8 szerint vagtunk, de az akar overkill is lehet, 4 is siman jo ahogy szamolgattam).

Ilyen szempontból igazad van.. ha csak növekedés van talán nincs belőle galiba.
Viszont még mindig tartom, hogy szerintem sokkal hatékonyabban kezeli egy fs az ilyen jellegű adatokat, főleg mivel erre vannak kitalálva.
Abszolút de nem vágná taccsra a fájlrendszer pár millió fájl.. és tegyél elő egy statikus web kiszolgálót és észreveszed, hogy semmi esélye egy rdms adatbázis-kezelőnek ellene.
Nem véletlen, hogy szinte minden levelezőrendszer fs-t használ a levelek tárolására.

( BlinTux v | 2011. 11. 01., k – 20:49 )

Én GMail-t!

- Évek óta használom és a ~7Gb tárhelyem 89%-a még szabad!
- Soha semmi nem veszett még el!
- Bárhonnét elérhetem.
- Telefonra/más levelezőbe szinkronizálhatom.
- Címkézhetek, kategorizálhatok, szűrhetek.
- Kényelmes, gyors, praktikus.

Ennél jobbat nekem senki nem fog tudni mutatni!
...max a Google :)

Én GMail-t!

legyszi-legyszi, valaki mutasson mar egy fejet fogo, double facepalm-ozo emoticon-t... Szerinted 7 GB-ba belefer 10 M level? 7 GB / 10 M = 700 byte, ez meg a header-nek is karesz.

A listad amugy impressziv, foleg ez: "- Soha semmi nem veszett még el!", meg ez: "- Bárhonnét elérhetem."

Ezzel azt akartam mondani, hogy meg csak a kozeleben sem voltal annak, amirol szo van, ugyhogy inkabb maradj csendben, amig a felnottek torik a fejuket, LOL ...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

értem én, hogy a gmail nem a barátod, de biztosan hallottál róla, h lehet extra helyet venni. ha az átlagos levélméret mondjuk 3k akkor ugye kb 4x7G elég is. szerintem elég sokáig ki tudod fizetni az éves felárat abból a pénzből amiből megveszed az igényeidnek megfelelő gépet 3-5 évre.

ps: a Te specifikációd sem tűnik teljesnek.

hallottam, kossz, de ugy gondoltam, mar pusztan abbol, hogy en akarom megcsinalni, a google mar kiesett a jatekbol. Btw. az a 3k-s atlag levelmeret erosen alabecsult, nalam az elozo honapban inkabb 30k volt ez az ertek.

ps: a Te specifikációd sem tűnik teljesnek.

ooo, kerdezz, es semmit nem hallgatok el :-)

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

A soha semmi nem veszik elt kicsit árnyalja ez:
- http://kocka.blog.hu/2011/02/28/a_legnagyobb_gmail_hiba_evor
- http://computerworld.hu/gmail-leallas-elszamolta-magat-a-google.html
- http://webisztan.blog.hu/2008/08/11/meghalt_a_gmail
- http://index.hu/tech/net/2009/05/24/andrasnak_betelt_a_gmailje/

Mindezzel együtt a gmail szerintem jól működik általában, csak nem árt odafigyelni. :)

( handler | 2011. 11. 01., k – 21:15 )

Haaat ez eleg sovanyka specifikacio. Hogyan erkeznek a levelek ? Mennyi erkezik parhuzamosan ? Mekkora a min/max/avg merete? Mitol lesz "biztonsagos" ? Egy bug vagy memoriahiba miatt random szemetet irt ki az adatbaziskezelo, aztan visszaolvasasnal osszedol - megis mitol lenne biztonsagban az adatod ? Atlag disk kb.: ~10^14bit olvasasa utan produkal egy nem javithato bithibat. A tobbi komponensrol pedig szo sem esett. Evente mennyi bit elveszteset toleralja a spec?

Hogyan erkeznek a levelek ?

SMTP-n :-)

Mennyi erkezik parhuzamosan ?

nehez megsaccolni (ezt azok tudjak megmondani, akik majd hasznalni fogjak), de azt mondanam, hogy elso korben 20 konkurens processz irja majd a leveleket.

Mitol lesz "biztonsagos" ?

attol, hogy nem vesziti el a mar atvett levelet

Egy bug vagy memoriahiba miatt random szemetet irt ki az adatbaziskezelo

ertem, hogy 100.00%-os biztonsag nincs, de egy hw hiba vagy egy kulso sw komponens bug-jat nem erzem a sajat hataskoromnek, de a lehetosegekhez kepest, a realitas keretein belul olyan vegtermek a cel, ami ezeket is kezeli - valahogy.

Evente mennyi bit elveszteset toleralja a spec?

nincs (meg) ilyen spec. Pl. az eloregedo hw miatti problemakat nem en akarom megoldani, uzemeltetesi feladatnak tartom annak a biztositasat, hogy a hw rendben mukodjon. Ha en korrektul diszkre irtam az adatot, akkor reszemrol kesz a feladat, es hw szinten kell (imho persze) azt megoldani, hogy 3 ev mulva is azt az adatot olvashassam vissza, amit kiirtam.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

( KoGa v | 2011. 11. 01., k – 21:23 )

Kerdes: akarsz is kezdeni valamit az emailekkel, vagy csak tarolod oket? Mindet tarolni kell, vagy neha-neha torolsz is? Rendezed valahogy, vagy csak az a lenyeg hogy egy nagy halom adatod el legyen tarolva?

Kerdes: akarsz is kezdeni valamit az emailekkel

igen. Egy email archivalo megoldasrol van szo, amibe az idonkenti (=ritkan, mondjuk naponta 1x lefut egy cron script) torles is beletartozik, ill. keresni, exportalni. A rendezes is kovetelmeny valamilyen szinten, de a levelek indexeleset nem a tarolo megoldas biztositja (a full text search imho nem annyira kiforrott/hatekony meg sql-ben), hanem azt alapvetoen a shpinx search nevu megoldassal tervezem megcsinaltatni. Ettol fuggetlenul egyszeru select-ek azert lesznek az adatbazis tablakra is.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Postgres 8.4-tol (de lehet, hogy 9.0-tol) tud szoveget indexelni (es egyebkent is tobbet tud, mint a Mysql).
De ha csak es kizarolag archhivalni akarsz, akkor vard meg mig osszegyulik par (mondjuk 1000) level, es ezt tedd ki valamilyen tomoritett (solid) file-ba (mondjuk 7zip), ez lesz a legjobb tarhely, ill. tarolasi sebesseg szempontjabol.

--
Az emberek azt állítják, hogy múlik az idő, az idő viszont csak mosolyog, mert látja, hogy az emberek múlnak. - tibeti közmondás

De ha csak es kizarolag archhivalni akarsz, akkor vard meg mig osszegyulik par (mondjuk 1000) level,

meg egy szavazat az fs-re :-) bar igy kell egy kulso utility, ami osszeszedi a felgyult file-okat, es csinal beloluk valami home made adatszerkezetet, ill. igy bonyolultabb lesz a levelek elo/visszaallitasa. Azert kerdeses, hogy ez mennyire serulhet meg mondjuk egy fsck utan, ill. azert torolni nem annyira trivialis egy ilyenbol, mint mondjuk egy sql tablabol...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

azt igen :-) de ha 1 level = 1 file, az problema lehet a keresesnel/eloallitasnal. Van szerencsem a desktop-omon egy ~2200 bejegyzest tartalmazo konyvtarhoz, es ezt kaptam:

time ls|wc -l
2204

real 0m4.541s
user 0m0.028s
sys 0m0.067s

Ezt azert sokallom, ezert is jobb lenne valamilyen indexelt adatszerkezet.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Az indexelest oldja meg az fs vagy a serch engine, vagy akarmi. Attol fuggoen melyik layer-en ertelmezed.

Valoban relevans, h mennyi ido alatt tudod kilistazni a file-okat egy konyvtarban? Lesz ilyen vagy hasonlo funkciora szukseg a rendszerben?

BTW, a tomoritest is megoldhatod fs szinten, ha nem nem akarsz alklamazas szinten bibelodni vele. Meg az sem biztos, h rosszul jarsz. En tuti arra mozdulnek el elso korben.

tompos

Valoban relevans, h mennyi ido alatt tudod kilistazni a file-okat egy konyvtarban? Lesz ilyen vagy hasonlo funkciora szukseg a rendszerben?

ehh, igazad lehet.

BTW, a tomoritest is megoldhatod fs szinten, ha nem nem akarsz alklamazas szinten bibelodni vele.

Ez csak akkor jatszik, ha transzparensen titkositani/dekriptalni is tud. Melyik fs-t ajanlod?

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Nyilvan nem, de lesz annyival rosszabb, hogy ne erje meg? Behozza az arat azon, h tobbet kell utykodni a problema egyeb megoldasan? Egyaltalan er annyit az egyeb megoldas, hogy megerje, h kezelni pl. egybol nehezebben lehet?

A titkositas egyaltalan mit jelent? Titkositott FS? Titkositott file-ok? Titkositott device?

Egyaltalan mekkora adattomegrol van szo meretre?

ZFS:
Hasznalom. A zfs-fuse befurdott, igaz adatvesztes nelkul. A nativ megoldas egyelore elvan, de csak egy secondary backup szerveren.
A glusterfs levlistan mostanaban elovettek a temat es egesz jokat hoztak ki, de inkabb csak teszt rendszereken.

Viszont nem volt kikotes a linux:)

Ha az, de csak az idegen kornyezet miatt, akkor nezd meg a debian/kfreebsd-t. Ha a freebsd veto mondjuk ceges policy miatt, akkor meg nezd meg a solarist, bar ott az ingyenes verzioban lehet, h limitekbe utkozol, mintha olyan remlene.

Van meg a lessfs, ami erdekes elgondolas (dedup-ra talaltak ki, de tud tomoriteni is), de nem tudom, mennyire nevezheto stabilnak.
Van meg hasonlo temakorben az opendedupe (java-s), arrol meg azt sem tudom, hogy tomoriteni tud-e. Viszont ha ebbe az iranyba mesz el, erdemes lehet megnezni.

Melyik az az fs, amelyikre backup nelkul rabiznad az eletedet?

tompos

Nyilvan nem, de lesz annyival rosszabb, hogy ne erje meg?

Nem nehez sima fs-re (ha mar 1 level = 1 file) gzip+blowfish komboval kezelt blokkokat kiirni, es mar keszen is vagyunk-

Viszont nem volt kikotes a linux:)

akar freebsd is lehet, bar szkeptikus vagyok, hogy a ZFS elegge kiforrott-e solaris-on kivul. Meg a solaris sem kizaro ok, de (ha lehet), akkor nem ragaszkodnek egyetlen OS-hez. Meg kulonben is, ki tudja? Tan meg HP-UX-on is menni kell majd neki.

Melyik az az fs, amelyikre backup nelkul rabiznad az eletedet?

jogos, valami mentes is jo lesz majd bele, de ez mar egy masik tortenet.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

> Nem nehez sima fs-re (ha mar 1 level = 1 file) gzip+blowfish komboval kezelt
> blokkokat kiirni, es mar keszen is vagyunk-

A kiiras konnyu, bar ebben a felallasban az overhead eleg nagy lenne, nem?
Viszont ezert erdekes, h utana mit is akarsz vele csinalni. Ha pl. csak X nap utan torolni, akkor megfelelo. Ha bongeszgetni vmi oknal fogva, akkor mar nem biztos...

Szoval a felhasznalas modjatol fugg eroteljesen, szerintem.

t

bar ebben a felallasban az overhead eleg nagy lenne, nem?

CPU terhelesre gondolsz? Egy atlagos spam level (amiket jelenleg kuldok ra) eseten a tomorites+titkositas ideje ms-ekben merheto. Kell hozza memoria is (kb. 2*levelmeret), azonban ezek egyelore belefernek, de majd csinalok teljesitmenyteszteket is.

Viszont ezert erdekes, h utana mit is akarsz vele csinalni. Ha pl. csak X nap utan torolni, akkor megfelelo. Ha bongeszgetni vmi oknal fogva, akkor mar nem biztos...

bongeszni is ugy, hogy a tarolt peldanybol elo kell allitani az eredeti levelet. Viszont a bongeszes nem azt jelenti, hogy egyenkent dekriptalom+kitomoritem a leveleket, hanem - ahogy zeller is irta lentebb - az SQL-ben tarolt metaadatok alapjan talalom meg, hogy mely levelek erdekesek pl. egy kereses szempontjabol, mondjuk azok a levelek, amelyeket te kuldtel az iden nekem (<- ez egy lehetseges keresesi feltetel).

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

> CPU terhelesre gondolsz?

Nem, a helyfoglalasra, ami csak arra megy el, h titkositasz, meg tomoritesz.

> az SQL-ben tarolt metaadatok alapjan talalom meg

Ez jo akkor, ha elore definialtan tudod, mi alapjan fogsz kesobb keresni (nyilvan a header-ek).
Akkor letarolod az sql-ben, ami kell es jol van. A keresesnel pedig eloveszi a user fix-en azt, ami kell neki es kesz.
A problema akkor johet elo, ha a user a kereses eredmenyei kozott akar bongeszni, nem?
Tehat a keresese alapjan kiad a rendszer 1k levelet es on-the-fly nezni akarja a user, melyik is kell neki (itt mondjuk sokat segithet egy rendes search engine esetleg).
Ezert erdekes, h mi is lesz a valos felhasznalas, ill. egyaltalan kell-e a file szintu, vagy elegseges lehet pl. az fs szintu.
En elkepzelni sem tudom, mi a franchoz kellhet a titkositas egy ilyen esetben:D

tompos

Nem, a helyfoglalasra, ami csak arra megy el, h titkositasz, meg tomoritesz.

nem ertem. A tomorites eleve kisebb meretet ad, es az utana kovetkezo titkositas kb. max. +100 byte extra meretet ad ehhez hozza. En ezt nem latom tul nagy vesztesegnek.

A problema akkor johet elo, ha a user a kereses eredmenyei kozott akar bongeszni, nem?

hogy problema lesz-e, azt meg nem tudom, de azt igen, hogy biztosan fog a user bongeszni a kereses eredmenyei kozott, ezert is kell egy hatekony megoldas, ami pikpak eloallitja az archivumbol az eredeti levelet.

En elkepzelni sem tudom, mi a franchoz kellhet a titkositas egy ilyen esetben:D

magahoz az archivalashoz nem letszukseglet, de vannak olyan szabalyozasok, amelyek 'tamper proof' tarolast irnak elo. Na ehhez az elso lepes a titkositas.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Ha file-onkent tomoritesz, akkor mindegyiknel szamolnod kell ezzel. Ha egy (vagy tobb) nagy file-lal szamolsz, akkor ertelemszeruen aranyosan kisebb 'pazarlassal' kell szamolnod. Sokmillio kis basz file-nal jelentos lehet.

> hogy problema lesz-e, azt meg nem tudom, de azt igen, hogy biztosan fog a user bongeszni a kereses eredmenyei kozott, ezert is kell egy hatekony megoldas, ami pikpak eloallitja az archivumbol az eredeti levelet.

Erre nyilvan vmi RO service lehet a leginkabb megfelelo. Akar imap, akar pl. sqwebmail.

Nem ertem tovabbra sem, miert segit ezen a titkositas? Vagy az az alapfelteves, h elkepzelheto, h a device-hoz hozzafer illetektelen, de a privat kulcshoz nem?
De ami lenyegesebb, tovabbra sem vilagos, mi kell neked, file szintu titkositas, vagy akar FS szintu?

tompos

Nem ertem tovabbra sem, miert segit ezen a titkositas? Vagy az az alapfelteves, h elkepzelheto, h a device-hoz hozzafer illetektelen, de a privat kulcshoz nem?

Az az alapfelvetes, hogy a levelek integritasat meg kell orizni. Azt erzem, hogy egy a kello energiat raszano tamadot (aki lehet a rendszergazda is) megakadalyozni nem lehet (foleg nem egy nyilt forrasu megoldasnal), de a realis kereteken belul szeretnem ezt minel nehezebbe tenni.

De ami lenyegesebb, tovabbra sem vilagos, mi kell neked, file szintu titkositas, vagy akar FS szintu?

file szinture gondoltam

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

A levelek integritasanak a megorzeset nem tudod garantalni semmilyen rendszerben, csak a root tevekenyseget tudod max. auditalni, nem?

OSS vagy nem. Rosszul gondolom? Azon felul hogy tudod nehezebbe tenni?

Ha a cel a file szintu titkositas, akkor viszont a hajadra kenheted pl. a deduplikaciot, akar a file akar, de akar a block szintut, nem? Marad az, h irsz hozza egy alkalmazast, ami szukseg eseten ki/be csomagolja a tartalmat a file(ok)-nak.

tompos

A levelek integritasanak a megorzeset nem tudod garantalni semmilyen rendszerben, csak a root tevekenyseget tudod max. auditalni, nem?

valaki felvetette az idobelyegeket, amit egy kulso fel biztosit (mondjuk ez extra koltseget jelent, de ha olyan a kornyezet, pl. egy penzugyi szervezet, akkor kipengetik). Szetnezek meg, hogy a PKI segithet-e ebben.

OSS vagy nem. Rosszul gondolom? Azon felul hogy tudod nehezebbe tenni?

pl. a titkosito kulcsot valami nem trivialis helyre teszem, egyedi serial key-t adok minden telepiteshez, ami valamilyen nem dokumentalt modon beleszol a titkositasba, passz.

Ha a cel a file szintu titkositas, akkor viszont a hajadra kenheted pl. a deduplikaciot, akar a file akar, de akar a block szintut, nem?

A deduplikaciot pedig egyelore mellekletre ertettem. Az pedig ugy lenne deduplikalva, hogy a levelben csak egy pointer mutatna a kulon tarolt mellekletre. Halottam olyan megoldasrol, ami MIME reszekre szedi szet a levelet, es mindet csak 1 peldanyban tarolja. Ez azonban majd egy 2.0-s verzioban lesz (ha egyaltalan).

Azon is ragodtam meg egy sort, hogy mennyire sanszos az, hogy valaki hajszalra ugyanazt a leveltorzset elkuldje 2x is, azaz a levelnek csak a fejlece modosul? Mert ha nincs ilyen sok, akkor a levelet nem kell szetszedni kulon fejlecre es torzsre. Azonban ha megis, akkor egy csomo duplikatum lesz tarolva, ami csak a datumban, message-id-ben + queue id-kben kulonbozik.

Marad az, h irsz hozza egy alkalmazast, ami szukseg eseten ki/be csomagolja a tartalmat a file(ok)-nak.

igen, de ez nem olyan veszes, 3 sor php-ben. A gzip gyorsan kitomorit, es a blowfish pedig a leggyorsabbak kozott van.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

> valaki felvetette az idobelyegeket, amit egy kulso fel biztosit (mondjuk ez extra koltseget jelent, de ha olyan a kornyezet, pl. egy penzugyi szervezet, akkor kipengetik). Szetnezek meg, hogy a PKI segithet-e ebben.

Dehat ha ugy van, akkor meg tokmind1, hogy titkositod, vagy nem.

> pl. a titkosito kulcsot valami nem trivialis helyre teszem, egyedi serial key-t adok minden telepiteshez, ami valamilyen nem dokumentalt modon beleszol a titkositasba, passz.

Dehat ez is fuggetlen az source nyiltsagatol. Rosszul gondolom?

> A deduplikaciot pedig egyelore mellekletre ertettem. Az pedig ugy lenne deduplikalva, hogy a levelben csak egy pointer mutatna a kulon tarolt mellekletre. Halottam olyan megoldasrol, ami MIME reszekre szedi szet a levelet, es mindet csak 1 peldanyban tarolja. Ez azonban majd egy 2.0-s verzioban lesz (ha egyaltalan).

Igen, ezt olvastam. Ez pedig a felhasznalas modjatol fugg. Ha egy altalanos termeket akarsz lefejleszteni, feltehetoen szukseges, mivel lenne ra igeny. Nyilvan pl. egy bankban millio korlevelet kuldenek ki, abban pedig ha jol gonolom epphogy csatolmanyok vannak. Mas kerdes, hogy ezt a meglevo mailszerveruk mar deduplikalva tarolja. De azt mar ti biztos tudjatok, hogy jon a kepbe a ti (te?) termeketek(d).

tompos

uhh, a lehetseges legegyszerubb modon szeretnem megoldani, es akkor inkabb mar freebsd legyen az egesz. Gondolom, Freebsd+ZFS-sel ertetted. Bar jo lenne egy viszonylag platformfuggetlen dolog, ld. eggyel fentebb. Meg azert kerdeses (szamomra), hogy mennyire tud jol deduplikalni a ZFS gzip+blowfish kezelt adatot?

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Nyilván minél több rendszer szolgáltatást használsz, annál kevésbé lesz platform független.

Viszont minek kellene tömörítés meg titkosítás külön? ZFS megcsinálna mindent dedup-pal együtt (vagy ha nincs natív titkosítás ZFS-ben, akkor kötet titkosítást neki). És ahogy gondolom tompos gondolta, levenné ezt a terhet a megvalósításodról.

VM-et én is kerülném mindig, csak azt gondoltam mindenképpen fontos a Linux. Szerintem alap kérdésként merül fel, hogy mennyire szeretnéd saját megoldásokból megoldani. Én szélsőségesen gondolkodnék. Vagy mindent már meglévő, jól kitesztelt megoldásokból építenék fel, vagy nagy részét leimplementálnám, és akkor ott a nagyobb szabadság lehetősége. Kérdés megéri-e.

(Nincs benne nagy tapasztalatom, és bocs, csak kicsit brainstorm-ozok, mert érdekesen hangoznak a felvázolt lehetőségek, és más területen nekem is hasznos lehet).

Viszont minek kellene tömörítés meg titkosítás külön?

nekem az jo, ha a ZFS ezt egyben meg tudja oldani: tomorit, titkosit es meg deduplikal is. Mert akkor minden levelet ahogy jon, csak irnek ki diszkre (ezen felul semmivel nem torodve), es az elobbieket mind megoldja az fs. Jol gondolom?

Szerintem alap kérdésként merül fel, hogy mennyire szeretnéd saját megoldásokból megoldani. Én szélsőségesen gondolkodnék. Vagy mindent már meglévő, jól kitesztelt megoldásokból építenék fel, vagy nagy részét leimplementálnám, és akkor ott a nagyobb szabadság lehetősége. Kérdés megéri-e.

szeretem a sajat megoldasokat, de nem feltetlen akarom feltalalni a kereket. Menet kozben merlegelem, hogy mit erdemes magamnak megirni.

és bocs, csak kicsit brainstorm-ozok,

en is :-)

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Nem egy könyvtár, hanem mondjuk 255*255*255*255 darab, ez négy szint, a levélből generált hash-ből az első négy bájt alapján beszórva a megfelelő helyre. A hash és a levél metaadatai (feladó, címzett, érkezési idő, tárgy, esetleg címszavak/cimkék) mennek DB-be, és a DB-n keresztül prímán lehet használni ezt az adathalmazt.

hmm, ez tetszik. En gondoltam meg a level sorszamara is (1, 2, ...), de ez sem rossz.

Btw. meg arra gondoltam, hogy a leveleket valahogyan deduplikalni kellene. A file mellekleteket ki kell venni belole, es kulon tarolni, ez egyertelmu, de kell-e pl. a level header-t kulon venni a body-tol?

Mennyire realis az, hogy kuld valaki egy levelet 5 cimzettnek a kovetkezo modon:

A) 1 levelet kuld, amiben 5 cimzett van
B) hetfo van, es 5x jut eszebe ugyanazt a levelet egymas utan elkuldeni az cimzetteknek, azaz 5 db levelet kuld el

"A" esetben lehet a (header+body)-t egyben tarolni, de mi van "B" esetben? A level message-id-je es az egesz fejlece is mas, viszont a body sanszos, hogy ugyanaz.

Mennyire vallalhato kompromisszum az, ha a levelet egyben tarolom (header+body) - a file mellekleteket kulon, es a tarolt levelben egy pointerrel hivatkozom ra?

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Pedig kifejezetten hibás elgondolás.
Akkor jársz jól, ha csak alpha és numerikus karaktereket használsz.. így van 62 karaktered.
Az elsőnek célszerű nem numerikust "adni", hogy kompatibilis legyen (xml, html ), valamint kifejezetten nagy értékkel kalkulálni, hogy ne lehessen ütközés.
A hash látszólag jó ötlet, mert nem elég random. Jobban jársz egy random() (String) generátorral..
Másik, hogy egy karakter könyvtárnév kevés.. két alpha+numerikus karakterrel 32xx könyvtárad/fájlod lehet könyvtáranként.. ami még kezelhető.
Szóval Neked inkább x > 4 karakter hosszú random stringre lenne inkább szükséged.

akkor jol ertelek, hogy azt javaslod, hogy amikor egy file-t le kell tenni, akkor generalok egy xxxx alaku (betuvel kezdodo) random stringet, ami 26 betuvel es 10 digittel szamolva legyen kb. 600k lehetoseg, azaz mondjuk a /var/piler/data alatt lesz potencialisan felmillio konyvtaram, amelyek kozott valamelyikbe beteszem a file-t? Vagy valahol elvesztettuk egymast...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Igen.
Dr. Zeller alant rá is mutatott.:)
> Pár millió fájl simán elvan ab/cd/ef/gh/i/ könyvtárstruktúrában, mág akkor is, ha nem hexa, hanem csak decimális számjegyekből áll az útvonal.

Nem tudom mikor jártál oskolába, de ha a 52 * 62 * 62 * 62 szorzatát (4 karakter, 52 = [a-zA-Z], 62 = [a-zA-Z0-)]) veszed, akkor 12 393 056 a végeredmény ma,
holnap kérdéses, ki tudja, hogy alakul a matematika..:)
Ha viszont hozzácsapsz pár karakter, akkor hatványozottan nő.. + 2 karakterrel 47 638 907 264 a végeredmény.. ami már elég nagy hogy minimális
legyen az ütközések lehetősége.

Egyébként a a lényeg, hogy 2 karakterrel 32xx könyvtárad lesz egy könyvtárban (nem félmillió), azokban ismét csak 32xx könyvtár és így tovább, ami kezelhető mennyiség.

Egyébként meg.. van számos problematika a Te esetedben, pl. biztos nem kell minden file-nak külön könyvtár tehát milyen mélységben érdemes egy id-t könyvtárstruktúrára leképezned.

De részemről ennyi.. dolgozni is kell.:) Sok sikert meg egyebet.:)

Nem tudom mikor jártál oskolába, de ha a 52 * 62 * 62 * 62 szorzatát

:-) fentebb irtam, hogy en 26+10-zel szamoltam. Ugy kijon.

a Te esetedben, pl. biztos nem kell minden file-nak külön könyvtár

biztosan nem kell. Sot, egy kazal file lehet ugyanabban a konyvtarban. Igazabol arra gondoltam, hogy egy konyvtarban legfeljebb x db file-t kellene tartani, akar ugy, hogy minden processz kulon konyvtarat ir, aztan ha "betelt", akkor nyitni egy ujat. De ez csak hangosan gondolkodas egyelore.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

jogos. Btw. 2 jeloltem van (Linux alatt): a jfs dinamikusan noveli az inode-ok szamat, igy itt ez nem gond, mig az xfs default 32 bites inode-okat hasznal, ami 4*10^9 entryt jelent (inode64 opcioval mount-olva elvileg nincs ilyen/ekkora limit). Egy 10 TB-os storage eseten es 10k-s atlag levelmerettel szamolva 1G levelet kell tarolni. Ha max. 256^3 darab = 16M konyvtarat hasznalok, akkor szerintem belefer a 4*10^9-es limitbe.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

( GCS v | 2011. 11. 01., k – 21:23 )

MongoDB és CouchDB mennyire jöhetnek szóba? Esetleg Ceph az állományrendszerhez?

lajk :-) az tetszett, hogy ha mongodb-be irsz, akkor az meg semmit nem jelent, mert nem kerult ki diszkre. Bar csak megoldottak ezt valahogy, hogy csak egy minimalis hasznalhatosagot biztositsanak... Egyelore annyi biztosnak latszik, hogy nem elosztott rendszerben gondolkozom, hanem 1 db dedikalt vasban.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

( tompos v | 2011. 11. 01., k – 22:59 )

- ha valoban csak tarolni akarod, feldolgozni nem, akkor szerintem fs (xfs, akarmi)
- relacios db-k nem erre valok, megneznem a nosql-es megoldasokat tenyleg es nemcsak a mongo-t, bar bizos vagyok benne, h azzal is megoldhato tisztesseggel:)
- kereseshez pedig javaslom, h nezd meg a solr-t is\

Azert nekem 10M level nem tunik olyan valoban lehetetlenul nagy mennyisegnek, legalabbis a tarolas szempontjabol.

tompos

- ha valoban csak tarolni akarod, feldolgozni nem, akkor szerintem fs (xfs, akarmi)

OK, de hogy? 1 level = 1 file az fs-en?

- relacios db-k nem erre valok, megneznem a nosql-es megoldasokat tenyleg es nemcsak a mongo-t, bar bizos vagyok benne, h azzal is megoldhato tisztesseggel:)

megnezem majd, a solr-t is, bar nekem bejon a sphinx

Azert nekem 10M level nem tunik olyan valoban lehetetlenul nagy mennyisegnek,

ez egy hasrauteses szam volt, ami eleg nagy mar ahhoz, hogy at kelljen gondolni a dolgot, de tavolrol sem egy hard limitkent gondoltam ra. Egy ezer fos cegnel ez a mennyiseg hipp-hopp osszejon.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

( calamari | 2011. 11. 02., sze – 11:58 )

Cyrus IMAP esetleg. Valami szerint külön mappába szedni a leveleket, ha kell.
A Cyrus megoldja az indexelést és a kereshetőséget.
Magát a kézbesítést meg az MTA. LMTP-n fogadja a leveleket a Cyrus.
A fájlrendszerben meg meglesznek a levelek külön fájlokban.
Szóval ebben az esetben fájlrendszerben tárolod a fájlokat, de van hozzá egy IMAP interfészed.
Pármillió levelet simán visz egy mappában a Cyrus, ezt több év tapasztalata alapján mondom.
Tud particionálni meg mindenféle okosságot.
Titkosításra esetleg LUKS.
Ha így oldod meg akkor egy csomó szopástól, teszteléstől, bugfixtől mented meg magadat, mivel egy már kész tesztelt szoftver megold mindent helyetted.
Mindenképpen meggondolandó. Bocs ha valamit félreértettem.

mennyire jo a cyrus full text search-ben, ill. a fejlec kulonbozo parametereire valo keresesben ill. szuresben from, to, subject, date + levelmeret, mellekletek szama, tipusa, merete, stb alapjan?

Hogy lehet ezzel a komboval megoldani valamilyen szintu deduplikaciot?

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Nem tudom sajnos ezekre a kereséssel kapcsolatos kérdésekre a pontos választ.
Valószínűleg azt tudja, amit az IMAP protokoll tud/lehetővé tesz "Server-side search" keretein belül.
El tudom képzelni, hogy ez lefedi a fent említetteket, utána kell olvasni, kipróbálni.
Magukban a fájlokban persze lehet keresni akármit, meg indexelni is lehet őket, kérdés, hogy ez mennyire szép/jó megoldás.
Deduplikációt kétlem, hogy tudna maga Cyrus, hiszen maga az architektúra úgy néz ki, hogy fájlonként tárolja a leveleket.
Azt valami más rétegben lehet csak megoldani szerintem.

Ha ilyenrol van szo, akkor jo lehet esetleg a dovecot is:

http://atmail.com/kb/2009/installing-apache-solr-with-dovecot-for-fullt…

De itt pl ertelemszeruen nem lehet file-onkent titkositani. Ill. konkretan ez a megoldas az egesz leveltomeget indexeli.
Mintha lenne vmi deduplikacios megoldas dovecot-hoz is, vagy csak terv..:)

tompos

( hrgy84 | 2011. 11. 02., sze – 13:09 )

SQLite-hoz kommentkent meg annyit, hogy ha jol remlik, ilyesmi korlatja van az Exchange JetDB motorjanak is, ezert a db reteget egy kulon szervizbe kiraktak, amit ugya tobb szerviz tud maceralni, de egy processzkent kezeli a db-t.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

vagy az sqlite db-t keverni a file-ok tarolasaval ugy, hogy a zeller emlitette 255*255*... konyvtar az tobb sqlite db. Sot nem is kellene ennyi, hanem csak annyi, hogy a parhuzamos irasok nagy reszet elkeruljuk, ill. egy adott szamu/meretu level tarolasa utan lehet uj kontenert nyitni.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

( Elbandi v | 2011. 11. 02., sze – 14:39 )

Metaadatok adatbazisban (felado, cimzett, datum, stb), levelek fajlban (pl hash kodu fajlnevekben, elso 4-6 karakter konyvtarban: /1/a/c/3/1ac31234 )
A csatolmanyokat ki lehet gyomlalni a levelbol es azt kulon tarolni (ezzek is tabla+fajlok). Arra azonban vigyazz, hogyha jogi eloiras miatt kell tarolnod a levelet (X evig pl), azt ala kell irnod idobelyeggel, es akkor a levelet nem modosithatod (vagy megkell oldani hogy elo tudd allitani bitre pontosan az eredeti levelet).

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Arra azonban vigyazz, hogyha jogi eloiras miatt kell tarolnod a levelet (X evig pl),

az ok vegul is mindegy: lehet olyan ceg, akit nem kotelez erre a tv, de megis archival, mig a masikat azert (is), mert a tv. is kenyszeriti ra.

ala kell irnod idobelyeggel, es akkor a levelet nem modosithatod

az idobelyeggel alairas (igeny szerint) majd egy kovetkezo fazis lesz. Olyan lesz a cucc, hogy ezt a feature-t is hozza lehet majd tenni. Termeszetesen a leveleket nem modositom, es olyan megoldas preferalt, ami nem is hagyja magat. Pont ezen tortem es meg mindig torom a fejem, hogy pl. egy nyilt forrasu megoldasnal hogyan lehet azt garantalni, hogy a tarolt leveleket ne lehessen sem modositani, sem pedig torolni - legalabbis nyom nelkul ne - meg a root hozzaferessel rendelkezo rendszergazdanak sem.

Btw. mit javalsz a deduplikaciora eme szal kapcsan? http://hup.hu/node/108331#comment-1367821

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara