berkeley-db-je - BerkeleyDBファイルの圧縮

Question

これは私の前の質問と関連していますここをクリックしてください。リレーショナルDBに処理および保存される前の一時ストレージにberkeleyDBを使用しています。サイズが特定のポイントを超えると問題が発生します。次に、ファイルを小さいファイルに分割するか、既存のファイルを圧縮する必要があります。質問圧縮部分に質問したいのですが、berkeley DBに圧縮ユーティリティが組み込まれているのか、それともプログラムで実行する必要があるのか​​を尋ねます。組み込みの場合は、常に高速になります。

Answer 1

ここから：

Berkeley FAQによると、（圧縮前に）最適化する方法は2つあります。

1. コンパクト
2. 真空

ここに示すように、独自の圧縮アルゴリズムを実装することもできます。

Berkeley DB VACUUMはSQLiteのものとどのように異なりますか？

SQLiteは、VACUUMコマンドをデータベースダンプとして実装し、その後にそのダンプから完全にリロードします。これはコストのかかる操作であり、操作の間データベース全体をロックします。これは、オールオアナッシング操作でもあります。動作するか、失敗して、いつか再試行する必要があります。SQLiteが終了すると、データベースのサイズが小さくなり（ファイルサイズが小さくなり）、ダンプファイルからのデータが順番にキー挿入されるため、btreeが以前よりも整理されます（浅くなります）。SQLiteは、それが機能し、データベースから全員をロックアウトする余裕がある場合、VACUUMをうまく機能させます。Berkeley DBは、まったく異なる方法でこれにアプローチします。現在、多くのリリースで、Berkeley DBのB-Tree実装には、他の操作が実行されている間に圧縮する機能があります。圧縮は、Bツリーノードが検査され、最適ではない場合に再編成されるプロセスです（逆分割など）。Bツリーが浅いほど、リーフノードでデータを見つけるために必要なルックアップは少なくなります。Berkeley DBは、ツリーのセクションまたはツリー全体を一度に圧縮できます。7x24x365（ファイブナイン）操作の場合、これは重要です。BDBバージョンのcompactは、進行中のデータベース操作に悪影響を及ぼしませんが、SQLiteのアプローチは影響を及ぼします。ただし、圧縮では、データベースの空のセクション（削除されたデータがかつて存在していたデータベースファイルのセグメント）はアドレス指定されません。Berkeley DBは、ファイル内のデータを移動し、ファイルを切り捨ててそのスペースをファイルシステムに戻すことにより、データベースファイルの圧縮もサポートします。Berkeley DBのリリース5.1以降、VACUUMコマンドはデータベースファイルを圧縮および圧縮します。この操作は、データベースの操作を維持できるようにするためにより多くの作業を行っているため、SQLiteのダンプ/ロードアプローチよりも時間がかかります。これは正しいトレードオフであると信じていますが、同意しない場合は、いつでもコード内のデータベースをダンプ/ロードできます。