アカウント名:
パスワード:
プレーンテキストなら圧縮率高いから、100分の1程度になるとしても26GB。。。試しに落とす気にもなれないなぁ。
圧縮率が高くなるのは,情報が少ないファイルだけです
仮に圧縮して100分の1程度になるテキストファイルがあればそれはたとえば同じ個人名を100回繰り返して書いたようなコピペだらけのファイルで有る可能性が高いです
テキストファイルの圧縮率は,その内容により変化します繰り返し登場する単語があればそれが圧縮できますが異なる名前や異なる金額が書かれたファイル,つまり情報が沢山つまったファイルでは圧縮出来る箇所が少なくなり,圧縮率が低くなります
極端な例をあげると,ランダムな値を書いたバイナリファイルは,まったく圧縮出来ません圧縮すると逆にサイズが増えます(*1)
半角英数のテキストファイルを圧縮すると,最悪の場合でサイズは1/2程度(*2)一般的な場合で10分の1程度になります(*3)
このように情報が多いファイルほど圧縮率は低く情報が少ないファイルほど圧縮率は高くなります
ですから,かりに100分の1程度に高圧縮出来るテキストファイルがあるとすればその内容はかなり薄い筈はずです
*1例えば以下の手順でランダムな値で10MBのバイナリファイル hoge を作成しxzで圧縮すると, 1MB程度サイズが増えた 11MBのファイル hoge.xz が出来ます$ dd if=/dev/urandom of=/tmp/hoge bs=1M count=10$ ls -lha hoge$ xz hoge$ ls -lha hoge.xz
これはデータ本体は圧縮が効かず10MB程度になりそこにxzのメタデータ(辞書とかヘッダとか)を付与するため1MB程度サイズが増えるためです
*2asciiコードは大雑把に言うと,1文字を7bitで符号化するので,1バイト(=8bit)あたり1bit無駄があります圧縮するとこの無駄を削減できるので,最低でもデータサイズを1bit分つまり半分に圧縮できます
*3たとえば linux のソースコードは 700MB程度ありますが,xz 形式で圧縮しても80MB程度です
> asciiコードは大雑把に言うと,1文字を7bitで符号化するので,1バイト(=8bit)あたり1bit無駄があります> 圧縮するとこの無駄を削減できるので,最低でもデータサイズを1bit分つまり半分に圧縮できます
8bit が 7bit になるのなら、元のデータサイズの 7/8 = 87.5%になって、12.5%減るけど、半減はしないんじゃないの?
半減で合ってるかと。11桁と10桁を比べてが10/11≒90.9%とは考えませんよね?
asciiテキストのみ、しかも数字の出現確率が高いとくれば、ハフマンがよく効きそうですけどね。8-1=7で半分とは、さすがに誘い受けの部類でしょうか。
情報が多い/少ないという言葉が誤解を招きやすい。たとえば姓が同じ/似ている人が多いだけで情報はかなり圧縮できる。圧縮率を上げるためにはどこまで同じかという判断をするアルゴリズムが重要。
ちなみに今回の2.6TBのデータのformatや解析方法の解説 [medium.com]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
2.6TBってホントだろうか。。 (スコア:0)
プレーンテキストなら圧縮率高いから、100分の1程度になるとしても26GB。。。
試しに落とす気にもなれないなぁ。
Re:2.6TBってホントだろうか。。 (スコア:2)
圧縮率が高くなるのは,情報が少ないファイルだけです
仮に圧縮して100分の1程度になるテキストファイルがあれば
それはたとえば同じ個人名を100回繰り返して書いたような
コピペだらけのファイルで有る可能性が高いです
テキストファイルの圧縮率は,その内容により変化します
繰り返し登場する単語があればそれが圧縮できますが
異なる名前や異なる金額が書かれたファイル,つまり情報が沢山つまったファイルでは
圧縮出来る箇所が少なくなり,圧縮率が低くなります
極端な例をあげると,ランダムな値を書いたバイナリファイルは,まったく圧縮出来ません
圧縮すると逆にサイズが増えます(*1)
半角英数のテキストファイルを圧縮すると,最悪の場合でサイズは1/2程度(*2)
一般的な場合で10分の1程度になります(*3)
このように
情報が多いファイルほど圧縮率は低く
情報が少ないファイルほど圧縮率は高くなります
ですから,かりに100分の1程度に高圧縮出来るテキストファイルがあるとすれば
その内容はかなり薄い筈はずです
*1
例えば以下の手順でランダムな値で10MBのバイナリファイル hoge を作成し
xzで圧縮すると, 1MB程度サイズが増えた 11MBのファイル hoge.xz が出来ます
$ dd if=/dev/urandom of=/tmp/hoge bs=1M count=10
$ ls -lha hoge
$ xz hoge
$ ls -lha hoge.xz
これはデータ本体は圧縮が効かず10MB程度になり
そこにxzのメタデータ(辞書とかヘッダとか)を付与するため1MB程度サイズが増えるためです
*2
asciiコードは大雑把に言うと,1文字を7bitで符号化するので,1バイト(=8bit)あたり1bit無駄があります
圧縮するとこの無駄を削減できるので,最低でもデータサイズを1bit分つまり半分に圧縮できます
*3
たとえば linux のソースコードは 700MB程度ありますが,xz 形式で圧縮しても80MB程度です
半角英数は最悪でも半減できる?? (スコア:0)
> asciiコードは大雑把に言うと,1文字を7bitで符号化するので,1バイト(=8bit)あたり1bit無駄があります
> 圧縮するとこの無駄を削減できるので,最低でもデータサイズを1bit分つまり半分に圧縮できます
8bit が 7bit になるのなら、元のデータサイズの 7/8 = 87.5%になって、12.5%減るけど、半減はしないんじゃないの?
Re: (スコア:0)
半減で合ってるかと。11桁と10桁を比べてが10/11≒90.9%とは考えませんよね?
Re: (スコア:0)
asciiテキストのみ、しかも数字の出現確率が高いとくれば、ハフマンがよく効きそうですけどね。
8-1=7で半分とは、さすがに誘い受けの部類でしょうか。
Re: (スコア:0)
情報が多い/少ないという言葉が誤解を招きやすい。
たとえば姓が同じ/似ている人が多いだけで情報はかなり圧縮できる。
圧縮率を上げるためにはどこまで同じかという判断をするアルゴリズムが重要。
Re: (スコア:0)
ちなみに今回の2.6TBのデータのformatや解析方法の解説 [medium.com]