Sok file tarolasahoz hatekony struktura

Adatbázis: SQL, XML DB

Egy 3 -szintu hash-elt (xx/xx/xx) konyvtarban van tobb millio par kB ... MB meretu file. Mivel ennek a mentese nem egyszeru (a file-ok sokasaga miatt), arra gondoltam, hogy jobb lenne / lehetne, ha ez a csomo file valamilyen joval kevesebb szamu (pl. 256 db) binaris file-ban lenne (pl. zip, tar, etc).

Persze nem eleg csak siman egy tar file-ba tenni a sok file-t, olyan szerkezet kell, amibol gyorsan elo tudom venni / kiolvasni a keresett file-t, ill. azt is meg kell oldani, hogy tobb processz is irhassa ezeket a file-okat, ill. torolni is tudni kell a belehelyezett file-okat.

Mit javasoltok erre a celra? Lattam egy megoldast, ami 4096 zip file-t nyit meg, es abba pakolja a file-okat, de hatha van ennel elegansabb es hatekonyabb megoldas.

( zamboriz v | 2014. 09. 07., v – 15:23 )

1 fájl elég. Erre van a sparse (hézagos?) fájl kitalálva. "xx/xx/xx"-ből számolsz bájtpozíciót, odaugrasz, aztán írsz, olvasol, vagy törölsz (FALLOC_FL_PUNCH_HOLE). Ha nincs felső korlátja a "pár-KB" fájlocskáknak, akkor kicsit macerásabb.

( joco01 v | 2014. 09. 07., v – 16:36 )

Lehet, hogy a képzelőerőmmel van gond, de nem látom, mitől lenne jobb. Egy fájlrendszer hosszú évek evolúciója alatt pont arra lett tökéletesítve, hogy sok fájlt tároljon. Te erre akarsz plusz egy réteget rátenni egy tároló fájlformátum szerepében, ami inkább csak lassabb lesz.

Én inkább fs szinten oldanám meg, manapság már lehet értesülni a fájlok változásairól, és akkor nem kellene sok mappát végigolvasni.

--

Igen, meg lehet fogalmazni úgy is a választ, hogy a backup ÚGY hosszú, ahogy a kolléga most csinálja, de lehet azt ésszerűbben is.

De úgy is meg lehet fogalmazni, hogy az adatbáziskezelés - bináris adatoké is - szintén hosszú évek alatt jutott arra a szintre, ahol ma áll.
Magyarul ha a kolléga a fájlrendszer szintjére szeretne húzni egy réteget, azt nem feltétlenül kell a sufniban előállítani, akármelyik BLOB vagy akár CLOB (pl. base64 (de)kódolással) tárolására képes db megteszi.

Szerintem a fontosabb vetület nem az, hogy hogyan backupol, hanem hogy hogyan akarja használni azokat a fájlokat. Egy adatbázis blob elérés maximum hozza az fs performanciáját, de jobb nem lesz nála, és ez igaz kb. bármire. Ezért írtam, hogy maradjanak fs szinten a fájlok, de jobb lenne többet tudni arról, hogy hogyan használja a fájlokat normál üzemben. Ezen felül egy adatbázis fájl nem pont archiválásra van kitalálva, egy dump/backup kombóval nem vagyunk sokkal előrébb sebesség szempontjából.

--

a file-okat egyszer irom ki diszkre, onnantol kezdve nem valtoznak, ill. egy alkalmazas olvassa a file-okat es ad eredmenyt a vegfelhasznalonak. Iras tehat egyszer van (egy random xx/xx/xx konyvtarba), viszont olvasas sokszor van (ahanyszor csak kell a file-ban levo adat), ezert a mar kiirt file-ok gyors elerese must have feature. Kell meg info?

zamboriz sparse file-ja lehetne megoldas, ha fix meretuek lennenek a file-ok, de nem azok, a meretuk par kB es par MB kozott szorodik, ill. ott a torles sem egyszeru, tovabba ha kitorolsz kozeprol egy 152 kB-nyi adatot, akkor idovel lesz egy szep lyukas nagy file-od, ahol nagyon kell sakkozni, hogy mit hova teszel -> tul bonyolult.

A jelenlegi - fs-ben - tarolas amugy teljesen jo, csak egy baja van, amit irtam: csillio kis file-t menteni nem leanyalom. Igy vagy egy jo mentesi modszert kell talalni, vagy egy jo tarolasi megoldast.

Amit eddig probaltam az egy sparse file-on ext2 filerendszert csinalni, amit aztan loopback mount-olva az eddigi filerendszerben tarolast tudom hasznalni. Csak ugye ebbol lehet mondjuk 8-16 ilyened felmount-olva, ami nem biztos, hogy eleg nekem.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Ha a leírt alapokra helyezve kellene ingyen megoldást találnom, azt 


# DAY0
TODAY=`date +%Y%M%D`
TGZ="backup-$TODAY.tgz"
TOC="backup-$TODAY.toc"
find /dir -type f > $TOC
tar -czvf $TGZ -T $TOC


# cron-daily
TODAY=`date +%Y%M%D`
TGZ="backup-$TODAY.tgz"
TOC="backup-$TODAY.toc"
find /dir -type f -mtime 1 > $TOC
tar -czvf $TGZ -T $TOC

alapokra helyezném.
Visszaállításhoz a fordított sorrendbe rendezett .toc fájlokból kinyerhető a keresett darab helye (a lokalitás elve alapján nagyobb eséllyel valamelyik mához közeli deltában).

- o -

Ha a pénz nem volna gond, akkor TSM.

- o -

Ha rám volna bízva az egész, akkor specifikáltatnám, hogy mit jelent a "gyors fájlelérés", és ha az hozható adatbázissal, létrehoznék pár partíciót a tartalom mérete szerint, minimalizálva ezzel a törlések miatti lyukacsosodás I/O-ra gyakorolt mellékhatását és gyártanék 1-2 indexet az elérési utak, fájlnevek, ezek kombója, igény szerinti csonkja kifejezésre.
És persze akkora bufferpoolt neki, amekkorát a fizikai RAM és az egy fedél alatt lakó processzek megengednek.

Rengeteg lehetőség van. Kevesebb fájl kellene? Akkor tárold az xx/xx/xx/ könyvtár fájljait egy xx/xx/xx.dat append-only fájban. Sok kis fájlocska helyett, 1 is elég.

> ha fix meretuek lennenek a file-ok, de nem azok, a meretuk par kB es par MB kozott szorodik, ill. ott a torles sem egyszeru

Nem gond, fix méretűvé lehet tenni őket. Lehet a fájlok helyett egy-egy pointert tárolni egy sparse fájlba, az adatok meg gyűlnek egy(több) append-only fájlba.

Törlés helyett jobb lehet a felejtés. Gyanítom, hogy nem pazarolsz jelentős méretű helyet ha egy törlés során nem történik hely felszabadulás.

"zamboriz sparse file-ja lehetne megoldas, ha fix meretuek lennenek a file-ok, de nem azok, a meretuk par kB es par MB kozott szorodik, ill. ott a torles sem egyszeru, tovabba ha kitorolsz kozeprol egy 152 kB-nyi adatot, akkor idovel lesz egy szep lyukas nagy file-od, ahol nagyon kell sakkozni, hogy mit hova teszel -> tul bonyolult."
A 32 bit elvette mindenki fantáziáját. :(
Egy 8EiB-os fájlba 536870912 (536 millió) 16 MiB-os fájl fér bele.
Mindegyiket fix indexre teszed, a fájlhoz fájlszám*16MiB helyen találsz rá.
A programodból mmapolod a fájlokat (ha elfogyna az 536 millió, nyithatsz újat), és egyszerűen ott lesz a memóriában az adat.
Egy másik fájlban tarthatsz egy bitmapet, vagy adatbázisban a fájl metaadat->sparse fájlnév:fájlszám összerendelést.
Ennél gyorsabbat és takarékosabbat fájlrendszer vsz. nem fog tudni.

Mentésre meg snapshot.

1. az eves brutto fizetesembol nem jon ki a 8EiB-os file tarolasahoz szukseges tesco-s sata diszkek 2 heti villanyszamlaja (szigoruan raid-ben persze, adatvesztes nem opcio, ugye)
2. 500 millional tobb 16 MB-os file mar nem fer be a memoriamba

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

ok, hadd lassam mas szemmel a vilagot :-)

Kicsit ragodva meg a probleman es jobban atgondolva az otletedet (esetleg a lentebb emlitett range locking koncepciojaval) mukodhet a dolog. Viszont gyorsabban megkapom-e az x poziciotol/hoz seek-elve az aktualis 16 MB-os szeletemet, mintsem ha egyszeruen a filerendszertol kernem az xx/xx/xx/abcde file-t?

Viszont meg egy lenyeges kerdes: ha a huge sparse file-bol torlok 123456 db 16 MB-os blokkot (random pozicioktol), akkor van-e mod arra (a teljes sparse file ujrageneralasan kivul), hogy a sparse file altal effektiven elfoglalt hely a 123456 * 16 MB-tal csokkenjen?

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Ebben a szálban:
"a file-okat egyszer irom ki diszkre, onnantol kezdve nem valtoznak, ill. egy alkalmazas olvassa a file-okat es ad eredmenyt a vegfelhasznalonak. Iras tehat egyszer van (egy random xx/xx/xx konyvtarba), viszont olvasas sokszor van (ahanyszor csak kell a file-ban levo adat), ezert a mar kiirt file-ok gyors elerese must have feature."
Erre a javasolt megoldásnál hatékonyabbat én nem tudok. Minden más értelmezésem szerint erre jön rá, megoldott, azaz itt nem kell foglalkozni vele.

"Kicsit ragodva meg a probleman es jobban atgondolva az otletedet (esetleg a lentebb emlitett range locking koncepciojaval) mukodhet a dolog."
Nem olvastam végig a threadet, de minek locking?
Nem csak három művelet kell neked:
- read
- delete
- add
a metaadatok meg SQL-ből jönnének? Mert ha igen, a locking az SQL-ben van. A fájl helyét egy auto incrementes szekvencia adja, vagy egy bitmap, vagy egy free/used lista adja, azaz garantáltan nem lesz ütközés, két processz nem fog egymás területére írni.
Vagy arra gondolsz, hogy a törlés okozhat race-t, mert kitörlöd az SQL-ből, kitörlöd a fájlból, de közben még lehet folyamatban olvasás?
Ha igen, rakhatsz garbage collect folyamatot rá, azaz a törlés az SQL-ből törlésre jelölést jelenti, amit aszinkron szabadít fel egy másik job, és mikor kitörölte az adatot, ténylegesen törli az SQL-t, így felszabadul az a slot.

"Viszont gyorsabban megkapom-e az x poziciotol/hoz seek-elve az aktualis 16 MB-os szeletemet, mintsem ha egyszeruen a filerendszertol kernem az xx/xx/xx/abcde file-t?"
Nézzük miből áll egyik és a másik.
Ha a fájlrendszerből kéred el, és tudod a fájl konkrét helyét (tudod):
- meg kell nyitnod, ez a fájlrendszerben egy rakás műveletet indít be (implementációfüggő, listákon gyalogol végig, vagy hashekben keres, csinál egy rakás dolgot)
- megkapod a FD-on a fájlt
- beolvasod
- lezárod
(persze mmapolhatod is, akkor a beolvasod elmarad, cserébe mmapokat/munmapot hívsz)
A másik megoldás (mmapolva a fájl):
- az mmapnak a téged érdeklő részét meghivatkozod, ha olyan az alkalmazásod, akár zero copy módon

Mérd ki, de nagyon csodálkoznék, ha az első lenne a gyorsabb. Többszörös mennyiségű kódot mozgatsz vele, amely adott esetben diszk IO-t is jelent (fájlrendszer metaadatok).

"Viszont meg egy lenyeges kerdes: ha a huge sparse file-bol torlok 123456 db 16 MB-os blokkot (random pozicioktol), akkor van-e mod arra (a teljes sparse file ujrageneralasan kivul), hogy a sparse file altal effektiven elfoglalt hely a 123456 * 16 MB-tal csokkenjen?"
Erre két megoldást tudok:
- a fentebb említett punch hole-t (google), ez néhol implementált, néhol nem
- ZFS-en ha a tömörítés be van kapcsolva, ha egy blokk csupa nullákból áll, sparse block lesz

Mivel FreeBSD-n legutóbb az első még nem volt, én az utóbbival operálok, azaz nálam a törlés annyi \0 kiírása (egy nagy write), amennyi adatot és ahol fel szeretnék szabadítani. Értelemszerűen ez elvileg pazarlóbb, mint a másik, de nekem eddig még nem volt bajom vele.

hmm, akkor eddig ott jarunk, hogy a 8 EB-t felosztom 16 MB reszre, lesz kb. 5 * 10^11 db 'slot'. Ezt elosztom a processzek max. szama kozott, igy minden processznek jut egy sajat, dedikalt, tagas resz, amibol nagyvonaluan szamolva 10^9 slot tuti kijon. Az aktualis 16 MB-os slot pozicioja + a sparse file neve bele lenne kodolva a file nevebe is, hogy az olvasashoz lehetoleg ne kelljen sql muvelet.

A torles kapcsan a zfs ill. fs-fuggo punch hole implementacio nem feltetlen jarhato ut, mert nem mindenhol olyan fs van (mar mukodo rendszerek), ahol ezek tamogatottak.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

> Viszont gyorsabban megkapom-e az x poziciotol/hoz seek-elve az aktualis 16 MB-os szeletemet, mintsem ha egyszeruen a filerendszertol kernem az xx/xx/xx/abcde file-t?

Elvileg gyorsabb lesz, de ha listázni nem akarsz (sűrűn), akkor csökkentsd le a dir hash mélységet és az is felgyorsul, mert jobb lesz a cache hit ratio. A sok "fájl egy mappában" problémát jól kezelik a modern fs-ek (pl ext4: dir_index), a túl nagy hash depth viszont több cache miss-t eredményez(het) ami drága IO-t jelent.

A hatékonyság kulcsa itt szerintem az, hogy naplózd, hogy mi változott a közelmúltban. Ennek hiányában a sparse file is lassú lesz ahhoz, hogy mindent átvizsgálj benne a változások után kutatva, a birtokában pedig a jelenlegi módszer is elég gyors lehet a mentés lebonyolításához és nem kell ingoványos terepre tévedned.

(Feltételezve, hogy nem az egyszeri teljes mentés teljesítménye probléma, hanem annak a frissítése.)

( gergov | 2014. 09. 07., v – 20:46 )

Én hasonló problémának pont a másik irányból mentem neki.
Van egy csomó apró (meg néhány hatalmas sparse) fájlom egy ext4 fájlrendszeren. Mivel az rsync naaaagyooon sokáig tartott, én a következőt találtam ki:
DRBD-t raktam a fájlrendszer alá. A resource úgy van beállítva, hogy a primary oldalon a párja nélkül is induljon, és így is megy hosszabb ideig.
A mentés egy újraszinkronizálást jelent, ami közben elvileg csak a módosult blokkokat másolja le a rendszer.

A megoldásnak csak annyi a szépséghibája, hogy ha épp a szinkron alatt pusztul el a forrás háttértár, akkor rossz esetben a mentésből is csak egy nagy adag inkonzisztens katyvasz marad hátra. Erre is megvan az ötlet: LVM snapshotot kell készíteni minden futtatás előtt, így elvileg hiba esetén is megmarad a régi mentés. Ez utóbbi csak elmélet, gyakorlatban nem próbáltam összehozni.

( mrceeka v | 2014. 09. 07., v – 21:26 )

Ha file-ként kell kezelni őket, akkor szerintem használj egy meglévő filerendszer típust.
Windows környezetben NTFS-en a file-ok száma kezelhető, mentésére VSS alapú megoldást, pl. System Center Data Protection Managert javaslok.

Üdv,
Marci
A Microsoftnál dolgozom.

( tompos v | 2014. 09. 07., v – 21:47 )

Miert nem jo vmilyen adatbazis? Akar sql v. nosql.

En egyebkent alternativakent zfs-t javalok, a backup-ra pedig a send/recv feature-t:)
Azzal a backup gyakorlatilag a faek egyszerusegu es villamgyors backupot kapod, az altalad leirt eset nagyjabol az elkepzelheto legjobb a send/recv elonyeit/hatranyait nezve.

temerdek adatrol van szo, akar tobb TB-rol is, ami imho kilovi a nosql megoldasokat. A sima sql-ekben nem igazan jo tobb TB-nyi random meretu adatot tarolni. Mennyire stabil a zfs Linuxon?

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Nekem jol teljesit, de azert nincs olyan allapotban, ami alapjan azt mondanam, h 99%-ban mindehova megfelelo tutira.
Az altalad leirtak alapjan valoszinusitheto, hogy a zfs neked igen jo lenne es a ZoL is szinte-tuti. Tenyleg csak megfelelo mennyisegu ECC ram kell neki es jo lesz.

Miert lenne baj a nosql-nek? AFAIK epp ilyenre talaltak ki, tevedek?
Adott esetben pl. a mogilefs-t is megneznem, anno ahol a kezem alatt volt (amugy 1 mar kesz rendszer), stabil volt es gyors.

En az ilyen sparse file-os, zip-es, tar.gz-s stb. megoldasokat kerulnem messzire. Nekem sosem voltak szimpatikusan az ilyen megoldasok, szerintem ronda hack-ek.
Nem mellesleg backup-olni talan meg szarabb is lehet, mivel sokkal tobbet fog kelleni masolni.

"temerdek adatrol van szo, akar tobb TB-rol is, ami imho kilovi a nosql megoldasokat."

Cassandra és a MongoDB is node szinten ajánl 3-5TB adatot, viszont lineárisan skálázható PB méretekig... én napi 30-100GB adatnövekedéssel és 10-15TB adattal már dolgoztam Cassandra esetén. Egészen pontosan melyik NoSQL esetén találkoztál TB-os limittel?

( asch v | 2014. 09. 08., h – 02:21 )

Amit írsz, az pont az a probléma, amire a fájlrendszereket kitalálták. Ha a backup túl sokáig tart, akkor azt kell felturbózni valamilyen trükkel.

Például ha előre van egy méretkorlátod az adatok mennyiségére, akkor veszel egy akkora méretű diszket, amire tuti elférsz, és ezt blokk szinten backupolod. A blokk szintű másolásnál nem nagyon van gyorsabb hozzáférési módja egy HDD-nek. Sok kis fájl esetén sokkal gyorsabb lehet, mint fájlonként olvasni az adatot. Ennek az a hátránya, hogy a mentés idejére le kell állítanod az írásokat.

Ha sok az írás, de kevés a felülírás és a törlés (loggolás-jellegű adatok), akkor journal-t érdemes írni, azt folyamatosan lehet írni, és a delta mentés is egyértelmű. A kereshető adatszerkezetet egy indexnek tekintheted a folyamszerűen tárolt adataid felett. Egyébként ha az alkalmazásod tud journalt írni a műveletekből, és azt újra le tudja játszani, akkor hirtelen végtelenszámú replikációs megoldás lehetősége nyílik ki előtted.

Attól függ, milyen a felhasználás. Ha éjszakára leállítható, akkor diszkenként kevesebb (kb 1TB) adatot tárolva megoldható néhány óra alatt. Nem mondom, hogy túl szofisztikált megoldás, de fejlesztési költségben megtérülhet az egyszerűsége miatt. Minden azon múlik, hogy mi a specifikáció. Amiről nem tudunk sokat.

( bucko | 2014. 09. 08., h – 10:16 )

Hmm, éppen van egy ilyen rendszerem, amely éppen 22.439.276 fájlt tárol. Az adatmennyiség tömörítve kb. 2,5 TB - keterítve legalább a tízszerese. A mentett adatok mérete az egy sortól (~30 karakter) 5GB-ig terjednek.

Elmondom a szempontokat.
- Windows/ntfs bizonyítottan alkalmatlan az n^m tárolóarchitektúra kezelésére.
- Sok egyedi file hatákony tárolására kizárólag a jfs alkalmas. Hátránya, hogy pl. debian alatt "belefagy a kernelbe" :), míg suse alatt működik.)
- Van az a mennyiség, ahol a fs/adatbázis alapból felejtős - konténereket kell használni. (Persze hallottam már a blob és társairól. Felmerül a kérdés: adatbáziskezelővel szeretnél szívni, vagy a feladatot megoldani?)
- Az elérési sebesség lehet kritikus. Az emlitett rendszer kb. 100 komplex ügyviteli rendszer adatbázis/tranzakció log mentéseit és iszonytató mennyiségű naplóit kezeli kvázi-online. Ha egy rendszeren hibát jeleznek, akkor a fejlesztő webes felületen azonnal eléri a tetszőleges rendszer/napló kívánt szakaszát.
- A rendszer paraméterezhetöen automatikusan takarítja magát. Mivel ez egy backup rendszer, az öreg konténerek törlésével takarítható. Ha lyukakat is kellene törölgetni, akkor azt az ésszerűen megválasztott konténer újraírásával lehet megtenni - copy sebességgel.
- A konténerekben találhatő chunk-ok indexeltek, illetve a konténerek forrás/típus szerint különválasztottak. (pl. egy cég, vagy rendszerfunkció könnyen létrehozható, vagy törölhető.)

A rossz hír: ez egy rendszer, meg kellett írni. Az általában nem működik, hogy hasraütésszerűen 256 részer osztunk valamit. :) Inkább részletesen fel kellene mérni a feladatot és az adattípusokat. (Segítek: létezik text és bináris.)

A jó hír: Az összes eszköz: tar, gzip, awk, c. A sebessége 1-2 nagságrenddel gyorsabb, mint az adatbáziskezelőé, függetlenül az adatmennyiségtől.

( dragi v | 2014. 09. 08., h – 10:30 )

Ha backup kell akkor nézd meg esetleg a duplicity-t. Az tar.gz-t csinál és megmondhatod mekkora legyen a tar mérete. És persze csak a különbözetet menti utána. Parancssorból visszaszedi neked file szinten is ami kell. Tehát nem neked kell a tar.gzben turkálni.

--
http://pyftpadmin.earthquake.hu

( kisauto | 2014. 09. 08., h – 10:36 )

-szerintem- Neked egy Content Storage kell.
Annak adott a sebessege is, a kapacitasa is, meg ugy alltalaban pont erre van kitalalva.
Indexelve le tudod kerdezni, melyik file hol van, mikor erheto el ujra, ha archivalva volt.

Nyilvan nem mondhatom, hogy most de rogton vegyel egy Axiont, vagy egy Centerat, de ha ezt hoszabb tavon, igenyesen akarod megoldani, ez az ut jarhato. Azt nem tudok, hogy a kisebb storage gyartok csinalnak -e ilyet ( hamar google nem talalt ), de erdemes egy kort futni.

( Elbandi v | 2014. 09. 08., h – 12:41 )

nalunk is elojott hasonlo igeny: 1 itemhez kellett tarolni 64db kepet, tobb megoldas is szoba jott:
* havi bontasban voltak a fajlok szetszorva, minden honap elejen az elozo honapban keszult fajlokat egy squashfs-be "osszenyomjuk" es csak mountoljuk a fajl (bonyolult, jo sok mount, squashfs fajl limit, stb)
* volt meg masik par otlet, de mar nem emlexem ra :(

Vegul a ffindex lett (semmi koze a ffmpeghez :D) a befuto. egy foo.dat fajlt csinal, az eredeti fajlokat egymas moge fuzi, es egy foo.idx, ami egy txt "nev kezdopozicio meret" sorokkal. a felette levo applikaciokat (nginx, php) okositottuk meg, hogy kepes legyen hasznalni ezt.

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

bonyolult, jo sok mount, squashfs fajl limit, stb

igen, az en aggalyaim is hasonloak. Jol hangzik ez az ffindex dolog. Hogyan oldjatok meg a torlest a foo.dat-bol? Ujrageneraljatok a dat ill. idx file-okat?

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

nincs szuksegunk csomagon beluli torlesre. amugy ha csak az kell hogy "ne latszodjon" a torolt fajl akkor eleg a idx-bol torolni a sort. ha fel is kell szabaditani a helyet, akkor ujrageneralas van (nemkell kulon kibontani/csomagolni, ha jol emlexem tud csomagbol olvas masikcsomagba ir megoldast)

a parhuzamos modositashoz lockot lehet hasznalni. (pl flock)

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

( sj | 2014. 09. 08., h – 13:05 )

kossz az eddigi tippeket, probalom osszefoglalni, hogy eddig hol jarunk:

find-dal megtalalni a valtozasokat (amit menteni akarok) teljesen jo, de tul sok inode-ot kell atnezni. Viszont van egy indexem (=metaadatok), amibol tudom a pontos path-t es az adott file letrehozasanak datumat (es/vagy egy serial-t is). Igy az sql-ben levo metadatok alapjan konnyen elo tudom allitani a tar szamara a mentendo file-ok listajat.

Az xx/xx/xx.dat append-only file azert nem valoszinu, hogy mukodne, mert tobb processznek kell tudnia irni az egyes xx.dat file-okat, bar feljavithato az otlet, ld. lentebb. Lockolassal / varakozassal nem komplikalnam az irast. A felejtes nem biztos, hogy eleg, mert praktikusan sok adatrol lehet szo, amibol (kornyezettol fuggoen) csak az utolso x nap/honap/ev rekordjait kell megtartani, igy a napi torles akar sok file-t / rekordot is erinthet.

A zfs-t lajkolom, solaris alatt mernek ra fogadni, de a hivatkozott topikot vegignezve megoszlanak a velemenyek, hogy ki merne ratenni az eletet is (linux / freebsd alatt). Egyelore ezt a tarsolyba teszem.

Az adatok mennyisegere nincs meretkorlat, igy egy diszk nem feltetlen eleg (jellemzoen lvm-et hasznalok), ill. a megallitom, amig mentek, sajnos nem jarhato ut.

A journal (vs. replikacio) erdekes otlet. A mentes mellett meg ez is egy hasznos dolog lenne, hogy az adatokat mondjuk egy masik adatkozpontba is at lehessen tolni. Eltoprengek rajta. Az fs-eknel megszokott hagyomanyos journal nincs, viszont ld. fentebb az egyes file-okrol van metaadat (path, timestamp, etc), amikkel tan nem remenytelen a replikacio. Csak akkor meg ott van extra feladatkent a mysql db replikacioja.

Kulon termeket (axion, centera, stb) nem vennek a celra.

A kontener dolog is tetszik. Arra gondoltam, legyen mondjuk 20 processzem (ami irja a file-okat / rekordokat) meg vagy 135 kontenerem (1 kontener = 1 binaris file), aztan szetosztom a 135 kontenert a 20 processz kozott, igy nem fordulhat elo az, hogy 2 processz is ugyanoda akarna irni. Ez a file mar lehet append-only, sparse, whatever. De ugye itt is komplikalni kell a torlessel, ill. kerdes, hogy hamarabb megkapom-e a file tartalmat egy nagy binaris file-ban seek-elve, mintsem ha a file-rendszerbol (milyen fs-bol persze) a szokasos open - read - close hivasokkal olvasnam ki.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

DB-ben lévő metaadatok a fájlokhoz jó lehet, az sql select gyorsabb lesz, mint a find (pláne, ha a find bármilyen időadatra is szűr), ergo annak a kimenetét jól oda lehet pattintani akár egy cpio bementére is - aztán amikor a mentés sikeres, akkor az archív fájl visszaellenőrzéséből kapott kimenet alapján lehet a metaadatokat update-elni, hogy "mentve".

aztán amikor a mentés sikeres, akkor az archív fájl visszaellenőrzéséből kapott kimenet alapján lehet a metaadatokat update-elni, hogy "mentve".

igen, valami hasonlora gondoltam en is ezen elindulva

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Az xx/xx/xx.dat append-only file azert nem valoszinu, hogy mukodne, mert tobb processznek kell tudnia irni az egyes xx.dat file-okat, bar feljavithato az otlet, ld. lentebb. Lockolassal / varakozassal nem komplikalnam az irast. A felejtes nem biztos, hogy eleg, mert praktikusan sok adatrol lehet szo, amibol (kornyezettol fuggoen) csak az utolso x nap/honap/ev rekordjait kell megtartani, igy a napi torles akar sok file-t / rekordot is erinthet.

Én nem lockolással "javítanám" fel az ötletet, hanem azzal, hogy nem direktben írom a fájlt n processz által, hanem lenne egy processz, aki írja a fájlt, a többi pedig IPC-vel vagy TCP-n tolja át neki az adatokat.

Ha törölni csak utolsó x nap/hónap/év alapon kell, akkor a legegyszerűbb, ha a szervezés is ilyen (idő) alapon történik: így ugye komplett fájlokat lehet törölni.

Ez igaz. A hash-elt könyvtárszerkezet miatt meg végig kell járni valamennyit, hogy van-e új fájl benne. A snapshot arra viszont teljesen jó lehet, hogy konzisztens mentést csináljon, és ne legyen szükség hosszú állásidőre. A find helyett meg lehet írni saját könyvtárbejárós utility-t, ami egy darab stat() hívással megelégszik fájlonként az időadatok előhalászásához.
A hash-elt könyvtárak mellé ha a fájlok nevében ott lehetne a létrehozás időpontja, akkor még tovább gyorsítható - nem kell stat() se, elég a könyvtárat beolvasni, és abban a fájlok nevein végigloholni.

A hash-elt könyvtárak mellé ha a fájlok nevében ott lehetne a létrehozás időpontja,

benne van, sot a file-ok neve is benne van egy sql tablaban, igy nem kell se find, se stat. Bar nem a file nevet hasznalnam fel, hanem a serial-t.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Gondolatok csupán...

Nem tudom, mennyire fájdalmas lenne esetleg az adatokat egyenesen adatbázisba küldeni apró fájlok helyett... Habár úgy sejtem, hogy ez a valami összefüggéssel van az emailekkel (munkásságodból adódóan), így valószínű, hogy végigjártad már ezt az utat. Egy időlenyomat alatt óránkénti triage esetleg jó lehet még adott pillanatban. Minden attól függ, mennyire gyakran kell régi adatokhoz hozzányúlni. Némely esetben a fájlrendszerek a legjobb "adatbázis kezelők", szóval minden a benchmarkokon múlik.
--
Coding for fun. ;)

Nem tudom, mennyire fájdalmas lenne esetleg az adatokat egyenesen adatbázisba küldeni apró fájlok helyett...

mar korabban felmerult ez az otlet, de aztan lebeszeltek rola, miszerint nem hatekony erosen valtozo meretu adatokat sql-be tenni, es egy 2-3 szintu hash-elt konyvtarban teljesen jol elfer egy csomo file. Ezzel egyet is ertek, ezzel onmagaban nincs is gond. Tovabba - szerintem - sokkal egyszerubb file-okat menteni, mint TB-nyi meretu sql tablakat.

A dolognak amugy van koze az emailekhez, ill. es sok adat kiolvasasat is biztositani kell.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Nos, ha ilyen feladatba ütköznék, első körben ezt csinálnám:
MySQL InnoDB-vel, RAW partición, Mediumblob mezővel (16Mb körül), COMPACT row formattal, O_DIRECT flush methoddal, replikációval esetleg inkrementális mentéssel. Lehet, hogy lyukra futás, de tuti, hogy így kezdeném.
--
Coding for fun. ;)

Ha már adatbázis felé lép az ember, akkor ilyen key-value egyszerűségű feladatra egy Cassandra például teljesen jól használható. Lineárisan skálázható horizontálisan és vertikálisan is, a failover és a loadbalance a protokollba van építve, egy node 3 és 5 TB között érzi jól magát, egy sornyi adat 2GB lehet... és nagyon sok (fejlesztési) platformhoz van kliens API, amivel kezelhető.

Érdemes elfelejteni a MySQL-t ilyen adatmennyiségek és egyszerű adatkezelés esetén. Az SQL adatbáziskezelők leginkább RDBMS-ek, és mint ilyenek relációk közötti összefüggések kezelésére vannak kitalálva, nem relációmentes adatok puszta tárolására, mint a jelen esetben.

Évek óta elérhetőek különféle NoSQL bigdata rendszerek, tanuljuk már meg végre mindenféle informatikai rendszerek tervezésekor, hogy léteznek ilyenek és komoly terhelést el tudnak vinni a hátukon töredék áron és "hulladék" hardveren.

Én innen indultam: "3 -szintu hash-elt (xx/xx/xx) konyvtarban van tobb millio par kB ... MB meretu file". Ez számomra egy szimpla kulcs-érték adatbázis... a metaadatok lehetnek relációs adatbázisban, de lehetnek Cassandra columnfamily alapokon is, ha előre tudjuk, hogy mi alapján keresünk az adatok között.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Sztem nem jártad eléggé körbe a snapshotot, pl: https://github.com/mpalmer/lvmsync

A snapshot is eltárolja, hogy adott pillanattól mi változik a volume-on, ez pedig igen hasznos lehet neked. Mondjuk folyamatos írás mellett nem triviális, de több snapshot-ot használva csak néhány másodpercre kéne blokkolni az írást ahhoz, hogy konzisztens fájlrendszert kapj a mentésben. A DRBD ugyanez, csak ott blokkolni se kell, ellenben kötöttebb.

Mondjuk nekem a sparse file is tetszik (miért is gond a range lock?), meg az alkalmazás szintű replikáció, csak ezek több melóval járnak mint a backup fixelése.

( ssikiss | 2014. 09. 09., k – 10:44 )

Írod, hogy nagyon sok fájlt (rekordot), kicsit, de összességében nagy méretben, konkurens eléréssel, gyors visszakereshetőséggel, mentési lehetőséggel szeretnél kezelni.
Na most akkor ez egy adatbázis, amit adatbázis-kezelővel kellene kezelni (sql,nosql,felhő). :)
Ha mást nem is, de legalább a metaadatokat beletenném, ami alapján ráncigálod a fájlrendszeren tárolt fájlokat.

Ha nem nagy a konkurencia, akkor lehet csettegni valami key-value store-al is, de igazából egy "igazi" adatbázis-kezelőnek annyira sok előnye van, hogy gyakorlatilag értelmetlen minden másban gondolkodni.

igen, jol mondja Fisher. A file-ok fs-ben vannak, minden mas sql-ben. Egyelore azzal probalkozom, hogy a metaadatok alapjan egy tool kiszedi az utolso mentes ota kepzodott file-okat path-at, es azt atadja a tar-nak. Aztan lehet, kiprobalom az ffindex mintajara keszitett cuccot is.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

( uid_6201 v | 2014. 09. 09., k – 23:18 )

Annó réges régen volt ilyen jellegű programozó munkám. Akkor úgy vettem töredékére a fájlokat, hogy egy-egy fájlba több különböző adatot írtam (első mezőként kapott egy többlet mezőt, amely a neve volt) és a fájl alapnevével egyező index fájlt vezettem mellette.

Így adott esetben tizedére tudtam csökkenteni a fájlok számát, ami már többszintes könyvtárszerkezettel kezelhető volt.
Másszóval a processzor beáldozásával (vizsgál és eldob) tehermentesítettem a háttértár fejléptetését.