SQL Serverのデータ圧縮は、読み取り専用のデータベースに非常に適していますか？

私が読んだSQL Serverのデータ圧縮に関するいくつかの文献では、書き込みコストが通常必要なものの約4倍に増加すると述べています。また、これがデータ圧縮の主な欠点であることを暗示しているようです。読み取り専用アーカイブデータベースの場合、100％埋められたページのデータ圧縮を使用すると、パフォーマンスが（ほとんど例外なく）向上することを強く意味します。

1. 上記の説明は正しいですか？

2. データ圧縮とそれ以外の場合の主な「違い」は何ですか（読み取り用）

   • 「CPU + x％」？
   • 「IO -y％」？
   • ページ分割発生？
   • tempdbの使用法？
   • RAM使用量？
3. そして書くために？

この質問のために、コンテキストを大きな（> 1TB）データベースのページレベルの圧縮に制限できますが、追加のコメントはいつでも歓迎します。

参照：

SQL Serverストレージエンジンブログ（DWシナリオは圧縮が非常に有利であることを示しています）
データ圧縮：戦略、容量計画、およびベストプラクティス

圧縮対象を決定するためのより詳細なアプローチには、各テーブルとインデックスのワークロード特性の分析が含まれます。次の2つの指標に基づいています。

U：特定のテーブル、インデックス、またはパーティションに対する更新操作の、そのオブジェクトに対する合計操作に対する割合。Uの値が低い（つまり、テーブル、インデックス、またはパーティションが頻繁に更新されない）ほど、ページ圧縮の候補として適しています。
S：そのオブジェクトに対する操作の合計に対する、テーブル、インデックス、またはパーティションに対するスキャン操作の割合。Sの値が大きいほど（つまり、テーブル、インデックス、またはパーティションがほとんどスキャンされる）、ページ圧縮の候補として適しています。

上記の両方は、DWスタイルのデータベース（読み取り集中型/排他型のビッグデータ操作）のページ圧縮を推奨する方向に明らかに偏っています。

1〜2年前のハードウェアでの自分の実験からの私の2セント：

ページ圧縮されたテーブル（〜80行/ページ）での読み取り専用操作（DWスタイルのスキャン、ソートなど）は、圧縮サイズを約3倍に削減すると、不均衡になることがわかりました。

つまり、いずれにしてもテーブルがメモリに収まる場合、ページ圧縮は、データサイズが3倍以上縮小した場合にのみ、パフォーマンスを向上させます。メモリ内のスキャンするページ数は少なくなりますが、各ページのスキャンに時間がかかります。

私は推測するあなたの計画は、ネストされたループをしているとシーク重いの場合は、あなたの走行距離は異なる場合があります。特に、これはハードウェアに依存します（外部のNUMAノードアクセスペナルティ、メモリ速度など）。

上記は、自分のハードウェア（Dell Poweredge 910以降）で自分のクエリを使用して自分で実行したテストに基づいた、大まかな経験則にすぎません。それはええ福音ではありません！

編集：昨日、Thomas Kejserの優れたSQLBits XIプレゼンテーションがビデオとして公開されました。この議論にかなり関連しており、ページ圧縮のCPUコストの「醜い」面を示しています。更新は4倍遅くなり、ロックはかなり長く保持されます。

ただし、ThomasはFusionIOストレージを使用しており、ページ圧縮に「ちょうど」適格なだけのテーブルを選びました。ストレージが一般的なSAN上にあり、データが3x-4xで圧縮されて使用されている場合、状況はそれほど劇的ではありませんでした。

データウェアハウス環境からいくつかの単語を追加できます。

30ミリオンの行（18 GB）のテストテーブルに圧縮（私の場合はPAGE）を実装すると、テーブルのサイズが18 GBから3 GBに減少します。（確かにストレージ効率）しかし、読み込み時間（書き込み）を22分から36分に増やします。

したがって、読み取りまたは読み取りとメモリへのデータの配置の場合、これは適切なソリューションになる可能性がありますが、毎日のデータロードの場合、パフォーマンスの低下を引き起こす可能性があります。