データベースに最大 32 GB のデータを入れる必要があるアプリを作成しています。読み取りには範囲クエリがあるため (0 < time < 1hr など)、B ツリー インデックスを使用しています。
最初 (データベース サイズ = 0GB) では、1 ミリ秒あたり 60 回と 70 回の書き込みが発生します。5GB と言った後、私がテストした 3 つのデータベース (H2、berkeley DB、Sybase SQL Anywhere) は、1 ミリ秒あたりの書き込みが 5 回未満になるまで、本当に遅くなりました。
質問:
ノート：
各レコードはいくつかの int で構成されます
はい; インデックス作成により、挿入時間は犠牲になりますが、フェッチ時間は改善されます。あなたの数字は合理的に聞こえます-詳細を知らなくても。
ベンチマークできます。適切な量のデータを保存する必要があります。クエリに基づいてインデックスを作成するかどうかを検討してください - 重いフェッチと軽い挿入? where句がそれを使用する可能性のあるすべての場所にインデックスを付けます。軽いフェッチ、重い挿入？おそらくインデックスを避けます。混合ワークロード; ベンチマークしてください！
ベンチマークを行うときは、ボリュームとデータ ドメインの両方で、可能な限り現実的または現実的なデータが必要です (たとえば、すべての「ヘンリー スミス」だけでなく、あらゆる種類の名前のデータの分布)。
インデックスがアクセス速度のために挿入速度を犠牲にするのは一般的です。これは、すべての列にインデックスを付けるデータベース テーブル (実際に見たことがある) から見つけることができます。クエリの数に比べて更新の数が少ない場合は、本質的に問題はありません。
ただし、次のことを前提とします。
1/ 書き込み速度が 5/ms まで低下することを懸念しているようです (それでも 5000/秒です)。
2/ レコードごとに数個の整数しか書き込んでいない。と
3/ クエリは時間クエリのみに基づいています。
通常のデータベースをバイパスして、独自の種類のデータベースを展開することを検討することをお勧めします (私の考えでは、デバイスの読み取り値などのリアルタイム データを収集していると思います)。
シーケンシャル タイミング データのみを書き込む場合は、フラット ファイルを使用して、「インデックス」情報を定期的に個別に (毎分の開始時などに) 書き込むことができます。
これにより、書き込みが大幅に高速化されますが、比較的効率的な読み取りプロセスが可能になります。最悪の場合、関連する期間の開始を見つけて、そこからスキャンを実行する必要があります。
もちろん、これはあなたのストレージが正しいという私の仮定に依存します：
1/ 時間に基づいて順番にレコードを書き込んでいます。
2/ 時間範囲のクエリのみが必要です。
はい、インデックスは通常、挿入を遅くしますが、選択 (クエリ) を大幅に高速化します。
B ツリーへのすべての挿入が等しいわけではないことに注意してください。それは木です。挿入するだけなら、成長し続けなければなりません。データ構造ではある程度のパディングが可能ですが、連続して増加する数値を挿入し続けると、バランスを保つために新しいページを追加したり、シャッフルしたりする必要があります。テストで適切に分散された数値が挿入されていることを確認し (実際にはそのようになると仮定します)、B ツリーに最初から予想されるアイテムの数を伝えるために何かできるかどうかを確認してください。
@Richard-tに完全に同意します-オフライン/バッチシナリオでは、コーパスへの一括更新の前にインデックスを完全に削除し、更新が完了したときにのみ再適用することは非常に一般的です。
適用されるインデックスの種類も挿入パフォーマンスに影響します。たとえば、SQL Server クラスター化インデックス更新では、データ分散とインデックス更新に I/O が使用されますが、非クラスター化インデックスは個別の (したがってより高価な) I/O 操作で更新されます。 .
他のエンジニアリング プロジェクトと同様に、実際のデータセットで測定することをお勧めします (スキュー ページ分布、ティアリングなど)。
BDBドキュメントのどこかで、ページサイズがbtreeのこの動作に大きく影響すると述べていると思います。同時実行の方法で多くのことを行っておらず、レコード サイズが固定されていると仮定すると、ページ サイズを増やしてみてください。