Pri pomahani dost tragicky neschopnym testerum, aby gigabajtama dumpovani
odpadu na konzoli terminalu nezasirali filesystem logujici jejich aktivity,
jsem narazil na nasledujici clanek analyzujici kompresi specificky log fajlu.
Neni to vedecka analyza, netestuje ruzne typy log fajlu (java, apache,
syslog...), ale i tak me to dost zaujalo - od ted na textova/log data uz
nepouzuju nic ostrejsiho nez "xz -3", bo to jaksi postrada smysl, pokud
cloveku nejde doslova o kazdej usetrenej bit:
http://stefanseidel.info/Log_file_compression
Je to teda z roku 2012 - nevim, jestli se od te doby vyvoj lzma2 nekam vyrazne
treba neposunul...
Predpokladam, ze bin-tree namisto hashovani je ucinnejsi pro jine typy dat,
ale na logy je bin-tree strasne pomalej a dokonce snad s horsi vyslednou
kompresi nez hash-tab... To bylo asi to zasadni a klicove pro me...
Ale asi bych trochu nesouhlasil s jeho metrikou v tom poslednim grafu - misto
mocneni/odmocnovani bych asi (kdyz-uz-tak) logaritmoval cas a kompresi
neumocnoval, ale nejakou "realistickou" metriku uz urcite nekdo nekde
vymyslel...
CePal
CePal
|
