テーブルクラスターをいつ使用するかをどのように決定しますか？さまざまなケースで使用するインデックスとハッシュの2つのタイプがあります。あなたの経験では、テーブルクラスターの導入と使用は成果を上げていますか？
どのテーブルもこのように設定されていない場合、テーブルクラスタを使用するようにテーブルを変更すると、設定が複雑になります。しかし、期待されるパフォーマンスのメリットは、将来のメンテナンス作業で複雑さが増すコストを上回るでしょうか？
テーブルクラスタリングをうまく説明し、優れた実装例を提供するお気に入りのオンラインリファレンスや本はありますか？
//Oracleのヒントを高く評価します。
テーブル クラスタの優れた機能は、異なるテーブルの関連する行を物理的に同じ場所に格納できることです。
これにより、結合のパフォーマンスが桁違いに向上します。ただし、思ったほど頻繁には報われません。
私がそれを使用したのは、2 つのハッシュ結合によって実行される 3 つのテーブルの結合だけでした。時間がかかりすぎました;)。ただし、結合は同じ列にあったため、結合列をキーとするハッシュ テーブル クラスターを使用することができました。これにより、関連するすべての行が一緒に (理想的には、同じデータベース ブロックに) 格納されました。そのことを知っていれば、Oracle は特別な最適化 (「クラスター結合」) を使用して結合を実行できます。
多かれ少なかれ事前に結合されていますが、通常のテーブルのように感じられます (INSERT/SELECT/UPDATE/DELETE の場合)。
一方、「クラスタリング係数」を制御するために主に使用される「単一テーブルクラスタ」があります-クラスタ化されたインデックス（Oracleではインデックス構成テーブルと呼ばれます）と同様のアイデアですが、セカンダリを使用する場合に高いコストを追加しません索引。
クラスタリングについては多くのことを話すことができますが、Oracle クラスターに関するほぼ究極の説明 (長所と短所、いつ使用するか、どのように使用するか) は、Tom Kyte の本「Effective Oracle by Design 」で見つけることができます。また、 asktomを検索することもできます。特定のクラスターの使用例 ( 1、2など)。まだ読んでいない人は、ぜひこの本を読んでみてください。
ここで見つけることができる情報もあります。
しかし、複雑なスキーマ構造を作成する前に常に行うべきことは、試行、テスト、ベンチマークを行い、ニーズに最適なソリューションを 1 つ選択することです:)
お役に立てれば。
私自身はOracleのテーブルクラスターを使用していませんが、そのインデックステーブルクラスターはMSSQLServerのクラスター化インデックスと非常によく似ていることを理解しています。つまり、行データは、クラスター化インデックスのキーによって物理的に編成されます。
これは、ほとんどのクエリが特定の値を持つすべての行を取得する必要がある、（行の総数と比較して）可能な値の数がかなり少ないアクセスの多い列に最適です。このような行はすべて物理的に一緒に格納されるため、ディスクI / O、特にシーク時間が短縮されます。
「適度に小さい」は簡単に定義できませんが、単一のコードの地域内のすべての住所を頻繁に照会する場合は、住所テーブルの郵便番号または郵便番号が妥当と思われます。州/州/準州のコードは、国全体の住所表として選択するには小さすぎる可能性があります。
したがって、可能な値が少ない列（たとえば、性別のM / F）でそれらを使用することは望ましくありません。これは、クラスタリングによって何も購入されず、挿入にコストがかかる可能性があるためです。また、（Oracleのシーケンスからの）「自動番号」代理キー列でクラスタリングを使用することは決してありません。これは、すべての挿入が物理的にそこで行われる必要があるため、テーブルの最後のエクステントに「ホットスポット」を作成するためです。また、クラスター化された順序を維持するためにRDBMSがレコードを物理的に移動する必要があるため、更新される列の値にクラスタリングを適用する必要はありません。