Twitterで最近、私は尋ねました:
私が知っている人は、T-SQLの
COMPRESS
とDECOMPRESS
機能を使用していますか?
肯定的に答えた人に、私は尋ねました:
ROW
やPAGE
圧縮とは対照的に、これを決定したのは何ですか?私の共著者の1人であるJoey D’Antoni(ブログ|Twitter)は、行とページの圧縮がLOB(「ラージオブジェクト」)データでは機能しないことを思い出しました。 Dave Dustin氏(Twitter)とniko Neugebauer氏(ブログ|Twitter)は、この理由から、LOBデータにCOMPRESS
を特別に使用していると述べました。コードの変更
これらの関数を使用するには、データを挿入するときに
COMPRESS
関数を使用する必要があるため、既存のコードを変更する必要があります。 DaveとNikoは、views内の機能を隠すことによってそれを行いました。環境にコードを変更できない場合は、行とページの圧縮、または場合によっては列ストアインデックスに頼らなければならない可能性があります。
どのように動作しますか?
SQL Server2016でリリースされた
COMPRESS
は、オープンソースのgzip圧縮アルゴリズムを活用しており、問題のデータの種類に応じて使用されるスペースを90%も削減できます。 データはVARBINARY(MAX)
データ型として格納されます:
INSERT INTO dbo.Table1 (Col1, Col2) VALUES ('C0001', COMPRESS('<long string goes here>'));
DECOMPRESS
データを再度読み出すのに使用されています:
SELECT Col1, DECOMPRESS(Col2) AS Col2 FROM dbo.Table1 WHERE Col1 = 'C0001';
私はそれをどこで使うでしょうか?
これは、JSONやXMLテキストを含む大きな文字列など、頻繁に照会する必要のないLOBデータを追跡するのに最適です。 以前の記事で説明したように、XMLデータ型はデータを永続的に変更するため、監査目的には適していない可能性がありますが、
COMPRESS
はデータを再度読み出すとまったく同じであるため、適切なストレージメカニズムになります。何か制限はありますか?
圧縮されたバイト配列として格納されているため、圧縮されたデータにインデックスを付けることはできません。 インデックスを作成する場合は、行またはページの圧縮を使用して最適なものを期待するか、列から必要なデータを含む計算列を使用して、代わりにそ