SQL Serverのデータ圧縮は、読み取り専用のデータベースに適していますか？
私が読んだSQL Serverのデータ圧縮に関するいくつかの文献では、書き込みコストが通常必要なものの約4倍に増加すると述べています。また、これがデータ圧縮の主な欠点であることを暗示しているようです。読み取り専用アーカイブデータベースの場合、100％埋められたページのデータ圧縮を使用すると、パフォーマンスが（ほとんど例外なく）向上することを強く意味します。
- 上記の説明は正しいですか？
データ圧縮とそれ以外の場合の主な「違い」は何ですか（読み取り用）
- 「CPU + x％」？
- 「IO -y％」？
- ページ分割発生？
- tempdbの使用法？
- RAM使用量？
- そして書くために？
この質問の目的のために、大きな（> 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分に増やします。
そのため、読み取りまたは読み取りとメモリへのデータの配置の場合は適切なソリューションになる可能性がありますが、毎日のデータロードの場合はパフォーマンスの低下を引き起こす可能性があります。