パーティション分割とインデックス
私はデータベースに非常に慣れていないので、私の質問が非常に基本的なものであるとすみません...
とにかく、私は大量のデータ（現在5億行、将来的には2倍になる可能性がある）のようなテーブルを作成しています。ここで、このテーブルのデータにすばやくアクセスする方法が必要なので、パーティションとインデックスを調査しています。ただし、インデックスではなくパーティションを作成する場合に混乱します。パーティション分割またはインデックス作成の合理的な候補のように見える3つの列があります。
- 時間（日または週、データは4か月の期間）
- 顧客「トークン」：ユーザーIDの最後の2桁
- クライアントID（通常、データセットには5〜20のクライアントがあります）
このテーブルに対してフューチャーセレクトを実行する場合、クライアントIDでフィルタリングすると同時に、サンプリングを実行したい場合があります（「トークン」変数で実行したい）。時間変数でフィルタリングすることもあります。
だから、私の質問はこれです：テーブルをどのように整理すべきですか？クライアントとトークンでパーティション化し、時間通りにインデックスを作成する必要がありますか？または、クライアントでパーティションを作成し、時間とトークンでインデックスを作成しますか？さらに重要なこととして、あなたが推奨する戦略の背後にある論理は何ですか？
また、テーブルを作成した後、さらにデータ（特に同じ日付/トークン範囲の新しいクライアント）を追加すると、インデックスが壊れますか？インデックスの再作成は比較的簡単ですか？
ご協力ありがとうございます。さらに情報が必要な場合はお知らせください。
簡単に言うと、インデックスを使用すると、テーブルの小さな割合に高速にアクセスできます。これは、データセグメント内の多くのブロック全体に散在するデータにアクセスするためです。そのため、探している行が少数のブロックにクラスター化されていない限り、これらの単一ブロックすべてにアクセスするための総コストは、ただスキャンするよりも高くなります。テーブル。
絶対的には、テーブルの行の20％にアクセスしている場合、インデックスからメリットを得ることができますが、1-5％が効果的な制限である可能性が高くなります。
より多くの割合、たとえば行の10％に効率的にアクセスしたい場合、パーティション化スキームを使用して「クエリ可能な」グループをパーティションに分離できれば、非常に迅速にクエリを実行できます。テーブルの行の1％にアクセスしている場合でも、フルパーティションスキャンでそれらの行のみを保持するパーティションからクエリが行を取得できる場合は、インデックスを介してそれらにアクセスするよりも高速になります（約100分の1）全テーブルスキャンを実行する時間（並列クエリを無視）。
したがって、クエリでクライアントIDに述語が頻繁に含まれる場合は、その上でパーティション分割を行います-リストパーティション分割をお勧めします。日付の範囲についてもクエリを実行する場合は、時間列の範囲分割を検討してください。
したがって、範囲リストまたはリスト範囲によってパーティションを合成できます。古いデータを簡単に削除したい場合は、範囲リストの方が良いかもしれませんが、それらの中から選択することがたくさんあるかどうかはわかりません。
トークンは、インデックスの候補として適しているようです。インデックスは自己維持型であり、データを変更してもインデックスは無効になりません。明らかに、それらを維持するためのオーバーヘッドがありますが、データは通常、変更されるよりも頻繁にクエリされるため、バランスを取るために、「最初にインデックスを付け、後で質問する」傾向があります。