Antes do SQL Server 2016, o particionamento de índices columnstore era considerado praticamente obrigatório porque os bloqueios tomados neles durante inserções/atualizações/exclusões eram extremos. No entanto, a partir do SQL Server 2016, os bloqueios tomados em índices columnstore são muito menos intensos . Por que, então, ainda é considerado uma prática recomendada particioná-los?
Estou ciente do truque onde você pode melhorar o alinhamento trocando uma partição, construindo um índice rowstore clusterizado, substituindo esse índice por columnstore e então trocando a partição novamente. No entanto, essa é apenas uma otimização de desempenho moderada que raramente sobrevive a uma reconstrução e foi amplamente tornada redundante pelos recursos de ordenação do SQL Server 2022 .
Os columnstores já são "particionados" por rowgroup.
O particionamento pode lhe dar um nível extra de eliminação além do particionamento implícito de rowgroup. Isso é mais importante do que o normal porque os columnstores não suportam seeks diretamente.
Ele fornece um delta store por partição, em vez de um para todas as linhas na tabela. Se houver atualizações significativas, isso pode ser útil para reter os benefícios da eliminação. Você precisa manter a manutenção para garantir que o número de linhas em delta stores não saia do controle (porque há mais delas).
A manutenção do índice pode ser realizada por partição.
Você pode escolher a compactação de arquivo para partições usadas com menos frequência.
Se o uso proposto não se beneficiar do particionamento, não o utilize.
Perguntas e respostas relacionadas: Quantas partições devo fazer para minhas tabelas de índice columnstore clusterizadas? Devo particionar as tabelas rowstore também?
Documentação: Índices Columnstore - Orientação de design
Por fim, não fique muito animado com o 'ordered columnstore'.