構成オブジェクトを圧縮するコレクションを提供するJavaサードパーティライブラリはありますか?私はそれをグーグルで検索しましたが、空白になりました。そのような構成は、大きな(マルチギグを読む)マップ、またはそのようなものに役立ちませんか?確かに、アクセスとストレージにはパフォーマンスの低下がありますが、アクセス頻度の低い長期にわたる参照の場合、それは合理的と思われますね。
3 に答える
このユースケースは基本的にインメモリデータベースのユースケースであるため、おそらくそれらを調べる必要があります。
これを行う場合、おそらく基本的に任意の Java オブジェクトをバイトにシリアライズしてから、それらをクラスに反映する必要があります。インメモリデータベースを使用することもできます-Javaがおそらくその種のことに対して少し高レベルであることを除けば、とにかく私が見ることができる本当の違いはありません.
これは実際にはいくぶんJava固有のものであることに注意してください.Cでは、メモリを取得して、派手なことをしなくても圧縮するだけのライブラリを持つことができるかもしれませんが、Javaはメモリにアクセスできないため、そういうのはちょっと難しい…
MapDBは明らかにJavaコレクションスタイルマップを実装し、「透過圧縮」を実行できます(http://www.mapdb.org/apidocs/org/mapdb/DBMaker.html#compressionEnable()を参照)。
オンディスクストレージまたはオフヒープストレージのいずれか用に設計されていると思います(http://www.mapdb.org/apidocs/org/mapdb/DBMaker.html#newDirectMemoryDB()を参照)。したがって、ディスクのブロックから選択できます。または、ガベージコレクションされていないメモリのブロック。
可能性は低い - そのようなコレクションは、ほとんどの状況で実際にはあまり役に立ちません
通常、データ構造は、一連の特定の使用パターンに対して高いパフォーマンスを発揮するように設計されています。圧縮を追加すると、オーバーヘッドが追加され、主なユースケースの速度が低下します。特に、最も効率的な圧縮アルゴリズムは、以前に見たデータへの後方参照を使用することに注意してください。これは通常、コレクション クラスから期待されるランダム アクセス パターンと互換性がなく (つまり、効率的に実装することは不可能)、コレクションの一部を変更する機能とも互換性がありません。
もちろん、圧縮は大量のデータへのシーケンシャル アクセスや、低速のストレージとメイン メモリの間でシャッフルする必要がある非常に大きなデータ ボリュームを処理する場合に最適です。しかし、ファイルシステムとデータベースと呼ばれる優れたツールが既にあります:-)