Início / dba / Perguntas / 280157
Accepted
Avi
Asked: 2020-11-24 03:21:28 +0800 CST

Índice columnstore clusterizado em tabelas pequenas

  • 772

As tabelas indexadas de armazenamento de colunas agrupadas em geral são úteis para tabelas grandes. Idealmente com milhões de linhas. E também útil com consultas, que selecionam apenas o subconjunto de colunas disponíveis em tais tabelas.

O que acontece se quebrarmos essas duas "regras"/melhores práticas?

  1. Como ter uma tabela indexada de armazenamento de colunas em cluster que armazenará apenas alguns milhares ou centenas de milhares de linhas no máximo.
  2. E executando consultas naquela tabela de armazenamento de colunas em cluster onde todas as colunas são necessárias.

Meus testes não revelam nenhuma degradação de desempenho em comparação com a tabela de índice clusterizado armazenada em linha. O que é ótimo no nosso caso.

Existe algum efeito de "longo prazo" que infrinja essas duas regras? Ou alguma armadilha escondida que ainda não apareceu?

Contexto por que é necessário: Eu projetei um modelo de banco de dados que será usado para muitas instâncias de bancos de dados de fornecedores diferentes. O esquema permanece o mesmo em todos os bancos de dados, mas diferentes fornecedores têm diferentes quantidades de dados. Assim, alguns pequenos fornecedores podem acabar com uma pequena quantidade de dados (<1.000.000) em suas tabelas. Não posso me permitir manter dois bancos de dados diferentes para o modelo de armazenamento de linha e armazenamento de coluna.

columnstore sql-server-2017

2 respostas

  1. O índice Columnstore tem uma grande vantagem no tamanho dos dados compactados. O objetivo geral do índice Columnstore é ler rapidamente um monte de dados devido à sua compactação.

    insira a descrição da imagem aqui

    CCI é índice agrupado de Columnstore, agrupado é índice agrupado

    O Columnstore Index compacta o tamanho dos dados de 4 MB para 2 MB.

    Podemos olhar para o desempenho em duas tabelas e três partes.

    A primeira é a SELECToperação mínima:

    SELECT * FROM Users_CCI WITH(INDEX=CCI_Users) WHERE Id=12333

    insira a descrição da imagem aqui

    insira a descrição da imagem aqui

    SELECT * FROM Users_Clustered WHERE Id=12333

    insira a descrição da imagem aqui

    insira a descrição da imagem aqui

    Resultado : Há uma Columnstore Scanestimativa aqui e errada. Além disso, a diferença de leitura lógica. Você pode dizer que não importa para você, mas, se você usar uma consulta SELECT mínima, provavelmente usará milhares de vezes. E isso afetará o desempenho total.

    A segunda é a UPDATEoperação mínima:

    UPDATE Users_CCI SET Age=10 WHERE  Id=2

    insira a descrição da imagem aqui

    UPDATE Users_Clustered SET Age=10 WHERE  Id=2

    insira a descrição da imagem aqui

    Resultado : Existem diferenças de leitura, CPU e tempo, como podemos ver.

    A terceira é a REBUILDoperação:

    USE [StackOverflow2013]
GO
ALTER INDEX [CCI_Users] ON [dbo].[Users_CCI] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = COLUMNSTORE)
GO
USE [StackOverflow2013]
GO
ALTER INDEX [PK_Users_Clustered_Id] ON [dbo].[Users_Clustered] REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

UPDATE Users_CCI SET Age=10 
UPDATE Users_Clustered SET Age=10

    Se eu reconstruir e atualizar todas as linhas para fragmentação de índice, verei um índice de armazenamento de colunas clusterizado mais fragmentado do que o índice clusterizado. E eu não mostrei, mas o Clustered Columnstore Indexprocesso de reconstrução produz log de transações mais de Clustered Index.

    insira a descrição da imagem aqui

    insira a descrição da imagem aqui

    Como diz o documento

    • Mais de 10% das operações na tabela são atualizações e exclusões. Um grande número de atualizações e exclusões causa fragmentação. A fragmentação afeta as taxas de compactação e o desempenho da consulta até que você execute uma operação chamada reorganizar que força todos os dados no armazenamento de colunas e remove a fragmentação. Para obter mais informações, consulte Minimizando a fragmentação do índice no índice columnstore.

    Se você tiver uma tabela pequena, não precisará indexar Columnstore.

    • 4
  2. Best Answer

    Para @YunusUYANIK apontar para as possíveis quedas de projetar seu esquema atendendo apenas a um lado, por que não criar índices rowstore e columnstore em sua tabela atendendo adequadamente a ambos os cenários? Claro que você pode acabar indexando os mesmos campos nos dois sentidos, mas a principal desvantagem seria apenas o aumento do uso do espaço de armazenamento, que geralmente é muito menos preocupante ao planejar o desempenho.

    Dependerá do seu esquema e da quantidade de dados em suas tabelas para cada fornecedor, portanto, você terá que testar para garantir que o design dos índices esteja sendo usado nas consultas apropriadas para as diferentes quantidades de dados com base nos predicados do fornecedor . Na pior das hipóteses, você pode ter que usar dicas de índice às vezes também, mas acho que se você projetar os dois tipos de índices corretamente, isso não é muito provável.

    • 3

relate perguntas