2 つのテーブルがあります。1 つ目は約 1 億行のファクト テーブルです。もう 1 つは、約 100 行しかないディメンション テーブルです。クエリを最適化するために、ファクト テーブルにビットマップ結合インデックスを作成しました。
ただし、ディメンション テーブルにいくつかの行を挿入すると、データベースがハングします。
何が原因か誰か知っていますか?
2 つのテーブルがあります。1 つ目は約 1 億行のファクト テーブルです。もう 1 つは、約 100 行しかないディメンション テーブルです。クエリを最適化するために、ファクト テーブルにビットマップ結合インデックスを作成しました。
ただし、ディメンション テーブルにいくつかの行を挿入すると、データベースがハングします。
何が原因か誰か知っていますか?
ビットマップインデックスはマトリックスであり、個別の値ごとに列があり、インデックス付きテーブルの各レコードに行があります。同じ原則がビットマップ結合インデックスにも当てはまります。DIMENSIONテーブルの個別の値ごとに1つの列があり、FACTテーブルの1つの行があります。
ここから、DIMENSIONテーブルに1つの行を挿入すると、インデックスに1億のエントリが生成されることは明らかです。それには長い時間がかかります。
あなたは「数行」を挿入していると言います。それで、正直なところ、これらすべてのエントリを生成するのに妥当な時間は何だと思いますか?
これはビットマップインデックスのトレードオフです。クエリの時間を大幅に節約できますが、メンテナンスのオーバーヘッドは非常に高くなります。したがって、ビットマップインデックスを展開する前に、慎重に検討する必要があります。これらのコストを改善できる場合もありますが、それは特定の状況によって異なります。
ビットマップ結合インデックスについては、もう1つ覚えておく必要があります。これにより、サーバーがハングするように見える場合もあります。
「ビットマップ結合インデックスを使用する場合、異なるトランザクションによって同時に更新できるテーブルは1つだけです。」
ドキュメントを読む必要があります。 詳細をご覧ください。
ビットマップ インデックスには、多数の行をロードするときに関連するパフォーマンスの低下があります。探している効率を得るには、単にインデックスを使用不可としてマークし、レコードをロードしてから、インデックスを再構築します。話しているデータの量に応じて、読み込み時間が改善されるはずです。