Digamos que uma tabela armazene dados granulares sobre algum evento. Tem a data do evento, uma dimensão de tipo com cerca de 30 mil tipos e uma dimensão de categoria com cerca de 100 categorias, além de alguns dados numéricos.
Em média, são 15 milhões de transações por dia. Mais de 5 bilhões por ano, mais de 60G por década. Isso não é big data, mas é muito.
Quantas linhas uma tabela do SQL Server 2012 pode conter?
Obviamente, os dados mais antigos são usados com menos frequência e são candidatos a serem particionados em várias tabelas no mesmo banco de dados. Mas quando esse particionamento deve começar a acontecer? 1 mesa por ano? 5 anos?
Informações adicionais coletadas dos comentários:
Considere: tenho armazenamento suficiente para armazenar 30 bilhões de registros desse evento. Se cada registro de evento exigir 1 KB, tenho 30 TB nessa tabela e armazenamento suficiente para isso (e para o log). Seu PK é bigint.
O que você acha de ter uma tabela com dados históricos e outra tabela com dados mais recentes? Ao invés de um evento transacional, a tabela possui um catálogo, clientes, por exemplo. Todos os dias o catálogo do OLTP é copiado para o DW. Assim eu teria uma tabela com os dados do histórico e outra tabela com os últimos registros.
No design que uso, o ETL alimenta a tabela de histórico, então uso row_number() para pegar o último registro de cada entidade por seu NK. É muito caro para rodar, mas desta forma mantenho entidades que existiam no passado e não estão mais no OLTP.
Conforme declarado na página do MSDN para especificações de capacidade máxima para SQL Server (para SQL Server 2012):
"Linhas por tabela = Limitada pelo armazenamento disponível" (o mesmo para plataformas de 32 bits e 64 bits)
Tudo isso depende das necessidades do sistema. Não há necessidade inerente de particionar, na verdade, apenas com base na questão do desempenho. O particionamento destina-se principalmente como um meio de gerenciar mais facilmente a entrada ou saída de grandes quantidades de dados em uma tabela, o mais rápido possível e causando o mínimo de contenção possível. Se o desejo era apenas auxiliar no desempenho da consulta, talvez comece a TESTAR em torno de 1 bilhão de linhas, mas mesmo assim, se você tiver um bom modelo de dados e uma boa indexação, provavelmente nem precisará se preocupar com isso. Além disso, índices filtrados e até mesmo estatísticas filtradas provavelmente seriam suficientes para muitos casos em que as pessoas escolhem implementar o particionamento de tabelas (se a intenção for puramente relacionada ao desempenho).
Mas se sua necessidade é remover rapidamente um grande bloco de linhas, talvez para esgotar os dados mais antigos, o particionamento da tabela ajudará, pois você pode remover os
SWITCHdados "antigos". E neste nível não é uma questão de linhas, mas uma questão de quanto tempo você deseja administrar. Se você deseja trocar dados mensalmente, faça partições mensais. Se você deseja envelhecer os dados anualmente, tente partições anuais.ATUALIZAR
Não sei por que não mencionei isso antes, mas você deve dar uma olhada em Partitioned Views. É quando você tem várias tabelas de esquema idêntico e uma View que faz um UNION ALL entre elas, e cada tabela tem uma
CHECK CONSTRAINTaplicação de um determinado intervalo de dados dentro dessa tabela (e assim o Query Optimizer sabe de onde obter os dados). Ao fazer isso, você pode ter duas tabelas - atual e histórica - e, em seguida, ter consultas que atingem uma ou outra (se o período de tempo for conhecido com antecedência, como uma consulta que atinge apenas os 90 mais recentes dias) ou usa a Visualização se os dados puderem estar em qualquer um deles. Consulte o seguinte para obter mais informações:Acredito que você possa até fazer uma combinação em que a tabela "atual" seja particionada (para que você possa alternar rapidamente os dados recebidos e excluir os dados que estão se tornando "antigos"), uma tabela não particionada para histórico e uma Visualização particionada para unir os dois. Então você só precisa de uma maneira de obter os dados da partição recém-desligada na tabela "histórica".
Além disso, no que diz respeito ao desempenho, existem outros recursos oferecidos, dependendo de qual edição você está usando (alguns vêm apenas com Enterprise Edition). Mas você deve procurar Índices ColumnStore, Compressão de Dados e talvez algumas outras coisas.