非常に大きなデータベース ファイルを持つ sqlite のパフォーマンス特性は何ですか? [closed] 質問する

そこで、非常に大きなファイルに対して sqlite でいくつかのテストを行い、いくつかの結論に達しました (少なくとも私の特定のアプリケーションについては)。

テストには、単一のテーブルまたは複数のテーブルを含む単一の sqlite ファイルが含まれます。各テーブルには約 8 列 (ほぼすべて整数) と 4 つのインデックスがあります。

アイデアは、sqlite ファイルが約 50 GB になるまで十分なデータを挿入するというものでした。

シングルテーブル

1 つのテーブルのみを含む sqlite ファイルに複数の行を挿入しようとしました。ファイルが約 7 GB になると (行数を正確にはわかりません)、挿入に時間がかかりすぎました。すべてのデータを挿入するテストには 24 時間ほどかかると見積もっていましたが、48 時間経っても完了しませんでした。

このことから、単一の非常に大きな sqlite テーブルでは挿入に問題が生じ、おそらく他の操作にも問題が生じるだろうという結論に至りました。

これは驚くことではないと思いますが、テーブルが大きくなるにつれて、すべてのインデックスの挿入と更新に時間がかかります。

複数のテーブル

次に、データを時間ごとに複数のテーブルに分割し、1 日あたり 1 つのテーブルを作成しました。元の 1 つのテーブルのデータは、約 700 個のテーブルに分割されました。

この設定では挿入に問題はなく、毎日新しいテーブルが作成されるため、時間が経っても時間がかかることはありませんでした。

真空の問題

i_like_caffeine が指摘したように、VACUUM コマンドは、sqlite ファイルが大きいほど問題になります。挿入/削除が頻繁に行われると、ディスク上のファイルの断片化が悪化するため、定期的に VACUUM を実行してファイルを最適化し、ファイル領域を回復することが目標です。

しかし、ドキュメンテーション、データベースの完全なコピーが作成され、バキュームが実行されるため、完了するまでに非常に長い時間がかかります。したがって、データベースが小さいほど、この操作はより速く完了します。

結論

私の特定のアプリケーションでは、バキューム パフォーマンスと挿入/削除速度の両方を最適化するために、データを 1 日 1 つずつ複数の db ファイルに分割することになるでしょう。

これによりクエリが複雑になりますが、私にとっては、これだけの量のデータをインデックス化できるのは価値のあるトレードオフです。もう 1 つの利点は、1 日分のデータを削除するために、db ファイル全体を削除するだけで済むことです (これは私のアプリケーションでは一般的な操作です)。

速度が問題になるかどうかを知るために、ファイルごとのテーブル サイズも監視する必要があるでしょう。

残念ながら、増分真空法は他にはないようです。自動掃除機. 自動バキュームでは実行できない、バキュームの目的がファイルのデフラグであるため、これを使用できません (ファイル スペースは大した問題ではありません)。実際、ドキュメントには、自動バキュームにより断片化が悪化する可能性があると記載されているため、定期的にファイルに対して完全なバキュームを実行する必要があります。