web-dev-qa-db-ja.com

列ストアインデックスが行グループ全体を埋めないのはなぜですか？

[vColumnstoreDensity]を使用して、列ストアインデックスの状態を監視しています。

奇妙に見えるインデックスが1つあることに気づきました。

私の理解では、列ストアインデックスは、次の行グループを開始する前に行グループを埋めます。最高のインデックスパフォーマンスを得るには、行グループが充実している方がよいでしょう。

以上のことをすべて言っても、理解に苦労しているテーブルが1つあります。最大のリソースクラスを使用してインデックスを再構築した後でも（ビルドプロセスに可能な最大量のメモリを提供するため）、[vColumnstoreDensity]ビューには、このインデックスが部分的に完全な行グループの多くに分散していることが示されます。

COMPRESSED_rowgroup_count

4936

COMPRESSED_rowgroup_rows

2693512978

COMPRESSED_rowgroup_rows_MIN

468

COMPRESSED_rowgroup_rows_MAX

739443

COMPRESSED_rowgroup_rows_AVG

545687

編集：

これは、クラスター化された列ストアインデックスです。

indexcolumnstoreazure-sql-data-warehouse
1
Neil P

列ストアグループが「カット」されているときに発生する拡張イベントがあります。イベントは column_store_index_build_process_segment 。このイベントには「トリム」の理由があり、2つの考えられるトリムの原因を探す必要があります。

  • インデックスビルドにセグメントをビルドするのに十分なメモリがない場合は、メモリ（あなたの場合はありそうにありません）。
  • ディクショナリサイズ（考えられる原因）。これは、列セグメントのデータのエンコードに使用されるディクショナリが最大サイズ（16Mb）に達した場合に発生します。

もちろん、このイベントをキャプチャするには、インデックスのビルド中にXEセッションを設定する必要があります（リンクされた記事にその方法が示されています）。

また、ビルド後のアーティファクト、特にディクショナリを調べて、小さなセグメントに関連付けられているセカンダリディクショナリがすでにフルサイズ（16Mb）になっているかどうかを確認することもできます。これは、トリムの考えられる原因が完全な辞書であることを示しています。

2
Remus Rusanu