Início / dba / Perguntas / 78323
Accepted
gotqn
Asked: 2014-10-04 06:32:41 +0800 CST

Maneira alternativa de compactar NVARCHAR(MAX)?

  • 772

Estou tentando compactar algumas tabelas que possuem NVARCHAR(MAX)campos. Infelizmente, o rowe a pagecompactação não têm o impacto desejado (apenas ~ 100/200 MB salvos para a tabela de 20 GB). Além disso, não consigo aplicar armazenamento de coluna e compactações de arquivamento de armazenamento de coluna porque eles não oferecem suporte à compactação de NVARCHAR(MAX)campos.

Alguém pode dizer se eu tenho alguma alternativa aqui?

Eu também acho que a compressão rowe pagenão tem efeito porque o conteúdo das NVARCHAR(MAX)colunas é único.

sql-server sql-server-2014

2 respostas

  1. Best Answer

    Tanto a compactação de página quanto a de linha não compactam BLOBs .

    Devido ao seu tamanho, os tipos de dados de grande valor às vezes são armazenados separadamente dos dados de linha normais em páginas de finalidade especial. A compactação de dados não está disponível para os dados armazenados separadamente.

    Se você deseja compactar BLOBs, precisa armazená-los VARBINARY(MAX)e aplicar o algoritmo de compactação de fluxo de sua escolha. Por exemplo GZipStream. Existem muitos exemplos de como fazer isso, basta procurar por GZipStream e SQLCLR.

    • 17

  2. Existem (agora) potencialmente duas maneiras de realizar a compactação personalizada:

    1. A partir do SQL Server 2016, existem funções internas para COMPRESS e DECOMPRESS . Essas funções usam o algoritmo GZip.

    2. Use SQLCLR para implementar qualquer algoritmo que você escolher (como @Remus mencionou em sua resposta). Essa opção está disponível em versões anteriores ao SQL Server 2016, desde o SQL Server 2005.

      GZip é uma escolha fácil porque está disponível no .NET e nas bibliotecas suportadas do .NET Framework (o código pode estar em um SAFEAssembly). Ou, se você deseja o GZip, mas não quer lidar com a codificação/implantação, pode usar as funções Util_GZip e Util_GUnzip que estão disponíveis na versão gratuita da biblioteca SQL# SQLCLR (da qual sou o autor).

      Se você decidir usar o GZip, seja você mesmo quem o codifica ou use o SQL#, saiba que o algoritmo usado no .NET para fazer a compactação do GZip mudou para melhor no Framework versão 4.5 (consulte a seção "Comentários" no MSDN página para GZipStream Class ). Isso significa:

      1. Se você estiver usando o SQL Server 2005, 2008 ou 2008 R2 - todos vinculados ao CLR v 2.0, que lida com as versões 2.0, 3.0 e 3.5 do Framework - a alteração feita no Framework versão 4.5 não terá efeito e, infelizmente, você ficará preso com O algoritmo original e chato do .NET.
      2. Se você estiver usando o SQL Server 2012 ou mais recente (até agora 2014 e 2016) -- todos vinculados ao CLR v 4.0 que lida com as versões 4.0, 4.5.x, 4.6 do Framework -- então você pode usar o algoritmo mais novo e melhor. O único requisito é que você tenha atualizado o .NET Framework no servidor que executa o SQL Server para a versão 4.5 ou mais recente.

      No entanto, você não precisa usar o GZip e é livre para implementar qualquer algoritmo semelhante.

    OBSERVE: todos os métodos mencionados acima são mais "soluções alternativas" em vez de substituições reais, mesmo que sejam tecnicamente "maneiras alternativas de compactar dados NVARCHAR(MAX)". A diferença é que com a compactação de dados incorporada -- rowe page-- oferecida pelo SQL Server, a compactação é feita nos bastidores e os dados ainda podem ser usados, lidos e indexados. Mas compactar todos os dados em um VARBINARYsignifica que você está economizando espaço, mas abrindo mão de algumas funcionalidades. É verdade que uma string de 20k não é indexável de qualquer maneira, mas ainda pode ser usada em umWHEREcláusula ou com qualquer função de string. Para fazer qualquer coisa com um valor compactado personalizado, você precisaria descompactá-lo na hora. Ao compactar arquivos binários (PDFs, JPEGs, etc.), isso não é um problema, mas essa questão era específica para NVARCHARdados.

    • 11

relate perguntas