非常に大きなデータベースファイルを使用するsqliteのパフォーマンス特性は何ですか？[閉まっている]

sqliteは、サポートされている場合でも、非常に大きなデータベースファイルでは十分に機能しないことを知っています（1 GBを超えるファイルサイズが必要な場合は、エンタープライズrdbmsの使用を検討することをお勧めします。もう見つかりません。古いバージョンのsqliteに関連している可能性があります）。

しかし、私の目的のために、他の解決策を検討する前に、それが実際にどれほど悪いかを理解したいと思います。

私は2GBから数ギガバイトの範囲のsqliteデータファイルについて話しています。誰でもこれについて何か経験がありますか？ヒント/アイデアはありますか？

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

テストには、単一のテーブルまたは複数のテーブルのいずれかを含む単一のsqliteファイルが含まれます。各テーブルには約8列、ほとんどすべての整数、および4つのインデックスがありました。

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

シングルテーブル

テーブルを1つだけ含む複数の行をsqliteファイルに挿入しようとしました。ファイルが約7GBの場合（申し訳ありませんが、行数を特定することはできません）、挿入に時間がかかりすぎていました。すべてのデータを挿入するテストには24時間程度かかると推定していましたが、48時間後でも完了しませんでした。

これにより、単一の非常に大きなsqliteテーブルには挿入に関する問題があり、おそらく他の操作にも問題があると結論付けました。

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

複数のテーブル

次に、1日あたり1つのテーブルで、いくつかのテーブルにデータを時間で分割してみました。元の1つのテーブルのデータは、約700のテーブルに分割されました。

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

真空の問題

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

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

結論

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

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

速度が問題になる時期を確認するには、おそらくファイルごとのテーブルサイズも監視する必要があります。

自動バキューム以外にインクリメンタルバキューム法がないように見えるのは残念です。私のバキュームの目標はファイルをデフラグすることです（ファイルスペースはそれほど重要ではありません）。これは、自動バキュームではできません。実際、ドキュメントには断片化が悪化する可能性があると記載されているため、定期的にファイルを完全に掃除する必要があります。

プラットフォームでは50 GB以上のDBSを使用しています。文句はありません。すべてが正しく行われていることを確認してください。定義済みステートメントを使用していますか？* SQLITE 3.7.3

1. 取引
2. 事前の発言

3. これらの設定を適用します（DBを作成した直後）

   PRAGMA main.page_size = 4096;
   PRAGMA main.cache_size=10000;
   PRAGMA main.locking_mode=EXCLUSIVE;
   PRAGMA main.synchronous=NORMAL;
   PRAGMA main.journal_mode=WAL;
   PRAGMA main.cache_size=5000;

これが他の人に役立つことを願って、ここでうまく機能します

最大3.5GBのSQLiteデータベースを作成しましたが、目立ったパフォーマンスの問題はありません。私が正しく覚えていれば、SQLite2にはいくつかの下限があった可能性があると思いますが、SQLite3にはそのような問題はないと思います。

SQLiteの制限ページによると、各データベースページの最大サイズは32Kです。また、データベースの最大ページ数は1024 ^ 3です。したがって、私の計算では、最大サイズとして32テラバイトになります。SQLiteに到達する前に、ファイルシステムの限界に到達すると思います。

挿入に48時間を超える時間がかかった理由の多くは、インデックスが原因です。それは信じられないほど高速です：

1-すべてのインデックスを削除2-すべての挿入を実行3-インデックスを再度作成

通常の推奨に加えて：

1. 一括挿入のインデックスを削除します。
2. 大規模なトランザクションでのバッチ挿入/更新。
3. バッファキャッシュを調整する/ジャーナルを無効にする/ PRAGMAを無効にする。
4. 64ビットマシンを使用します（大量のキャッシュ™を使用できるようにするため）。
5. [2014年7月追加] 複数のSQLクエリを実行する代わりに、共通テーブル式（CTE）を使用してください！SQLiteリリース3.8.3が必要です。

SQLite3の使用経験から次のことを学びました。

1. 挿入速度を最大にするために、列制約のあるスキーマは使用しないでください。（必要に応じて後でテーブルを変更する ALTER TABLEで制約を追加することはできません）。
2. スキーマを最適化して、必要なものを保存します。これは、データベースに挿入する前に、テーブルを分解したり、データを圧縮/変換したりすることを意味する場合があります。良い例は、IPアドレスを（長い）整数として格納することです。
3. dbファイルごとに1つのテーブル-ロックの競合を最小限に抑えるため。（単一の接続オブジェクトが必要な場合は、ATTACH DATABASEを使用してください。
4. SQLiteは同じ列にさまざまな種類のデータを格納できます（動的型付け）。

質問/コメント歓迎。;-)

sqliteスケーリングに関する主な不満は次のとおりです。

1. 単一プロセス書き込み。
2. ミラーリングなし。
3. 複製なし。

7GBのSQLiteデータベースがあります。内部結合を使用して特定のクエリを実行するには2.6秒かかります。これを高速化するために、インデックスを追加してみました。追加したインデックスに応じて、クエリが0.1秒に低下したり、7秒​​に上昇したりしました。私の場合の問題は、列が非常に重複している場合にインデックスを追加すると、パフォーマンスが低下することでした：

SQLiteのドキュメントには、データベースファイルの実際のサイズ制限は数十GBであるという記述がありました。これは主に、トランザクションを開始するたびにSQLiteが「ダーティページのビットマップを割り当てる」必要があるためです。したがって、データベースの各MBに256バイトのRAMが必要でした。50 GBのDBファイルに挿入するには、大きな（2 ^ 8）*（2 ^ 10）= 2 ^ 18 = 256 MBのRAMが必要です。

しかし、SQLiteの最近のバージョンでは、これは不要になりました。詳細はこちら。

私は、vacuumコマンドを使用するときに、大きなsqliteファイルで問題を経験しました。

まだauto_vacuum機能を試していません。データを頻繁に更新および削除することが予想される場合、これは一見の価値があります。