na Twitteru nedávno jsem se zeptal:

používá někdo, koho znám, funkce COMPRESS a DECOMPRESS v T-SQL?

těm, kteří odpověděli kladně, jsem se zeptal:

co vás přimělo rozhodnout se o tom na rozdíl od komprese ROW nebo PAGE?

Joey D ‚ Antoni (blog | Twitter), jeden z mých spoluautorů, mi připomněl, že komprese řádků a stránek nefunguje na datech LOB („velký objekt“). Dave Dustin (Twitter) a Niko Neugebauer (blog | Twitter) uvedli, že z tohoto důvodu konkrétně používají COMPRESS pro LOB data.

změny kódu

použití těchto funkcí vyžaduje změny existujícího kódu, protože při vkládání dat musíte použít funkci COMPRESS. Dave a Niko to udělali tím, že Skryli funkčnost uvnitř zobrazení.

pokud nemůžete provést změny kódu ve vašem prostředí, možná se budete muset uchýlit k kompresi řádků a stránek nebo případně indexům columnstore.

jak to funguje?

Vydáno s SQL Server 2016, COMPRESS využívá algoritmus komprese gzip s otevřeným zdrojovým kódem a může zmenšit použitý prostor až o 90% v závislosti na druhu dotyčných dat. Data jsou uložena jako VARBINARY(MAX) datový typ:

INSERT INTO dbo.Table1 (Col1, Col2) VALUES ('C0001', COMPRESS('<long string goes here>'));

DECOMPRESS se používá k opětovnému přečtení dat:

SELECT Col1, DECOMPRESS(Col2) AS Col2 FROM dbo.Table1 WHERE Col1 = 'C0001';

kde bych to použil?

to je skvělé pro sledování dat LOB, která nemusí být často dotazována, například velké řetězce obsahující JSON a text XML. Jak bylo uvedeno v předchozím příspěvku, datový typ XML nemusí být vhodný pro účely auditu, protože trvale upravuje data, zatímco COMPRESS by byl vhodným mechanismem ukládání, protože data jsou při opětovném čtení úplně stejná.

existují nějaká omezení?

komprimovaná data nelze indexovat, protože jsou uložena jako komprimované bajtové pole. Pokud chcete vytvořit index, můžete použít kompresi řádků nebo stránek a doufat v to nejlepší, nebo použít vypočítaný sloupec obsahující data, která potřebujete ze sloupce, a místo toho indexovat.