Particionamento do SQL Server - o que usar para a chave de partição?

Nunca trabalhei com o particionamento do SQL Server, mas atualmente enfrento o design de um banco de dados para o qual os volumes provavelmente o justificam. O sistema é para cupons. Os cupons devem ser emitidos periodicamente, geralmente a cada seis semanas, embora também haja emissão ad-hoc - por exemplo, para um evento especial. Existem 15 milhões de clientes e, para cada evento de emissão, cada cliente receberá 6 tipos diferentes de cupom, totalizando 90 milhões de ocorrências. Precisamos rastrear os dados de resgate da instância do cupom e mantê-lo por 6 meses, embora normalmente um cupom seja válido apenas por seis semanas. Qualquer solicitação de resgate de um cupom inválido não chegará ao banco de dados, pois será validada pelo PDV até.

Durante um período de seis meses, precisaremos armazenar 360 milhões de linhas na tabela Instância de cupom e até 72 milhões (assumindo uma taxa máxima de resgate de 20%) na tabela de resgate. Tenho a sensação de que esses números são grandes demais para uma única partição?

Minha pergunta é - o que usar como chave de partição? Um candidato óbvio seria por evento de emissão, fornecendo aproximadamente 6 partições. Mas acho que talvez isso daria um tamanho de partição muito grande para permitir o desempenho ideal? Seria possível particionar por duas chaves, por exemplo, por evento de emissão + último dígito do ID do cliente? Então a lógica seria:

If issuance event = 1 and last digit of customer id < 5 then
    Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
    Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
    Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
    Store in partition 4
Etc...

Além disso, não tenho certeza das especificações do servidor de banco de dados que precisaremos. 16gb e 8CPUs serão suficientes? O banco de dados precisa poder retornar um resultado da tabela de instância de cupom, digitada em um valor numérico de código de barras em menos de meio segundo. A solicitação de transação esperada para validar (selecionar) e resgatar (inserir) deve atingir um pico de aproximadamente 3.500 por minuto.

O servidor SQL Server 2008r2 de 64 bits db será provisionado como VM a partir de um host muito poderoso com acesso a uma SAN de alto desempenho e grande capacidade.

Ficaria muito grato por qualquer conselho daqueles que implantaram uma solução do SQL Server para gerenciar volumes semelhantes.

Saudações

Roubar.

As perguntas de especificação do servidor devem ser direcionadas para Serverfault ou DBA.SE.

Para a questão do particionamento, não acho que você precise particionar para isso.

360m linhas é muito, mas não é muito pesado.

Você NÃO sob quaisquer circunstâncias tentar partição com base no último dígito de um campo. Não tenho certeza se isso funcionaria, mas não é SARGable que não seria sustentável.

Se você precisar apenas procurar uma única linha com base em uma chave numérica, o particionamento provavelmente não ajudará.

Se você decidir seguir a rota da partição, lembre-se de que todas as suas consultas precisam ser eficazes para incluir suas chaves de partição, para que o mecanismo saiba qual partição verificar. Caso contrário, ele verificará todos eles e você realmente prejudicará o desempenho.

Você pode particionar em várias chaves se usar uma coluna computada persistente; como outros disseram, no entanto, o particionamento não funciona para todas as situações. Não sei se entendi o seu cenário o suficiente para lhe dar conselhos específicos, mas aqui estão algumas diretrizes gerais:

• O particionamento é útil na leitura de dados quando a chave de particionamento faz parte da instrução SQL, que permite ao otimizador invocar a exclusão de partição. Você precisa ter certeza de que a chave escolhida é útil para a maioria das consultas.

• Um benefício de uma boa estratégia de particionamento é o envelhecimento dos dados; por exemplo, se sua chave de partição é baseada em data (ou seja, o dia do ano) e você deseja remover todos os dados anteriores a uma determinada data, é muito fácil alternar essas partições para uma tabela vazia e truncar.

Você realmente precisa definir seus requisitos um pouco mais claramente. Você mencionou que terá aproximadamente 360 ​​milhões de linhas em 6 meses. Que tal daqui a 2 anos? Você continuará crescendo apenas na taxa em que está crescendo atualmente? Ou existe uma chance de você experimentar um crescimento exponencial. Deseja manter os dados nesta tabela para sempre; ou você deseja arquivar dados regularmente.

O particionamento pode ser usado para arquivamento de dados. Veja o cenário da janela deslizante. Veja este white paper e este .

O particionamento também pode ser usado para gerenciar a fragmentação do índice. Você pode reconstruir / reorganizar partições específicas.

Você também deve considerar as visualizações particionadas em oposição às tabelas particionadas. As visualizações particionadas não exigem licença do SQL Server Enterprise. As visualizações particionadas também permitem executar reconstruções de índice online em uma "partição" específica.

O particionamento também pode ser considerado ao fazer o planejamento de recuperação de desastres. Pode ser usado para recuperação parcial do banco de dados. Por exemplo: você pode ter suas partições antigas em um grupo de arquivos diferente das partições principais / atuais. E então, quando você está se recuperando, recupera o grupo de arquivos primário, o grupo de arquivos em que suas partições atuais residem e, por fim, você pode restaurar os grupos de arquivos nos quais as partições antigas residem. Isso pode reduzir a quantidade de tempo que seu aplicativo precisa ser desativado.

Confira este ótimo vídeo de Kimberly Tripp sobre particionamento .

A menos que você faça o particionamento por causa do arquivamento de dados antigos, está fazendo isso pelo motivo errado e não deve fazê-lo.