Van sok kis fájlom, amikben van némi rendundancia, jól tömöríthetőek elméletben. Nevezzük őket log bejegyzéseknek.
Önmagukban túl rövidek a bejegyzések ahhoz, hogy egy LZ-szerű tömörítő "bemelegedjen". Viszont annyira hasonlóak a bejegyzések, hogy hosszútávon kialakulhatna egy ideális prefix-szet, vagy tömörítőállapot, amivel jól lehetne tömöríteni. Például csak decimális számjegyek vannak benne space-ekkel elválasztva.
Nem szeretném viszont úgy tömöríteni őket, hogy egyetlen stream-be szedem össze őket, mert jó volna, ha random elérhető maradna az adat.
Az a kérdésem, hogy van-e erre valami standard megoldás: például betanítok egy tömörítőt, hogy jól kezelje a számokat, és ebből a tömörítőállapotból kiindulva tömörítem a fájlokat? Van erre működő példa, vagy lib, ami tudja ezt és egyszerű használni? Java-hoz kellene.
(Plusz komplexitás, hogy minden bejegyzésben van 2-3 szakasz, amiknek eltérő struktúrája van, eltérő módon tömörítendőek, de ezzel külön meg tudok küzdeni. Például van benne függvény-szerű adatsor, amit differenciális kódolással lehet jól összenyomni, egy másikban random számok vannak, egy harmadikban pedig majdnem mindig ugyanaz.)
Hozzászólások
"Önmagukban túl rövidek a bejegyzések ahhoz, hogy egy LZ-szerű tömörítő "bemelegedjen".": több évtizedes zip/rar/huffman technikák sokkal okosabbak mindannyiunknál bemelegítés szempontból. Vannak újítások, mint anno a 7zip, amely jobban megfigyeli hogy kell bemelegedni. Akár 10-15%-ot is tud hozni. De ha eleve jól tömöríthető (20-30%-RA), akkor felesleges ezt optimalizálni.
"mert jó volna, ha random elérhető maradna az adat.": szerintem csak szekvenciális tömörítők vannak, olyan ami struktúrát is tart fenn a random access-re nem a tar-gz szemléletben keresendő. Sokkal inkább egy tömörített fájlrendszeren lévő adatbázis lesz a barátod. Abban talán a JSON "jellegű" struktúra miatt tudsz keresni elemekre is, ha ezek tényleg LOG-ok vagy ahhoz hasonlók.
Viszont kérdés:
- mennyi helyet spórolsz egy ZIP-pel és mennyi lenne az ideális?
- (igazi hülyeség ON) miért nem másolod az elérési struktúrát (mappák+almappák) egy zipben, amelyben zip-ek vannak, ahol egy elem egy további ZIP. Ahogy mész a struktúrában lefelé...
> szerintem csak szekvenciális tömörítők vannak, olyan ami struktúrát is tart fenn a random access-re nem a tar-gz szemléletben keresendő.
A random access-t úgy értem, hogy logbejegyzésenként ki lehessen olvasni viszonylag gyorsan. A bejegyzésen belül már nem kell seek-elni, hanem egyben kell kivenni ha szükség van rá.
> több évtizedes zip/rar/huffman technikák sokkal okosabbak mindannyiunknál bemelegítés szempontból.
Okos, de csak akkor tud bemelegedni, ha van hozzá elég adat. Párszáz bájton nem tud rendesen bemelegedni. Például a zip is fájlonként tömörít (AFAIK), tehát ha egy bejegyzés 1 fájl, az nem túl hatékony - nem melegszik be a tömörítő.
> Sokkal inkább egy tömörített fájlrendszeren lévő adatbázis lesz a barátod. Abban talán a JSON "jellegű" struktúra miatt tudsz keresni elemekre is, ha ezek tényleg LOG-ok vagy ahhoz hasonlók.
Az adatoknak van néhány keresőkulcsa, amik adatbázisban kereshetőek lesznek. Plusz egy csomó hozzácsapott bináris adat, ami nem kereshető, csak elővehető mondjuk sorszám szerint. Ezt kellene tömörítve tárolni.
> - mennyi helyet spórolsz egy ZIP-pel és mennyi lenne az ideális?
1152 byte -> 343 byte gzippelve. Nem rossz, de lehetne jobb is. Sajnos jelenleg nincsen még meg az adattömegem, amit tömöríteni kellene. Pár példám van, ami alapján azt gondolom, hogy ha lesz sok, akkor együtt sokkal jobban fognak tömörödni, mint egyesével.
> - (igazi hülyeség ON) miért nem másolod az elérési struktúrát (mappák+almappák) egy zipben, amelyben zip-ek vannak, ahol egy elem egy további ZIP. Ahogy mész a struktúrában lefelé...
A zip formátum fájlonként tömörít, nincs túl sok haszna
Van egy másik példám is:
gzip: 55970->24573
bzip2: 55970->22672
Írtam hozzá egy egyedi tömörítőt, ami annyit tud, hogy az ismétlődő prefixeket "fejből" tudja, illetve a függvényadatokat differenciálisan tárolja. Ezzel:
55970->14008
Látszik belőle, hogy van itt értelme előismerettel rendelkező tömörítést csinálni.
Én annó kb. 10 éve hasonló problémába ütköztem. Fogtam egy lzma2 tömörítéssel rendelkező readonly fájlrendszert, talán squashfs-t de nem biztos hogy ezt és összeraktam egy ilyen image-ba. Ezt felmountoltam és megvolt a relative gyorsan kereshető txt adathalmaz.
Igen, ez jó ötlet lehet. Van hátránya is: Összesen óriási adatmennyiségről lesz szó, sok archive lesz, és az állandó felmountolást/lemountolást elég nehézkes lesz megoldani. Meg ezzel Linuxhoz kötöm a programot sajnos.
Ez nagyjából egyenértékű azzal, hogy a bejegyzéseket optimális számban egymás mögé másolom (beindexelem, hogy melyik hol kezdődik), és egyben tömörítem. Akkora darabokban, hogy már bemelegedjen a tömörítő, de még ne legyen túl lassú a random elérés. Csak így meg kell valósítani azt a logikát, ami a squashfs-ben eleve benne van.
Itt viszont előny, hogy működik a fájlrendszer cache. Egyébként igen, vélhetőleg több archivod lesz. Én is kb. 40 GB-onként dobtam bele ilyen fájlrendszerbe és a megfelelő köteteket csatoltam fel.
Esetleg N fájlonként tar.xz és az elemzőszoftverben futásidejű feldolgozása? De bármelyiket választod, valahol macerásabb, mint a readonly squashfs loopback eszközön keresztüli felcsatolása.
A zstd-hez tudsz konnyen dictionaryt kesziteni. Probald meg azzal, hatha.
Hm, ez jónak tűnik a feladatra. Érdekes, hogy hasonló nehézségűnek tűnik blokkokba gyűjteni az adatot, mint ezt megfelelően felparaméterezni, és használni. Megfontolandó.
Kötegeled a fájlokat pl. tizesével egy saját formátumban (akár protobuf vagy bencode) és úgy ereszted rá a sima pkzip-et.
Igen, erre felé gondolkodok főképpen. Ami bonyolítja, hogy adatbázisba lenne jó tenni a blobokat. Mondjuk ugyanezt az adatszerkezetet ott is meg lehet csinálni:
* Beteszem nyersen
* amikor összejön mondjuk 100 nyers blokk (ki kell mérni az ideális számot) akkor átteszem tömörítettbe és a nyerseket törlöm
* A lekérdezést megcsinálom, hogy tudja kezelni a nyers és a tömörített blokkot is. Ha egyszerre többet kérnek egy blokkból, akkor természetesen csak egyszer csomagolom ki.
Ha adatbázis, akkor nem lenne jobb adatbázis vagy alatta fájlrendszer szinten tömöríteni, aztán hasznosabb dolgokkal tölteni a többi idődet? :) Meg van oldva a transzparens tömörítés és a random access is, és elvileg még hatékony is mert nagyobb blokkokat fog egyben tömöríteni.
Azzal a részével mindenképpen foglalkoznom kell, hogy a bejegyzéseket szétszedjem a különböző adattípusok mentén (legalább függvény adat és egyéb).
A függvény adatokra csakis a delta-kódolás működik, mert ezek jó kis zajos mért adatok. Erre pedig a generikus tömörítők nem jók. Tehát valamit mindenképpen foglalkoznom az üggyel, ezt nem bízhatom az adatbázisra. Ráadásul súlyra ebből lesz a legtöbb, a többinek a tömörítése csak hab a tortán.
Az adatbázisban lesznek a live lekérdezhető adatok, viszont a historikus adatok backupját lehet, hogy nyers fájlokba tenném (ha ez ésszerűbb), ezért gondolkodom adatbázis és fájl-szerű tárolásban egyszerre.
Olyan file rendszeren tárolni amely tud tömörítést?
Alapvetően arra lövök, hogy egy Linux/Windows platformon hordozható, bárhová könnyen telepíthető program készüljön, a rendszergazda számára mennél inkább kulcsrakész legyen. Ezért ez nem lenne ideális.
De elképzelhető, hogy mégis ez lesz.
Win-en tudsz mappára vagy adott fájlokra tömörítést kérni, tudja az NTFS - Linuxon van csak így extra igény, de Btrfs-en kívül már mást nem használnék, annyira kényelmes amúgyis a snapshot-ozás, raid meg tömörítés.