【3分で流し読み】SQL Server 列ストアインデックスの遅延圧縮オプションを理解する

こんばんは。今回は、SQL Serverの列ストアインデックスの遅延圧縮オプションについて少し調べたので、分かったことをメモしておこうと思います。

それではまいります。

列ストアインデックスの遅延圧縮オプションとは

列ストア インデックスの新機能 – SQL Server | Microsoft Docs

と公式ドキュメントもあるのですが、以下の公式ブログに分かりやすい解説がありましたので、こちらを読み解いた方が理解が深まると思います。以下、概要を箇条書き。

Real-Time Operational Analytics: Compression Delay Option for Nonclustered Columnstore Index (NCCI) | Microsoft Docs

  • SQL Server 2016で追加された列ストアインデックスのオプション
  • リアルタイム運用分析へのトランザクション ワークロードの影響を最小限に抑えるための機能
  • 「アクティブな」行をデルタ行グループに保持し、指定された遅延時間後にのみ、これらの行を圧縮行グループに移行させる
  • 行をデルタ行グループに長く保持することで、NCCI のメンテナンスオーバーヘッドを削減できる

どういうことか。列ストアインデックスは通常以下のような内部動作となっている。

  • 圧縮された行が削除された場合、物理削除されず、論理削除となる
  • また、圧縮された行が更新されると、その行は論理削除され、デルタ行グループに新しい行が再挿入される
  • 圧縮された行グループがメモリに読み込まれると、ディスクストレージとメモリを消費し続ける
  • 削除された行は、クエリ結果を返す前にフィルタリングされるため、論理削除された行が多くなるとクエリパフォーマンスが低下する(断片化)
  • 極端な例として、圧縮された行グループの合計サイズが50GBで、50%の行が削除されたとすると、25GBのストレージと同数のメモリを浪費していることになる

この断片化をどう防ぐか。

  • SQL Server 2016では、インデックスの再構成(REORGANIZE)を行うことで論理削除された行を物理削除することができるが、それでも一度圧縮された行グループを(メモリ上に?)読み込んだ上で削除し、再び圧縮する必要がある
  • 一方、削除される行がデルタ行グループにあった場合、断片化を起こすことなく、直接削除される

後者をうまく利用するのが圧縮遅延オプション。

  • 例えば、トランザクション処理の一環として、行が15分ごとに10回更新され、その後、休止状態になる場合を考える。また、行は10分ごとに圧縮されるとする。このパターンでは、同じ行を10回圧縮することになり、削除された行のオーバーヘッドが発生する
  • ここで、NCCIにデルタ行グループの行を少なくとも150分間保持するよう指示できれば、デルタ行グループの行を更新することができ、圧縮行グループで更新するよりもはるかに安価に行を更新できる
  • 圧縮遅延を使用すると、一連の行がデルタ行グループに留まる時間を制御できる。
  • デフォルト値は 0 分
  • 圧縮遅延オプションを追加すると、デルタ行グループの数が多くなる。たとえば、トランザクションが10分ごとに100万行を挿入し、圧縮遅延が150分の場合、サイズ(100万、200万、400万、800万)の4つのデルタ行グループが存在することになる
  • デルタ行グループを圧縮するスレッドが遅れた場合、さらに増える可能性がある。注意点として、圧縮遅延時間はデルタ行グループがCLOSEDになった時点を基準に計算される。例えば、デルタ行グループが午前8時に閉じられた場合、圧縮遅延が150分に設定されていると仮定すると、午前10時30分に圧縮の対象となる

利用方法

CREATE COLUMNSTORE INDEX (Transact-SQL) – SQL Server | Microsoft Docs

こんな感じで列ストアインデックス作成時に指定する。

CREATE CLUSTERED COLUMNSTORE INDEX cci ON Sales.OrderLines
WITH ( COMPRESSION_DELAY = 10 MINUTES );

パフォーマンス

以下の公式ブログで言及されています。

Real-Time Operational Analytics: Compression Delay option with NCCI and the performance | Microsoft Docs

トランザクションの処理速度を15%、利用するストレージ容量を30%、分析クエリの処理速度を20%以上改善できた、ということが書いています。

ベストプラクティス

Real-Time Operational Analytics: Compression Delay Option for Nonclustered Columnstore Index (NCCI) | Microsoft Docs

遅延圧縮オプションは以下のシナリオで有効化することを検討する。

  • インサート/クエリーのワークロード:ワークロードが主にデータのインサートとクエリである場合、デフォルトのCOMPRESSION_DELAYである0が推奨される。このようなワークロードの例としては、(a)従来の DW ワークロード(b)Web アプリケーションのクリックパターンを分析する必要がある場合のクリックストリーム分析などがある
  • OLTP ワークロード:ワークロードが重いDMLの場合(すなわち、重いUpdate、Delete、Insert の組み合わせ)、列ストアインデックスが断片化することがある。最近圧縮された行グループの10%以上の行が削除されている場合、COMPRESSION_DELAYオプションを使用して、行が圧縮の対象となるまでの時間を遅らせることができる。たとえば、ワークロードで新しく挿入された行が60分間「ホット」な状態(つまり、複数回更新される)である場合、COMPRESSION_DELAYを60に選択する

以上、遅延圧縮オプションについての簡単なまとめでした。取り急ぎ翻訳メインでしたが、使っていくなかで分かったこともまたアップデートしていきたいと思います。

おしまい

この記事を気に入っていただけたらシェアをお願いします!

コメントを残す

メールアドレスが公開されることはありません。

ABOUT US
Yuu113
初めまして。ゆうたろうと申します。 兵庫県出身、東京でシステムエンジニアをしております。現在は主にデータ分析、機械学習を活用してビジネスモデリングに取り組んでいます。 日々学んだことや経験したことを整理していきたいと思い、ブログを始めました。旅行、カメラ、IT技術、江戸文化が大好きですので、これらについても記事にしていきたいと思っています。