テーブルの 1 つに約 7 億件のレコードが含まれるデータベースを使用する .Net アプリケーションを作成したいと考えています。SQLite のパフォーマンスがこのシナリオを満たしているかどうか、または SQL Server を使用する必要があるかどうか疑問に思います。SQLite がもたらす移植性が気に入っています。
4 に答える
確かにSQL Serverに行きます。SQLite の 7 億レコードは多すぎます。
SQLiteでは次の制限があります
- シングルプロセス書き込み。
- ミラーリングなし
- 複製なし
このスレッドをチェックしてください:非常に大きなデータベース ファイルを持つ sqlite のパフォーマンス特性は何ですか?
700mは多いです。
あなたにアイデアを与えるために。レコード サイズが 4 バイト (基本的に単一の値を格納する) であるとすると、DB は 2GB を超えることになります。レコード サイズが 100 バイトに近い場合は、65 GB に近いことになります (これには、インデックスやトランザクション ログ ファイルなどで使用されるスペースは含まれません)。
私たちは大規模なデータベースで多くの作業を行っていますが、そのサイズのデータベースに対して SQLLite を検討することはありません。率直に言って、「移植性」は、ここでの懸念事項の中で最も少ないものです。そのサイズの DB をあらゆる種類の応答性でクエリするには、適切なサイズのデータベース サーバーが必要です。32GB の RAM と高速ドライブから始めます。
書き込みが 90% 以上多い場合は、より小さな RAM で済む可能性があります。読み取りが重い場合は、マシンが可能な限り多くの DB (または少なくともインデックス) を RAM にロードできるように、それを試して構築する必要があります。そうしないと、ディスク スピンドルの速度に依存することになります。
SQLite は、この量のデータを処理できる必要があります。ただし、このサイズに拡張できるように構成する必要がある場合があり、一般的な原則に基づいて、SQLite の「メモリ内」インスタンスにこれほど多くのデータを含めることはできません。
詳細については、SQLite エンジンの実際の制限について説明しているこのページを参照してください。関連する構成設定は、ページ サイズ (通常は 64KB) とページ カウント (64 ビット int の最大値である約 21 億まで) です。計算すると、データベース全体が 140 TB を超える可能性があります。7 億行の 1 つのテーブルで構成されるデータベースは、数十ギガのオーダーになります。簡単に管理できます。
ただし、SQLite がそれほど多くのデータを格納できるからといって、そうすべきであるとは限りません。大規模なデータストアに対する SQLite の最大の欠点は、SQLite コードがプロセスの一部として実行され、それが呼び出されたスレッドを使用してサンドボックスのメモリを消費することです。サーバー指向の DBMS で利用できる、レプリケーションやクラスタリングのような大規模なクエリやデータストアを「分割して征服する」ためのツールはありません。このような大規模なテーブルを扱う場合、挿入/削除では、テーブルを適切な場所に配置してすべてのインデックスを更新するのに非常に長い時間がかかります。選択は実行可能である場合がありますが、インデックス付きクエリでのみです。ページまたはテーブルのスキャンは絶対にあなたを殺します。
同様のレコード数を持つテーブルがあり、取得に関して問題はありません。
手始めに、ハードウェアとサーバーへの割り当てから始めます。例については、http ://www.sqlservercentral.com/blogs/glennberry/2009/10/29/suggested-max-memory-settings-for-sql-server-2005_2F00_2008/ を参照してください。
次の条件を満たしていれば、レコードのサイズや数に関係なく:
- 外部キーにインデックスを作成し、
- 一般的なクエリをビューに保存 (http://en.wikipedia.org/wiki/View_%28database%29)、
- データベースとテーブルを定期的に維持する
あなたは大丈夫なはずです。また、各列に適切な列タイプ/サイズを設定すると役立ちます。