Fórum Root.cz
Hlavní témata => Software => Téma založeno: mhi 15. 06. 2022, 13:50:57
-
Resim 2 problemy (na sobe nezavisle, ale svym zpusobem podobne):
- kazdy den stahuji z internetu nejaka data, jedna se o plaintext HTML stranku, kde je dlouhatanska tabulka, ktera se ale meni nejen na konci, ale vyjimecne i uprostred. Potreboval bych tyto z 90% shodne HTML soubory nejak "pribalit" postupne za sebe, takova idealni predstava je dolepeni do .tar.gz, ktery by si umel vzit stav pred ukoncenim komprese (zapis tar traileru) a umel tam dolepit ten novy soubor s tim, ze by se asi vyuzil stav kompresoru "z minula". Bylo by to vlastne ekvivalentni reseni vse prekomprimovat znovu, coz je taky asi pruchozi (treba po mesicich), ale nelibi se mi to, protoze dalsi bod
- podobne mam hromadu ruznych PDFek, ktera prichazi nova a nova, je v nich nekolik typu obsahu. Problem je, ze takove PDFko ma treba 300kB, je v nich nekolik typu textu/tabulek, ktere se porad dokola opakuji, obcas to prochazi "rucnim" zpracovanim (ruzne typy exportu/tisk do PDF, apod.). Text samotny nejde bohuzel rozumne vypreparovat, ne bez ztraty informace. V PDFku jsou casto zbytecne obrazky, jsou tam pribalene fonty, apod. No a tohle bych potreboval taky nejak inkrementalne stavet za sebe, aby se vyuzila informace z historickych souboru. Napadlo mne pouzit (udelat?) nastroj, ktery rozbali PDFkove objekty do plaintextu, aby to slo lip komprimovat externe, a hlavne treba ty opakujici se objekty by komprese vzala z minula.
Prosim jen o hotova minimalisticka reseni (tzn. ne instalace nejakeho molochu), naprogramovat si to nejak asi umim, nebo si umim koupit velky disk a rychlejsi pocitac.
-
Pokud jsem to dobře pochopil...
Jeden zip/rar soubor, otevřít a přidat nové pdf? Jak se to bude chovat? Očekával bych, že se využije slovník toho zipu. Nebo ne?
Druhá možnost: vytvořit si virtuální komprimovaný FS?
-
kdyz se v ruznych souborech objevuji stejne kusy textu/binarnich dat, tak bych pouzil huffmanovo kodovani.
velke bloky, ktere se casto opakuji se zakoduji pomoci mensiho poctu bajtu.
vzdy bych zpracoval nejake mnozstvi dat, vygeneroval mapovani pro huffmana a zakodoval podle toho data.
mapovani a zakodovane soubory bych ukladal postupne do jednoho souboru a la tar, a postupne bych si ukladal offsety a delky na mapovani, na data a na dalsi bloky, ktere se do souboru pridaji v budoucnu.
v budoucnu by bylo mozno znova vytvorit mapu pro huffmana a zase ji ulozit na aktualni konec souboru s novymi zakodovanymi daty a indexy/offsety by se updatovaly.
-
kdybys to jednoduse ukladal do gitu, tak by to mohlo fungovat ne?
mam dojem, ze taky uklada jen diffy a i binarni data tam jde vlozit.
-
git pokud vím ukládá soubory tak jak jsou (nejprve). A jednou za čas udělá packy, tedy znovu kompresi, asi vždy všeho dohromady, když už se odhodlá. Snad by to i mohlo amortizovaně fungovat slušně, jen s binárními soubory si jistý nejsem.
-
git pokud vím ukládá soubory tak jak jsou (nejprve). A jednou za čas udělá packy, tedy znovu kompresi, asi vždy všeho dohromady, když už se odhodlá. Snad by to i mohlo amortizovaně fungovat slušně, jen s binárními soubory si jistý nejsem.
kazdopadne by pak mohl autor porovnat svoje reseni s gitem co se tyka velikosti dat, rychlosti atd.
-
Koupil bych vetsi a pripadne rychlejsi disk.
Pokud chces vymyslet neco, tak z popisu problemu me prijde ze hodlas vyuzit korelaci mezi souborama, takze pak bych se zameril na tooly co umi udelat binarni diff. Ale delat to efektivne znamena (filesize^2) operaci, takze to bude trvat (nastesti mas male soubory). A muzes pak pouzit nejaky komprimovany FS, kde se ten bindiff ulozi a zkomprimuje jen sam o sobe.
Dalsi varianta je jet nejakou dobu uncompressed a az pak veci sbalit. Typicky to pouzivam na logy - jeden den = 24 logu = jeden gz na konci dne. Ty to muzes delat treba mesicne do archivu treba.
-
Mily alex6bbc, dekuji za odpoved, ale odpovidate skutecne to na co jsem se ptal? Jednak nechci nic programovat, a pak git (pominu-li ze neresi muj problem) bych za moloch uz povazoval. Myslel jsem nejakou utilitu typu tarxzappend file.tar.xz novysoubor.html
A pak huffmanovo kodovani obvykle neresi ty opakujici se bloky o delkach ktere se mi vyskytuji, to se dela trosku jinak, viz treba bzip2.
Jestli neco budu programovat, tak to bude tool, ktery bude hledat ty opakujici se bloky a v nejakem binarnim formatu si ulozi "knihovnu referenci" a pak data kombinovana s referencemi.
-
Mily alex6bbc, dekuji za odpoved, ale odpovidate skutecne to na co jsem se ptal? Jednak nechci nic programovat, a pak git (pominu-li ze neresi muj problem) bych za moloch uz povazoval. Myslel jsem nejakou utilitu typu tarxzappend file.tar.xz novysoubor.html
A pak huffmanovo kodovani obvykle neresi ty opakujici se bloky o delkach ktere se mi vyskytuji, to se dela trosku jinak, viz treba bzip2.
Jestli neco budu programovat, tak to bude tool, ktery bude hledat ty opakujici se bloky a v nejakem binarnim formatu si ulozi "knihovnu referenci" a pak data kombinovana s referencemi.
aha ok.
ja to napsal, jak bych si to udelal, kdybych to potreboval.
opakujici se bloky muzou byt jakkoli velke a pokud se opakuji tak si to primo rika o to je mapovat na kratsi kod.
ale to by si clovek musel sam naprgat podle svych potreb.
-
Ohledně toho HTML: To je vzorová úloha pro DB ne?
Krajně, při záchvatu lenosti, tak zvolit šikovně velikost bloku a použít souborový systém s deduplikací.
Ad FS s deduplikací:
Mám velmi špatné zkušenosti, papírově to vypadá hezky, ale ve skutečnosti ....úspora několik % na běžných datech.
Ale právě ty textové soubory mohou být skvělý způsob, jak deduplikací ušetřit hrozně moc místa.
Deduplikace, při vhodně zvoleném bloku, by mohla uspořit hrozně moc místa a přitom by to zůstalo transparentní.
Nicméně se jí musí někdy trochu pomoct, třeba hlavičku obsahující datum dát do extra souboru.
-
Jeste bych doplnil file system s deduplikaci + na nem zapnout on the fly kompresi. Pro textove/html soubory urcite.
Jinak ty PDF jsou imho uz komprimovane interne, takze dalsi komprese uz tolik neprinese.
-
Netusim jak na takovou ulohu vyuzit databazi.
Nevim jak by filesystem resil kdyz mi nekdo prida radek do tabulky nebo zmeni
<tr><td>aa<td>bb<td>cc
za
<tr><td>aa<td>qqq<td>cc
(dojde k posunu o byte a zmene uprostred, je to jen priklad- zde treba myslim zmenu cele vety v tabulce)
Jinak ty HTML maji treba 2MB.
****
Bindiff by sel pouzit jen kdyby umel srovnavat proti vice souborum. Napadlo mne, ze bych mohl vzit podle data treba poslednich 100 souboru a hledat proti nim + pokud uz jsou "komprimovane" s referencemi, tak i v tech referencovanych souborech. Ono by to pak samo naslo co je cemu podobne, mozna by podle toho slo ty soubory i typove roztridit :). Vlastne by to asi statisticky mohlo poznat "tohle PDF delal stejny clovek jako techto 50 dalsich".
****
PDF je obvykle komprimovane uvnitr, pridani jednoho znaku do textu zmeni cely deflate bitstream, takze pro zpracovani je potreba je dekomprimovat.
-
Netusim jak na takovou ulohu vyuzit databazi.
Já ano, ale ty chceš něco fakt simpl, jednoduché.
Tedy - proto - použij FS s deduplikací, což je v podstatě taky jednoduchá databáze :-)
Jen se postarej, abys hlavičky (často se mění, protože tam je datum a pod), měl jinde.
Rozsekneš soubor na hlavičku a obsah. Navíc to celé můžeš krásně komprimovat na úrovni FS, jak tu zaznělo = bude to malinké, možná se to vejde na SSD.
Výhoda souborové deduplikace je i v tom, že když se ti změní formát souboru, výstupního souboru, tak v nejhorším zapíšeše znova celé 2MB a začínáš deduplikovat znovu. U DB by ses musel zajímat o změnu obsahu.
Jak zpracovat PDFka netuším, ale nejspíš extrahovat, jak jsi správně uvedl.
Velikost sektoru si asi budeš muset určit, zeřejmě to bude umět deduplikaci jen na úrovni sektoru, nikoliv na úrovni výřezu. Tj bla123456789 a alb123456789 budou komplet jiná data a zůstanou, tak jak jsou. Očekávám, že ti sektorová deduplikace bude fungovat jen pokud budou oba sektory 123456789. Ale mohu se plést. Na Widlích mi to chodilo dobře jen při shodě sektorů. Jak se to posunulo (třeba se na začátek souboru umístila 1), už to mělo s deduplikací problémy. Kdo ví, jak chytrá je deduplikace na Linuxu. Ať poradí.
-
Samotný gzip to umí celkem triviálně, jen si nejsem jist s efektivitou při malém množství přidaných dat: https://unix.stackexchange.com/questions/264980/how-to-append-a-line-in-a-zipped-file-without-unzipping
Je otázka, jestli s tím bude umět pracovat i tar. Mohl by.
-
Netusim jak na takovou ulohu vyuzit databazi.
K čemu by ti byly HTML dekorace? Ty si můžeš uložit do nějaké XSLT šablony třebas.
Takže jedna z možností je přežvýkat soubor a jeho řádky regexem, protože ukládání formátování je nadbytečná informace. Jednotlivé věty pak ukládáš do DB, takže ti nevadí, že někdo věty zpřeházel, navíc máš kompletní historii.
Výhody:
Může to být bezkonkurečně nejmenší, máš k dispozici všechny verze, můžeš provádět data mining atd.
Nevýhody:
Musíš se zajímat o formát, jak ti přestane fungovat Regex, musíš upravit import.
S vysokou pravděpodobností může vzniknout situace, kdy bys musel strukturu tabulek upravit.
Tak je to o tom, jak důležitá data to jsou, jestli je můžeš zpracovat a kolik na to máš času.
Málo času / nechuť / nedůležitost / neexistující přidaná hodnota / ....nenene... = použij FS s deduplikací
Nicméně - odebrat HTML dekorace může být decela chytré tak jako tak - třeba i pro to FS s deduplikací.
Mnoho z nich můžeš beztrestně odebrat, aniž by to snížilo čitelnost textu = redukce dat.
-
Hodně, dokonce i starých komprimačních programů umí deduplikaci.
Tuším dokonce i stařičké ARJ.
Ale proč to dělat, když stejnou práci zvládne i FS? ::)
Navíc - abys mohl deduplikovat data - potřebuješ vytvořit archiv obsahující co nejvíc souborů.
Tj. měl bys XY archivů nebo bys pořád musel vybavolovat a balit data třeba za rok... ::)
Proč, když to zvládne FS?
-
Deduplikace na FS nebude fungovat moc dobře. Protože když mu někdo do souboru něco vloží, tak se to celý posune a bloky už identický nebudou.
-
Ukladal bych jen patche z htmldiff. Pripadne to verzoval gitem. Pokud se jedna o stale stejnou stranku s malym mnozstvym zmen.
-
Je fakt, že u toho primitivního řetězení gzipu by reduplikace fungovala jen maximálně v rámci přidaných dat. Prostě to nebude příliš efektivní s malými bloky přidaných dat.
-
Deduplikace na FS nebude fungovat moc dobře. Protože když mu někdo do souboru něco vloží, tak se to celý posune a bloky už identický nebudou.
Tak třeba týden, kdy v pondělí se změní zdroj:
2MB dat + změna 4kb + změna 4kb + změna 4kb + změna 4kb + změna 4kb + změna 4kb
Tj. úspora: 12 MB
Pak se ti posune offset:
2MB dat + změna 4kb + změna 4kb + změna 4kb + změna 4kb + změna 4kb + změna 4kb
A začínáš zase znova....takže buď v klidu, deduplikace bude fungovat docela slušně.
Pokud se to uprostřed mění zřídka, bude úspora ohromná.
Jen je potřeba uříznout hlavičku a zajistit, aby to začínalo vždy stejně - (zajistíš uříznutím hlavičky - hlavičku řežeš proto, aby ti obsah začínal vždy stejně).
A navíc - to bude na úrovni FS transparentní, žádné balení a rozbalení, žádné skripty, můžeš to mít v jednom adresáři za dvacet let, nemusíš nic balit.
Příklad: 1x týdně se to celé změní:
Máš 52 týdnů * 2 MB = 104 MB ročně na tento soubor (adresář), který by jinak měl asi 750 MB.
Navíc, pokud se ti změní věta bez posunu - tomu by se dalo pomoct odebráním HTML dekorací a zarovnáním, tak z toho budeš mít třeba 10-20 MB za rok. Tak to klidně můžeš držet na SSD.
Problém mohou být ty PDF, ty bude těžší zpracovat - leda je převést na HTML, možná něčím jako poppler-utils (neznám) Odebrat z toho dekorace a zase by to mohlo jít deduplikovat.
-
Ukladal bych jen patche z htmldiff. Pripadne to verzoval gitem. Pokud se jedna o stale stejnou stranku s malym mnozstvym zmen.
Výhoda deduplikace na úrovni FS je transparentnost, kdy máš přístup ke všem souborům a verzuje se to samo.
Navíc pouhým překopírováním na jiný FS z toho vyrobíš původní obsah.
Taky se to dá mimořádně rychle vyzkoušet, jen správně oddělit hlavičku a body, vzniknout soubory .heat a .content, které jsi schopný skriptem klidně zase spojit. No a pak koukat, jak deduplikace maká za tebe.
Výhoda htmldiffu je to, že tě netrápí zarovnání na sektory, ale cirkus okolo toho bude předpokládám(nevím) větší.
Další nevýhoda, proti jaké verzi to chceš kontrolovat? Vždy proti té poslední? Pak se ti ten vláček snadno rozbije...
-
Appendovani gzipu bohuzel nic neresi, neprebira se stav kompresoru z minula.
Deduplikace na urovni bloku fungovat dle meho nazoru nebude, jak pise Logik. Predstavte si, ze dokument vznika tak, ze nekdo hodi do Wordu nejakou tabulku a texty, doplni tam nekam nahodne volne poznamky a pak z toho udela PDF. Nebo v tom HTML neco upravi. Vznikaji ruzne nahodne posuny o par bajtu, apod.
U tech ruznych diffu je problem "proti cemu diffovat". Ono to bohuzel neni tak,ze by ty "stejne" dokumenty sly po sobe. Ja si stahnu 50 PDFek a do doby nez je otevru nejsem schopen rict, kdo je udelal-jaky "format" maji, a v jake nalade byl zrovna ten clovek.
-
Vysvělil jsem ti, co s tím máš dělat.
Zkouška jednoduchá ;)
Myslet = houby vědět.
-
Výhoda deduplikace na úrovni FS je transparentnost, kdy máš přístup ke všem souborům a verzuje se to samo.
Navíc pouhým překopírováním na jiný FS z toho vyrobíš původní obsah.
Taky se to dá mimořádně rychle vyzkoušet, jen správně oddělit hlavičku a body, vzniknout soubory .heat a .content, které jsi schopný skriptem klidně zase spojit. No a pak koukat, jak deduplikace maká za tebe.
Tak to bych transparentnim vubec nenazyval. Zadny head a body neni mozny, kdyz se ti pridavaji radky / meni texty, na nekolika mistech dokumentu.
FS-dedup je nejhorsi napad pro problem tazatele. Ty soubory nejsou blokove orientovane! (napr. nejsou to obrazy disku, kde by takova vec mohla fungovat, pokud se do obrazu neco sem tam pridava a meni).
-
U tech ruznych diffu je problem "proti cemu diffovat". Ono to bohuzel neni tak,ze by ty "stejne" dokumenty sly po sobe. Ja si stahnu 50 PDFek a do doby nez je otevru nejsem schopen rict, kdo je udelal-jaky "format" maji, a v jake nalade byl zrovna ten clovek.
Pokud chces sledovat "vlakna" ale zpravy chodi nahodne, tak ti nezbyva nic jineho, nez udelat pdf2text a hledat nejvetsi zhodu s nekterym z vlaken ktere sledujes (holt musis novy dokument porovnat bud se vsema predchozima souborama, nebo poslednim z kazdeho vlakna). Kdyz budes delat vsechna, tak ti nalezne i vhodnejsi parent-doc k bindiffu, pokud by match nebyl na poslednim souboru z daneho vlakna (teoreticky nejpodobnejsim - nejmene zmen).. a budes to mit stromovity.
Ale nechapu v jakych radech se tady pohybujeme, ze tohle zrovna je potreba resit - proc nejde vzit vetsi/rychlejsi disk.
-
Zadny head a body neni mozny, kdyz se ti pridavaji radky / meni texty, na nekolika mistech dokumentu.
Prosím, nereaguj na mě!
Jak ti to říkal ZAJDAN?
kazdy den stahuji z internetu nejaka data, jedna se o plaintext HTML stranku, kde je dlouhatanska tabulka, ktera se ale meni nejen na konci, ale vyjimecne i uprostred.
Pokud se změní uprostřed a dojde k posunu, pak se jen uloží nová verze.
Vyjímečně asi není každý den že? Tj. úspora zde bude zřejmě ohromná, větší než kompresí.
Pokud by se to uprostřed měnilo 1x za 30 dnů, budeš mít poměr cca 1 ku 29, tj. 1x uložíš 2MB a dalších 29 * 2 MB = cca 58 MB ušetříš.
-
ZFS deduplication works on blocks (recordlength) it does not know/care about files. Each block is checksummed using sha256 (by default changeable). If the checksum matches an other block it will just reference the same record and no new data will be written. One problem of deduplication with ZFS is that checksums are kept in memory so large pools will require a lot of memory. So you should only apply reduplication when using large record length
Deduplikace na FS nebude fungovat moc dobře. Protože když mu někdo do souboru něco vloží, tak se to celý posune a bloky už identický nebudou.
-
kazdy den stahuji z internetu nejaka data, jedna se o plaintext HTML stranku, kde je dlouhatanska tabulka, ktera se ale meni nejen na konci, ale vyjimecne i uprostred.
Když se ti to změní uprostřed ale vyjimecne i uprostred
tak se ti jen znova uloží celá verze ne?
BTW, u nás je výjimečně = občas, zřídka, ne každých pár dnů. ::)
Nešňupejte tolik ten kokeš ::)
-
Vysvělil jsem ti, co s tím máš dělat.
Zkouška jednoduchá ;)
Myslet = houby vědět.
No vidite, a ja jsem tak hloupy, ze jsem vasi radu neprijal a dale se ji nebudu zabyvat. Jsme zvlastni lide, co? Jako kdybychom kazdy zili v nejake paralelni realite :).
Ale nechapu v jakych radech se tady pohybujeme, ze tohle zrovna je potreba resit - proc nejde vzit vetsi/rychlejsi disk.
Hrubym odhadem bych rekl, ze ta "knihovni komprese" muze byt treba 1:500, takze mi to prijde zajimave se tim chvili zabyvat. PDFka prevadet do textu nelze, ztrati se informace, nefunguje to dobre. Spousta programu treba neumi (a asi nemuze umet) kdyz je embeddnuty zmrseny font ze znaky neodpovidaji ASCII/UTF-8 a neni tam mapa. U tech PDFek je problem, ze PostScript uvnitr pocita fixne se souradnicemi, mozna by ale sel napsat program, ktery to nejak relativizuje, pak by mohla fungovat nejak "knihovni" komprese alespon na prunicich stranek.
-
Zadny head a body neni mozny, kdyz se ti pridavaji radky / meni texty, na nekolika mistech dokumentu.
Prosím, nereaguj na mě!
Jak ti to říkal ZAJDAN?
Zadost se zamita. Nevim o cem mluvis, ale jsi vedle jak ta jedle s tou deduplikaci. Delas jenom tobe vyhovujici predpoklady, ktere jsou na mile vzdalene situaci tazatele co se tyce podoby dat.
-
No vidite, a ja jsem tak hloupy, ze jsem vasi radu neprijal a dale se ji nebudu zabyvat
Máš recht, stejně bys to nedokázal ořezat.
-
Hrubym odhadem bych rekl, ze ta "knihovni komprese" muze byt treba 1:500, takze mi to prijde zajimave se tim chvili zabyvat. PDFka prevadet do textu nelze, ztrati se informace, nefunguje to dobre.
Prevod do textu je jenom kvuli hledani podobnosti s vlaknem do ktereho chces vclenit to PDF, dale to uz je bindiff/patch.
Pokud ale ty PDF budou ruzne vyrobena, tak nejsou stejna.. ze se ti to zobrazuje stejne, tak to neznamena ze maji stejny zdrojak ktery by sel zkomprimovat s diff. Tohle je slepa cesta.
-
Aha, takhle. Nez to resit takhle, to mi prijde jednodussi uz hledat v poslednich n souborech daneho formatu (HTML,PDF) a tim si najit nejaky hodne podobny.
Ruzne vyrobena PDF jsou "stejna v ramci serie", problem je ten PostScript uvnitr, ale mozna by mohl jit nejak sjednotit.
Bohuzel je to hodne za hranou toho kolik casu tomu chci venovat, ale je to zajimave tema.