bzip2 - még ne temessük

 ( hg2ecz | 2019. szeptember 3., kedd - 20:16 )

A gzip után valamikor az 1990-es évek vége felé jött a bzip2, amely komoly előrelépést a forráskódok és egyéb szöveges állományok tömörítésében.
Aztán jött egy évtizede az lzma és az xz. Ez utóbbi fokozatosan kiszorította a bzip2-t, mert a nagy fájlokra tényleg jobban tömörít.

Éppen írok egy gyorsabb mintavételezésű mérésadatgyűjtőt BeagleBone Black-re. A mért adatokat a RAM-ban gyűjtöm, majd percenként szöveges formában, tömörítve tolom ki az SD kártyára (célok: olvashatóság, helytakarékosság, ritkább SD írás). Ennek apropóján "megversenyeztettem" a tömörítőket.

1670032 meres-1567533300.log
227702  meres-1567533300.log.bz2
343496  meres-1567533300.log.gz
231328  meres-1567533300.log.xz

1665659 meres-1567533360.log
228739  meres-1567533360.log.bz2
345092  meres-1567533360.log.gz
232780  meres-1567533360.log.xz

A perces bontású, ASCII számokat tartalmazó mérésnapló tömörítésére meglepően jól vizsgázott a bzip2.
Ezért a már majdnem elfeledett bzip2 lett belegyógyítva az adatgyűjtő szoftverembe.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A zstd-t kiprobalhatnad meg

Köszi a tippet. Nem futott be sajnos.
391444 meres-1567533300.log.zst

Speciális némileg a helyzet, mert 1,5 MB körüli apróbb fájlokról beszélünk, amik mindössze [0-9.:\t\n] karakterkészlettel rendelkeznek.

Kivancsi lennek hogy a compress (.Z) mit mutat.
____________________
echo crash > /dev/kmem

gzip-nél rosszabb,
375797 meres-1567533300.log.Z

Javaslom Lacos hup társunk által kifejlesztett lbzip2-t használni, mely párhuzamos.

Tempóban nincs problémám. Viszont egymagos jószág a BeagleBone Black.
(a 2 db 200 MHz-es direkt programozott PRU-t nem számolva).

Akkor jó :) illetve ram szempontjából is jobb akkor valszeg a sima.

Hogy megy a Rust? :)

A jelenlegi LOG előkiértékelőm Rust-ban van írva, szintén a BBB-n fut a távoli telephelyen. Eredetileg Python-ban írtam, de a Pypy3 is lassúnak bizonyult, Rust-ban 5-szörösére gyorsult.
Tömörítő lib-ek szerencsére igen egyszerűen beépíthetőek a kódba: https://docs.rs/bzip2/0.3.3/bzip2/

Nekem két bajom van vele. Felületesen nézve nincs rajta A/D konverter, illetve ha oprendszer megy rajta, akkor gyanítom, hogy az minden, csak nem real time. Saját tervezés lesz ebből... (4 csatornán kellene 1 MS/s, legalább 10 bit, de inkább több, aztán valós időben kicsit dolgozni az adaton.)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az én projektem realtime speckóját teljesíti szerencsére és 7 db A/D bemenete van a BBB-nek. Ezért ez lett belerakva.

A tied esetén viszont barátod lehet egy külső A/D IC és a BBB PRU-ja. Kb. 350 MB RAM-ba írhatsz akár 40-50 Msps jittermentes tempóval a PRU segítségével. A Linux pedig csak kiveszi, menti ill. kiértékeli. Egy hasonló: https://hackaday.com/2016/07/31/blindingly-fast-adc-for-your-beaglebone/

Feltételezem hogy ez a default compression levellel ment mindegyik tömörítő esetén, vagyis bz2 -9, gz -6, xz -6. Érdemes lenne megnézni ugyanazon a szinten, vagy ugyanannyi idő/memória ráfordítás esetén, mert ez így szinte almát körtével összehasonlítás. Valami ilyesmire gondolok.

+1
Ezen kívül még az adattípus dimenziót is lehet tesztelni.

Bár a kitűzött cél alapján jó ez így, mégis vizsgálni lehetne más szempontok szerint is.
Pakolt bcd vagy bináris formátummal 2-3x-os tömörítést lehet elérni. A kívánt formátum elő- vagy visszaállításához elég egy pár soros filter. Igaz, a csökkentett redundancia miatt így romlik a tömörítési faktor, de az eredő jobb is lehet.

Az sd kártya kímélésére meg hatékonyabb lehet raw formátumban írni és blokkolni. Az biztosan kevésbé terheli, mint bármely fs.

Köszi ezt a tippet is. Viszont tegnap ezeket is elvégeztem, a fenti adathalmazra [0-9.:\t\n] nem tudták kiütni a gzip2-t 1,5MB körüli nyers fájlméretek esetén.
Az lzma és xz lehetnének esélyesek, ezeket az adatgyűjtésnél több száz megás napi bontású LOG fájlok tömörítésére aktívan használom, de azok csak a jelenleginél sokkal nagyobb fájlméret esetén tömörítenek nagyon erőteljesen. Az hogy miért percenként rakom el jelen esetben, annak is oka van.

Egy mintafájlt fel tudnál rakni valahova? (ha nem titkos)
Csak érdekességképpen kipróbálnék rajta néhány algoritmust..

Én a mai napig a bz2-t és a 7z-t használom.

De majd megnézem az itt javasolt eszközöket is, legalább 3 újat említettetek.