A compactação de dados do SQL Server é categoricamente boa para bancos de dados somente leitura?

Alguma literatura sobre compactação de dados do SQL Server que li afirma que o custo de gravação aumenta para cerca de quatro vezes o que seria normalmente necessário. Também parece implicar que essa é a principal desvantagem da compactação de dados, o que implica fortemente que, para um banco de dados de arquivo somente leitura, o desempenho (com poucas exceções) será aprimorado pelo uso da compactação de dados de páginas 100% preenchidas.

As afirmações acima são verdadeiras?
Quais são as principais "variações" entre a compactação de dados e outras formas (para leitura)
- "CPU + x%"?
- "IO -y%"?
- ocorrência de divisão de página?
- uso do tempdb?
- Uso de RAM?
E para escrever?

Para os fins desta pergunta, você pode limitar o contexto à compactação no nível de PAGE de um grande banco de dados (> 1 TB) , mas comentários adicionais são sempre bem-vindos.

Referências:

Blog do SQL Server Storage Engine (O cenário DW mostra que a compactação é muito vantajosa)
Compactação de dados: estratégia, planejamento de capacidade e práticas recomendadas

Uma abordagem mais detalhada para decidir o que compactar envolve a análise das características da carga de trabalho para cada tabela e índice. É baseado nas duas métricas a seguir:

U: a porcentagem de operações de atualização em uma tabela, índice ou partição específica, em relação ao total de operações nesse objeto. Quanto menor o valor de U (ou seja, a tabela, o índice ou a partição não é atualizada com freqüência), melhor candidato é para a compactação de página.
S: A porcentagem de operações de varredura em uma tabela, índice ou partição, em relação ao total de operações nesse objeto. Quanto maior o valor de S (ou seja, a tabela, o índice ou a partição é mais varrida), melhor candidato é para a compactação de página.

Ambas as opções acima são comprovadamente tendenciosas no sentido de recomendar a compactação de página para bancos de dados no estilo DW (operações de leitura intensiva / exclusiva / big data).

— 孔夫子
fonte

Que literatura especificamente? Sempre haverá sobrecarga da CPU para compactação / descompactação, mas, como nas leituras, você também está gravando em um número menor de páginas. Na verdade, eu acho que o lado de gravação se beneficiaria ainda mais do que o lado de leitura, pois o lado de leitura geralmente terá as páginas compactadas armazenadas na memória (isso nem sempre é, mas o melhor é o caso, dependendo do tamanho dos dados e da memória alocada).

— Aaron Bertrand

Vai ser muito difícil fornecer qualquer uma das métricas que você está solicitando, porque depende totalmente da natureza dos dados e da capacidade de compactá-los (e isso também será diferente dependendo da linha x da página). ) Algumas pessoas relataram até 90% de taxa de compactação, o que afetará o uso da memória (de maneira positiva) e a CPU para realizar essa compactação. Esse papel reduz a sobrecarga da CPU em 10% para compactação de linha e maior para página . O que você observa pode ser bem diferente.

— Aaron Bertrand

Para um banco de dados de arquivo somente leitura, acho que a pergunta seria se ele pode caber na memória. Se tudo puder caber na memória, depois de carregado no buffer pool, não haverá benefício real em compactá-lo. Se, no entanto, nem tudo puder caber na memória, você ainda poderá obter algum benefício em trocar menos páginas dentro e fora do cache, mesmo que haja trabalho realizado descompactando-o.

— Aaron Bertrand

Nenhum dos links que você adicionou parece mencionar essa penalidade de 4x por escrito. Você se lembra onde você pegou isso? Gostaria de ver o contexto.

— Aaron Bertrand

Bem, se você não pode ajustar os dados na memória, esse cenário é discutível, certo? :-)

— Aaron Bertrand

Respostas:

Apenas meus 2 centavos de minhas próprias experiências em hardware de 1 a 2 anos:

Operações somente leitura (varreduras no estilo DW, classificações etc.) em tabelas compactadas de página (~ 80 linhas / página) que eu encontrei no ponto de equilíbrio na redução do tamanho da compactação de ~ 3x.

Ou seja, se as tabelas caberem na memória de qualquer maneira, a compactação de página somente beneficia o desempenho se o tamanho dos dados tiver diminuído em mais de 3x. Você digitaliza menos páginas na memória, mas leva mais tempo para digitalizar cada página.

Eu acho que sua milhagem pode variar se seus planos são aninhados e pesados. Entre outros, isso também seria dependente de hardware (penalidades de acesso ao nó NUMA externo, velocidade da memória etc.).

A descrição acima é apenas uma regra prática que eu sigo, com base em meus próprios testes, usando minhas próprias consultas em meu próprio hardware (Dell Poweredge 910 e mais recente). Não é evangelho hein!

Edit: Ontem a excelente apresentação de Thomas Kejser do SQLBits XI foi disponibilizada como um vídeo. Bastante relevante para esta discussão, mostra a cara 'feia' do custo da CPU para compactação de páginas - atualizações lentas em 4x, bloqueios mantidos por um pouco mais de tempo.

No entanto , Thomas está usando o armazenamento FusionIO e ele escolheu uma tabela que é apenas 'apenas' qualificada para compactação de página. Se o armazenamento estivesse em uma SAN típica e os dados usados fossem compactados em 3x-4x, a imagem poderia ter sido menos dramática.

— John Alan
fonte

Esse pode ser o hardware antigo? Em um novo hardware, SSD vazio Para armazenamento, acho que os núcleos não conseguem acompanhar os discos facilmente. Eu normalmente acho que o benefício começaria MUITO mais fácil - uma redução de 50% no IO vale a pena quando não há tantas mudanças.

— TomTom

TomTom, Storage não entra em jogo para esses números. A comparação é entre tabelas não compactadas na memória e tabelas compactadas na memória.

— John Alan

Nunca vi um DWH que fosse bom o suficiente para memória. Seriamente. Você voltará ao disco.

— TomTom

Sim, é claro que você ocasionalmente retornará ao disco - a leitura no disco é onde a compactação de página quase sempre tem uma vantagem (assumindo que os dados sejam compactáveis o suficiente!). Mas se a sua carga de trabalho carregar do disco uma vez e depois manipular tudo na memória pelo resto do dia - quanto peso você daria à leitura do disco e quanto às operações na memória?

— John Alan

Acabei de encontrar uma apresentação relevante de slideseck do SQLBits 2013 por Thomas Kejser: slideshare.net/fusionio/…

— John Alan

Posso adicionar algumas palavras do meu ambiente de Data Warehouse.

A implementação de compactação (PAGE no meu caso) em uma tabela de teste com 30 milhões de linhas (18 GB) reduz o tamanho da tabela de 18 GB para 3 GB! (eficiência de armazenamento, com certeza), mas aumente o tempo de carregamento (gravação) de 22 para 36 minutos.

Portanto, para ler ou ler e colocar os dados na memória, pode ser uma boa solução, mas para o carregamento diário de dados, isso pode causar um rebaixamento do desempenho.

— Tomasz Wieczorkowski
fonte