( bucko | 2017. 02. 22., sze – 15:19 )

A tárolás ésszerűen megválasztott - konfigurálható méretű - konténerekben. Kivétel a nagy méretű fájlok.
Tartozik hozzá egy index, amiben a keresendő jellemzők és pointerek vannak. Egyes fájltípusok tar.gz formátumban igény szerint.
Igaz, ez egy backup rendszer. Fejlesztők akkor használják, hogy egy adott rendszer adott logjából (mondjuk napi 12GB) meg szeretnének nézni egy intervallumot. Várakozási idő nincs, pedig a kiszolgálást shell és awk (no, jó - egy kis C is) végzi.
Itt a tárolás lényege a tömörítés. Ebből következően az olvasás mindig gyorsabb, mint a diszk. ;)
A keresés 99%-ban az indexben történik. Az index text, de tetszőleges nem sql adatbázisban is lehetne.

A tervezés a 16^N dir típusú, igen népszerű, de nagyon lassú tárolási mód ellenében készült. Így a fájl és dir mennyisége alacsonyan tartható, azaz nem lassítja a rendszert. A másik előny, hogy lényegtelen a tároló sebessége.

Maga a rendszer végesállapotú automata, és teljesen automatikus. Jelenleg 128 ügyvitel rendszerről/16 szerverről gyűjt irdatlan mennyiségű logokat, tranzakció logokat, adatbázis mentéseket, és a data store-t (szkennelt dokumentumok, stb.), összesen 10-12 féle adattípust.
A gyűjtés kvázi-online, azaz 5-10 perc késleltetéssel kerülnek az archivumba a gyűjtemények. A rendszer tranzakciót is kezel, ezért nincs elveszett adat.

VAN a rendszerben sql is, amibe gyakorlatilag az index kerül bele mégegyszer: 1db gyűjtemény=1 sor.
Ezt jól le lehet kérdezni a webes programozóknak. ;)

Ha leálítjuk legalább néhány órára a rendszert, akkor elkezdi fokozott tempóban behozni a lemaradást. (Elméletileg 1:600000 is lehet a dinamikus sebességnövekedés. Ez olyan mint a dinamikus kontraszt. :)))
Ilyenkor több ezer tranzakció csücsül az adatbázis cache-ben, mert a rendszer erőssége az, hogy nem használ sql-t, ezért gyorsabb is nála. :-D

Természetesen a hálózat maximális terhelése és az archiválási idő is paraméterezhető.

Szóval ez nem a topicnak megfelelő feladat és tárolási mód. Ennek ellenére biztosan kialakítható lenne egy optimum némi józan paraszti ésszel. Inkább a feladatot kell megfogalmazni és számolgatni.
Ebben az backup rendszerben <1000 dir és kb. 6000 fájl tárolja a 30M entitást. A maximális dir mélység a mount pointtal együtt csak 3.