» »

Kompresija velikih tekstovnih datotek

Kompresija velikih tekstovnih datotek

jukoz ::

Zdravo,

rabim idejo, kako skompresirati velike text datoteke - gre se za loge meritev - od par 100k do par milijonov vrstic.

Trenutno so fajli TSV/CSV, veliki med 1GB in 2GB, generiramo jih mi.
Format ostane fiksen in se ne spreminja.

Podatek je torej zapisan v eni vrstici, lahko pa vsebuje tudi umlaute, cirilico, arabščino, kitajščino - odvisno kako so uporabniki poimenovali parametre.

Ideja je, da si lahko uporabnik zloada loge za svoje naprave in jih obdeluje po svoje - eni jih tudi loadajo v Excel oz kaj podobnega.

Trenutno se berejo podatki iz senzorjev in dodajajo v eno datoteko. To datoteko lahko uporabnik zloada k sebi.
Podatki se filajo večkrat na sekundo, nekaj sekund, minuto, uro, dan, odvisno od nastavitev. En sam file nam povsem odgovarja in se to ne bo spreminjalo.

Tudi za naprej bi jim pošiljali eno enotno datoteko, ker so zadaj potem drugi procesi obdelave pri uporabnikih. Lahko pa je kompresirana, ker bi bil to samo en dodaten korak.

Vse ideje dobrodošle.

secops ::

Tako kot dela to linux. Ko je datoteka enkrat velika X, se začne pisati v novo datoteko. Polne datoteka pa se lahko nato tudi stisnejo, recimo v.tar.gz

WizzardOfOZ ::

Na katerem sistemu pa delate? Win ali Linux?
Jaz velike loge pakiram s 7z in dam razpon preko vseh jeder -1 (torej če na 8 jedrni mašini pakiram dam 7 jeder za pakiranje, da to hitro opravi).
1 ali 2GB tudi ni neka huda velikost. Pri sevenzipu si omejen na velikost particije in to je vse.
Milčinski je napisal butalce kot prispodobo in ne kot priročnik!!!
Svuda u svijetu ima budala ali je izgleda kod nas centrala!!!

jukoz ::

Hvala za hiter odziv.

Sistem je in bo nek unix.

Ostati mora ena datoteka. Po možnosti čim manjša - rad bi jih zmanjšal iz 1GB na kaj manj. Da jo lahko uporabnik v miru prenese tudi večkrat, če je prvo poškodoval. Velikost bi zmanjšal tudi za to, ker imajo nekatere mašine bolj kilav dostop do neta in je prenos nezanesljiv.

Kot rečeno - to so datoteke polne teksta in nič drugega. Ali bi s kompresijo kaj dosegel - bi bile uporabno manjše? Npr 10% manjša ne vem če je smiselno, mogoče za nekatere.

Sicer bom pa malo testiral in javim.

pegasus ::

Če se tekst pretežno ponavlja, kar je tipično za log datoteke, boš dosegel dobre kompresije. Po učinkovitosti (in porabi cpu) si sledijo nekako tako: gzip, bzip2, xz. Za vse obstajajo multithreaded varjante pigz, pbzip2, pxz. Zadnje čase mi je zelo všeč xz, preberi man page, na mašini z veliko rama lahko dosežeš fenomenalno boljše kompresije, če imaš čas.

b3D_950 ::

V mojem primeru; približno 1GB velik log file, gre v približno 2MB zip file.

7z a -mx3 -t7z
Zdaj ko je mir, jemo samo krompir.

Ahim ::

jukoz je izjavil:

Kot rečeno - to so datoteke polne teksta in nič drugega. Ali bi s kompresijo kaj dosegel - bi bile uporabno manjše? Npr 10% manjša ne vem če je smiselno, mogoče za nekatere.

Sicer bom pa malo testiral in javim.

Seveda da bo kompresija pomagala, ampak mora imeti stranka dovolj znanja za zadevo odpakirat. Najmanj ucinkovite metode bodo hkrati najbolj "user-friendly" za neuke uporabnike (= prastari ZIP, ki ga Windows podpirajo brez dodatnih programov). Najbolj učinkovit ali pa vsaj najbolj fleksibilen (potestiraj: zstd, pick your poison v mnozici stopenj kompresije, dekompresija je pa približno enako hitra ne glede na stopnjo kompresije) bo pa omogočil hitrejše penose in manj zasedenga prostora na vaši strani ...

garamond ::

Kompresija se lahko naredi na relaciji server-spletni brskalnik, v najboljšem primeru je potrebna samo pravilna konfiguracija. Uporabnik take kompresije ne opazi (razen seveda "večje hitrosti" prenosa).
Recimo html za tole Slo-Tech temo je porabil 9,7 kB prek omrežja za dejansko velikost 29,3 kB.
https://developer.mozilla.org/en-US/doc...
A parody of extremism is impossible to differentiate from sincere extremism.

Ahim ::

garamond je izjavil:

Kompresija se lahko naredi na relaciji server-spletni brskalnik, v najboljšem primeru je potrebna samo pravilna konfiguracija. Uporabnik take kompresije ne opazi (razen seveda "večje hitrosti" prenosa).
Recimo html za tole Slo-Tech temo je porabil 9,7 kB prek omrežja za dejansko velikost 29,3 kB.
https://developer.mozilla.org/en-US/doc...

Normalni web strezniki podpirajo serviranje predkompresirane vsebine, sicer je lahko proces precej racunsko potraten, ce se ista vsebina kompresira vsakic sproti.

BigWhale ::

jukoz je izjavil:


Trenutno se berejo podatki iz senzorjev in dodajajo v eno datoteko. To datoteko lahko uporabnik zloada k sebi.
Podatki se filajo večkrat na sekundo, nekaj sekund, minuto, uro, dan, odvisno od nastavitev. En sam file nam povsem odgovarja in se to ne bo spreminjalo.

Tudi za naprej bi jim pošiljali eno enotno datoteko, ker so zadaj potem drugi procesi obdelave pri uporabnikih. Lahko pa je kompresirana, ker bi bil to samo en dodaten korak.

Vse ideje dobrodošle.


Ne izumljaj tople vode in si poglej logrotate.

Invictus ::

Zbirati podatke v en file, ki ga lahko potem uporabniki sami jemljejo, je tako leto 1990?

A ne morete narediti ene usrane baze in gor en reporting software? Recimo OpenSearch (https://opensearch.org/)

Poleg tega delaš vsaj 2 stvari pri tekstovnih datotekah, ki se filajo:

1. Dnevni rotation
2. Rotation na podlagi velikosti

Itak pa vse, razen trenutno aktivno zipneš in arhiviraš.

Kaj tukaj ni jasno?
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

c3p0 ::

Old school podjetje, printajo verjetno na dotmatrix printerje in tisti perforiran zeleno-beli papir.

Zgodovina sprememb…

  • spremenil: c3p0 ()

SambaShare ::

Glede na zahteve logrotate, sploh nimaš kaj razmišljati.

Zimonem ::

Najbrž je najbližje Garamond. CSV kompresiran prek http je nekje 70% prihranka.

Zbirati podatke v en file, ki ga lahko potem uporabniki sami jemljejo, je tako leto 1990?

A ne morete narediti ene usrane baze in gor en reporting software? Recimo OpenSearch (https://opensearch.org/)

Poleg tega delaš vsaj 2 stvari pri tekstovnih datotekah, ki se filajo:

1. Dnevni rotation
2. Rotation na podlagi velikosti

Itak pa vse, razen trenutno aktivno zipneš in arhiviraš.

Kaj tukaj ni jasno?

Pa daj preberi , kakšen je celoten pipeline. Ljudje hočejo celoten dataframe potem ga pa obdelujejo po svoje. Ali prek skript ali prek excela, whatever.

Invictus ::

Imaš produkcijske podatke in jih imaš v enem, preko Giga velikem filu?

Res pametno zasnovan sistem... Single point of failure...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

BlaY0 ::

Invictus je izjavil:


A ne morete narediti ene usrane baze in gor en reporting software? Recimo OpenSearch (https://opensearch.org/)

To usrano bazo je potem treba bekapirat in smo v končni fazi spet na .tar.gz ali .tar.lz4 in 3x več infrastrukture.

Če v loge gledaš 1x na vsake kvatre potem je baza z vso infrastrukturo zadaj en velik overkill.

Če ti pa dodatna infrastruktura ni problem in bi rad fleksibilnost potem pa usmeriš loge v kakšen Graylog.

Invictus ::

Naj pove obseg firme in tip podatkov, preden bluzimo...

Bi rekel, da ni ravno pomembno...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Zimonem ::

Invictus je izjavil:

Naj pove obseg firme in tip podatkov, preden bluzimo...

Bi rekel, da ni ravno pomembno...

Pa daj ne bluzi gre za podatke iz senzorike , kjer se neredko vrže precej zapisov proč, baza jih pa niti ni sposobna sprocesirat.

BlaY0 ::

Zimonem je izjavil:

Invictus je izjavil:

Naj pove obseg firme in tip podatkov, preden bluzimo...

Bi rekel, da ni ravno pomembno...

Pa daj ne bluzi gre za podatke iz senzorike , kjer se neredko vrže precej zapisov proč, baza jih pa niti ni sposobna sprocesirat.

Zakaj jih ne bi bila sposobna sprocesirat? Vse to smo počeli že 30 let nazaj. Z večanjem obsega zbranih podatkov se je izbolševala tudi strojna oprema. Danes je že vsaka pametna žarnica zmožna on-the-fly kompresirat podatke z lz4.

Zimonem ::

dB nima filtrov. Niti ga nečeš pri analizi. Ga spišeš. Pa še različni senzorji različne sheme. Ne zastonj se izogiba pretirani shematizaciji podatkovnega procesa, če ta ni ravno računovodske narave. Zato se danes tudi uporablja precej več jasona kot soapa. Je pa s slednjim lažje delat če je vse v nulo zdefinira od , ampak selit in filtrirati podatke je pa latrina.

Invictus ::

Povej to večini evropskim velikim podjetjem, kjer počnejo ravno to...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

BlaY0 ::

Dandanes lahko v "bazo" zapišeš že kompresiran json, ki tako ali tako pride lahko kompresiran že od izvora. To baza vse pogoltne in zna on-the-fly razpakirat pri branju iz nje. Skratka niti ne rabiš pošiljati "as is" podatkov po nekem komunikacijskem protokolu, ki btw uporablja kompresijo, zadeve na drugi strani odkompresirat, spravit na disk nekompresirano in potem "lo and behold" vse nazaj zakompresirat v ločenem procesu. Waste of resource, če mene prašaš.

Zimonem ::

Kaj že počnejo. Saj nisi za drugega kot podpora računoivodkinjam.

Spura ::

Prvo vprasanje je: ali je problem prostor na napravi? To ti odgovori ce rabis kompresirat ze na napravi. Drugace je, kot je ze nekdo povedal, dovolj HTTP server, ki zna kompresirati pri prenosu samem.

jukoz ::

Vidim da ste malo zašli.

Če se citiram:
"Ostati mora ena datoteka. Po možnosti čim manjša - rad bi jih zmanjšal iz 1GB na kaj manj. Da jo lahko uporabnik v miru prenese tudi večkrat, če je prvo poškodoval."

V smislu, da če jo je skopiral k sebi in jo posvinjal, da jo lahko v miru še enkrat prenese in ne čaka 100 let na to. Ne vem kakšne linije uporabniki imajo in me ne zanima.

Procesov nadaljnjih obdelav ne bo nihče spreminjal in mora datoteka ostati ena sama.

Tako da, @pegasus, hvala za odgovor, to sem iskal.

Spura ::

jukoz je izjavil:

Vidim da ste malo zašli.

Če se citiram:
"Ostati mora ena datoteka. Po možnosti čim manjša - rad bi jih zmanjšal iz 1GB na kaj manj. Da jo lahko uporabnik v miru prenese tudi večkrat, če je prvo poškodoval."

V smislu, da če jo je skopiral k sebi in jo posvinjal, da jo lahko v miru še enkrat prenese in ne čaka 100 let na to. Ne vem kakšne linije uporabniki imajo in me ne zanima.

Procesov nadaljnjih obdelav ne bo nihče spreminjal in mora datoteka ostati ena sama.

Tako da, @pegasus, hvala za odgovor, to sem iskal.
Mislim, ti imas nemogoce zahteve. Rad bi imel en sam file, pisal vanj, hkrati bi pa rad da je file kompresiran. To ne gre. Oziroma lahko imas v teoriji stream compression, ampak taki preprosti tooli tega ne bodo znali, in tvoj pisatelj v file gotovo ni temu prilagojen.

Zgodovina sprememb…

  • spremenil: Spura ()

Invictus ::

Zato so mu tudi predlagali logrotate :D.

Ampak, če nočejo implementirati kake baze s podatki, potem že niso tako pomembni...

Drugače pa nekateri FTP serverji podpirajo MODE Z - on the fly kompresijo.

Sam mora to podpirati tudi FTP client...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Zgodovina sprememb…

  • spremenil: Invictus ()

jukoz ::

Še statusno poročilo:

upoštevali smo nasvete in uporabili klasičen ZIP, tako da lahko uporabnik podatke odpakira tudi na WinXP (ja, tudi to se najde).
V povprečju se skrčijo na cca 20% prvotne velikosti, kar je povsem dovolj.

Hvala vsem za ideje.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Stiskanje datotek (strani: 1 2 )

Oddelek: Pomoč in nasveti
5412309 (6519) Oberyn
»

Canon predstavil tipalo z 250 milijoni točk

Oddelek: Novice / Zasloni / projektorji / ...
4222876 (11991) LuiIII
»

[js] json kompresija

Oddelek: Programiranje
223887 (3236) infiniteLoop
»

Compress

Oddelek: Znanost in tehnologija
332742 (2096) nevone
»

Kako stisnit (Zrarat) datoteko veliko 700mb na 20mb???

Oddelek: Pomoč in nasveti
204865 (4339) StratOS

Več podobnih tem