助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 7

新しいコメント
 
YuraZ:

考え方は明快だ...

にもかかわらず、この方法論は（ちょっと検索しただけでは）業界ベースでは利用できない

訳あり

なぜなら、データベースはすでに、すべてのデータをRAMにロードすることなく、検索というタスクに完璧に対処しているからです。
 
Integer:

圧縮されたデータでの検索は、誰も言っていないんです。圧縮された2つの配列を比較する話です。

aaa"、"bbb"、"vvv "という配列があるとする。3つの配列 要素は、それぞれ独立して圧縮されます。圧縮して、配列「a」「b」「c」を得たとします。

求められた文字列 "bbb "は、配列の中から探す必要があります。検索する前に、圧縮して "b "を得る。今、私たちはそれを探し、見つけることができます。

はっきり言いますが、あなたの場合、反復回数を省略しているので、圧縮して3a、3b、3cとなるはずです。

このようなアルゴリズムで70〜80%の圧縮率が得られると思ったら大間違いです。ロシア語のテキストでも（数値はともかく）このやり方ではデータが膨れ上がるだけです。

例えば、単語「Expert」は「1E1k1с1п1е1р1t」と再符号化され、1ビットも圧縮されず、2倍に膨れ上がることになる。を省略した場合でも、圧縮は行われません。

日時 2014.08.18 13:45:45は、あなたの方法を圧縮を与えることはありません。

名言はもちろんのこと...そのため、この場合、このようなトランスコーディングの効率は0に近くなります。これは、PCXフォーマットで使用されている、いわゆるRLEアルゴリズムです。

 
elugovoy:

1.はっきり言いますが、あなたの場合、反復回数を省略しているので、圧縮して3a、3b、3cとなるはずです。

このようなアルゴリズムで70〜80%の圧縮率が得られると思ったら大間違いです。ロシア語のテキストでも（数値はともかく）このやり方ではデータが膨れ上がるだけです。

例えば、単語「Expert」は「1E1k1с1п1е1р1t」と再符号化され、1ビットも圧縮されず、2倍に膨れ上がることになる。を省略した場合でも、圧縮は行われません。

日時 2014.08.18 13:45:45は、あなたの方法を圧縮を与えることはありません。

名言はもちろんのこと...そのため、この場合、このようなトランスコーディングの効率は0に近くなります。これは、PCXフォーマットで使用されている、いわゆるRLEアルゴリズムです。

1.事実ではありません。もしかしたら、すべてが3回になるようなデータだから、こんな単純な圧縮アルゴリズムになったのかもしれませんね。

あとは...おお、ありがとうございます。短いデータの列を圧縮するとサイズが大きくなるとは、目からウロコです。

 
Integer:
なぜなら、すべてのデータをRAMにロードしなくても、データベースはすでに素晴らしい検索を行なっているからです。

実際、良いSQLサーバーを正しくセットアップする（例えば、ハードウェアが64Gと128ZUの場合）。

オペレーティングシステムのニーズを除いた64gの実質的なすべてを占有しています。128г

そして、20ギガのデータ（プリキャッシュされたデータ）の検索は、実質的にメモリ上で行われることになります......。

だから、圧縮する意味がないのです

--

 
Integer:

ヒントみたいなものですね。

検索の仕方、先に 書きました。

まず、「ほのめかし」と「主張」は異なる概念です。

次に、私の言葉にはそんなことは微塵もありません、もう一度言います。ソースファイルに対して1つのツリーが存在し、データの一部が見つかると別のツリーが存在することになる

また、多少なりとも本格的な圧縮アルゴリズム（古典的なものならハフマンでも）を使うと、検索ができなくなる。理論的にも無理です。

 
Integer:
なぜなら、すべてのデータをRAMにロードしなくても、データベースはすでに素晴らしい検索を行なっているからです。
だから、SQLデータベースに20ギガバイトを入れるのは意味があるんです。
 
elugovoy:

まず、「ヒント」と「アサーション」は異なる概念である。

次に、私の言葉にはそんなことは微塵もありません、もう一度言います。ソースファイルは1つのツリーを持ちますが、データの検索を行う部分は独自のツリーを持ちます。

また、多少なりとも本格的な圧縮アルゴリズム（古典的なものであれば、ハフマンでも可）を使うと、検索ができなくなる。理論的にも無理です。

同じデータを圧縮しているのに、なぜデータの一部だけツリーが違うのですか？異なるデータであれば、異なるツリーを持たせてください。重要なのは、同じデータを圧縮するときに、圧縮されたデータを一致させることです。
 
Integer:
同じデータを圧縮しているのに、なぜ一部だけ違うツリーがあるのでしょうか？もし違うデータなら、違うツリーを持たせればいいのです。私たちにとって重要なのは、同じデータを圧縮したときの圧縮データの一致度です。

ディミトリ - それが可能であれば

昔なら、SQLの産業用データベースを作って、80％～90％の圧縮データで（高速に）検索していただろうに...。

挿入・更新・削除も可能

 
Integer:

1.それは事実ではありません。もしかしたら、すべてが3回になるようなデータかもしれないので、単純な圧縮アルゴリズムにしたのかもしれません。

あとは...短いデータの列を圧縮するとサイズが大きくなるとは知らなかっただけに、目を見開かせていただきありがとうございました。

そしてもうひとつ、目を見開くための小論文を。どんなエンコーディングにも目的がある。

圧縮符号化には伸長符号化があり、テレタイプしかサポートしない通信路でバイナリデータを伝送することを目的としており（例：電子メールによる画像）、通常はRadixアルゴリズムに基づくBase64が使用される。

データ補正に伴う冗長符号化（CD Aduioなど）は、物理的なキャリアへのダメージからデータを可能な限り保護することを目的としています。

圧縮符号化、その目的 保存／アーカイブ のデータを使用します。

 
YuraZ:

ドミトリー - 可能であれば

80%〜90%に圧縮されたデータを（高速に）検索できる産業用SQLデータベースをとっくに作っていただろうに...。

第2ラウンドを目指す？5-6ページから読み直してください。特に投稿を よく読んでください。

私が示唆したことを私に帰結させないでください。私は、互いに独立して圧縮されている凝縮された配列を比較することを提案しました。別々に圧縮された巨大なファイルの中にある小さなテキストを一度に探すのではありません。

1234567891011121314...21
新しいコメント