Estou desenvolvendo um projeto de banco de dados no SQL Server e estou pensando se usar o índice columnstore é uma boa ideia.
O projeto consiste em uma tabela (A) que conterá um grande número de linhas, com muitos valores repetidos para uma coluna. Todos os dias, um pacote de novas linhas será adicionado à tabela, com um "DateId" para cada pacote.
Depois disso, precisarei atualizar uma tabela diferente (B) juntando com A e filtrando A para o "DateId" e outras colunas.
Exemplo em SQL:
CREATE TABLE A (
[Id] [BIGINT] IDENTITY(1,1) NOT NULL,
[DateId] [INT] NOT NULL,
[B_Id] [BIGINT] NOT NULL,
-- other columns...
INDEX cci_A CLUSTERED COLUMNSTORE
)
CREATE TABLE B (
[Id] [BIGINT] IDENTITY(1,1) NOT NULL,
-- other columns...
INDEX cci_B CLUSTERED COLUMNSTORE
)
UPDATE B
SET ...
FROM A
INNER JOIN B ON A.B_Id = B.Id
WHERE A.DateId = @myDateId
O columnstore é uma boa escolha neste caso?
Modificar uma linha fará com que a linha antiga seja sinalizada como "excluída" (mas ainda está no índice de armazenamento de colunas) e a nova linha será adicionada ao deltastore (armazenamento baseado em linha que será compactado quando atingir cerca de 1 milhão linhas). Então, como você pode imaginar, muitas atualizações irão, até certo ponto, degradar seu índice columnstore ao longo do tempo. É claro que você pode fazer a manutenção do índice, mas um índice columnstore em B pode não ser a melhor escolha ...