10 億を超えるキーを Berkley DB にロードする必要があるため、事前にチューニングしてパフォーマンスを向上させたいと考えています。標準構成では、1,000,000 個のキーをロードするのに約 15 分かかりますが、これは遅すぎます。たとえば、Berkley DB の B+Tree (ノード サイズなど) を調整する適切な方法はありますか?
(比較として、tokyo キャビネットをチューニングした後、25 分で 10 億のキーをロードします)。
PS実行中のシステムに設定するパラメーターではなく、コードとしてのチューニングのヒントを探しています（jvmサイズなど...）
TokyoCabinet が 25 分間で 10 億個のキーをロードするとき、保存されているキー/値のサイズはどのくらいですか? 使用している I/O システムとストレージ システムは何ですか? 「ロード」という用語を使用して、永続的な安定ストレージへの 1B のトランザクション コミットを意味していますか? これは 1 秒あたり 666,666 回の挿入であり、私が認識している I/O システムでは物理的に不可能です。その数にキーと値のサイズを掛けると、どうしようもなく物理的な限界を超えてしまいます。
Gustavo Duarteのブログを見て、I/O システムとハードウェアのしくみについて少し読んでから、あなたの声明を見直してください。TokyoCabinet が正確に何をしていて、何をしていないのかを知りたいと思っています。推測する必要がある場合は、オペレーティングシステムのファイルシステムキャッシュにコミットしていますが、それらのバッファーをディスクにフラッシュ (fdsync()-ing) していません。
完全な開示: 私は Oracle で Oracle Berkeley DB (TokyoCabinet の直接の競合相手) のプロダクト マネージャーを務めており、これらのデータベースとその周辺にある最高のハードウェアを約 10 年間使用してきたので、偏見と懐疑の両方を持っています。 .
Berkeley DB には、トランザクション ハンドルに設定できるフラグがあります。これらのフラグは、速度と耐久性 (ACID の「D」) をトレードオフするこの方法や他の同様の方法を模倣しています。
Berkeley DB Java Edition (BDB-JE) を高速化する方法に関しては、以下を試すことができます。
データベースのパフォーマンスに関する主張を明確にすることは非常に重要です。それらは単純に見えますが、データを破損したり、コミットされたトランザクションを失ったりしないように正しく設定するのは非常に難しいことがわかりました。
これが少し役立つことを願っています。
BDB-JE での一括挿入は、単一のトランザクションにグループ化すると桁違いに高速になります。その理由は、トランザクションがコミット時に同期されている間に、単一のコミットごとに (デフォルトで) ディスクへの同期書き込みが発生するためです。私のアプリケーションでは、単一のコミットとして 100,000 個の小さなキーを書き込むのに 1 分以上かかりましたが、トランザクションではわずか数秒しかかかりませんでした。