完全に C で記述されたアプリケーションがあります。テーブルからいくつかの値を取得するなど、コード内のテーブル アクセスには、Pro*C を使用します。また、アプリケーションのパフォーマンスを向上させるために、データをフェッチするためにいくつかのテーブルもプリロードします。一般に、いくつかの入力フィールドを取得し、テーブルから出力フィールドをフェッチします。
通常、テーブルには約 30000 のエントリがあり、最大で 10 万に達することもあります。
しかし、テーブル エントリが約 1,000 万エントリに増えると、アプリケーションのパフォーマンスに危険な影響を与えると思います。
私はどこか間違っていますか？本当にパフォーマンスに影響する場合、アプリケーションのパフォーマンスを安定させる方法はありますか?
アプリケーションがテーブルを操作する方法を考慮して、テーブル内の行数が 1,000 万に増加した場合に考えられる回避策は何ですか?
テーブルを並べ替えていない場合、検索時間は比例して増加します...何か間違ったことをコーディングしていなければ、あなたの例 (30K 対 1M) では、検索時間が 33 倍になります。テーブルを段階的に反復 (i++ スタイル) していると仮定しています。
ただし、何らかの方法でテーブルを並べ替えることができれば、検索時間を大幅に短縮できます。これが可能になるのは、ソートされた情報を検索するインデクサー アルゴリズムは、検索対象の要素に到達するまですべての要素を解析しないためです。補助テーブル (ツリー、ハッシュなど) を使用し、通常ははるかに高速に検索し、検索対象の正しい要素を特定します。 、または少なくともマスターテーブルのどこにあるかをより正確に推定できます。
もちろん、要素を挿入または削除するとき、または検索を実行するときに、テーブルを並べ替える必要があります。
まあ、それは本当にあなたがデータで何をしているかに依存します. kit-and-kabootle 全体をメモリにロードする必要がある場合は、大きなバルク サイズを使用して、発生する必要があるオラクル ラウンド トリップの数を少なくするのが妥当な方法です。
結果セット全体をメモリにロードできるメモリ リソースが実際にない場合でも、大きなバルク サイズが Oracle のオーバーヘッドに役立ちます。適切なサイズのレコードのチャンクをメモリに取得し、それらを処理してから、次のチャンクを取得します。
実際のランタイム環境とビジネス目標に関する詳細情報がなくても、それは誰もが得ることができるほど具体的です。
この問題について詳しく教えてください。
キャッシュ サイズが 1MB 以上になると、キャッシュ ミスが多すぎる可能性があります。
テーブルを複数回繰り返したり、要素にランダムにアクセスしたりすると、多くのキャッシュ ミスが発生する可能性があります。
「google hash」にアクセスして、その実装を確認してみてはいかがでしょうか? それはC++にありますが