したがって、10k レコードのテーブルに対するクエリと 10mil レコードのテーブルに対するクエリは、どちらもほぼ同じ数のレコードをフェッチし、単純なインデックス (自動インクリメント、自動インクリメント、レコード ID タイプのインデックス付きフィールド)。
私の質問は、適切にインデックスが作成され、クエリが常にそれらのインデックスを効果的に使用するようにデータベースが設定されている場合、これは 40 億件近くのレコードを持つテーブルに拡張されますか?
また、非常に大きなインデックス付きテーブルに新しいレコードを挿入すると、すべてのインデックスを再計算する必要があるため、非常に遅くなる可能性があることを知っています。テーブルの最後にのみ新しいレコードを追加すると、速度低下を回避できますかインデックスがバイナリ ツリーであり、ツリーの大きなチャンクを再計算する必要があるため、機能しませんか?
最後に、非常に大きなテーブルの操作に関するよくある質問/注意事項を少し調べましたが、実際には見つかりませんでした。そのようなことを知っている人がいれば、そのリンクをいただければ幸いです。
非常に大きなテーブルのインデックス作成 (データベース関連のあらゆるものと同様) は、アクセス パターン、読み取りと書き込みの比率、使用可能な RAM のサイズなど、多くの要因に依存します。
「ホット」(つまり、頻繁にアクセスされるインデックス ページ) をメモリに収めることができれば、アクセスは通常高速になります。
非常に大きなテーブルのインデックス作成に使用される戦略は、パーティション テーブルとパーティション インデックスを使用することです。ただし、クエリがパーティション キーで結合またはフィルター処理されない場合、パーティション化されていないテーブルよりもパフォーマンスが向上することはありません。つまり、パーティションが削除されません。
SQL Server データベースのパーティション分割の神話と真実
インデックスをできるだけ狭くしておくことは非常に重要です。
あなたが要求したように、大きなテーブルと、コスト/メリットを含むインデックス作成の影響についての良い読み物を次に示します。
一意のインデックス ルックアップを介してデータにアクセスすると、テーブルが非常に大きくなると速度が低下しますが、それほど遅くはありません。インデックスは Postgres (ノードごとに 2 つの子しか持たないバイナリ ツリーではない) に B ツリー構造として格納されるため、10k 行のテーブルには 2 つのレベルがあり、10B 行のテーブルには 4 つのレベルがある場合があります (ノードの幅によって異なります)。行）。したがって、テーブルが途方もなく大きくなると、5 レベル以上になる可能性がありますが、これは余分なページが 1 つ読み込まれることを意味するだけなので、おそらく目立たないでしょう。
新しい行を挿入すると、テーブルの物理レイアウトのどこに挿入されるかを制御できないため、インデックス付けされている最大値を使用するという点で「テーブルの終わり」を意味すると思います。この場合、Oracle がリーフ ブロックの分割に関していくつかの最適化を行っていることは知っていますが、Postgres については知りません。
適切に索引付けされている場合、挿入のパフォーマンスは、選択のパフォーマンスよりも影響を受ける可能性があります。PostgreSQL のインデックスには、テーブルの一部またはテーブル内のタプルに対する不変関数の出力にインデックスを付けることができる膨大な数のオプションがあります。また、使用可能であると仮定すると、インデックスのサイズは、テーブルの実際のスキャンよりもはるかにゆっくりと速度に影響します。最大の違いは、ツリーの検索とリストのスキャンです。もちろん、インデックスの使用につながるディスク I/O とメモリのオーバーヘッドは依然として存在するため、大きなインデックスは理論的には十分に機能しません。