Servidor de armazém de dados. Como você calcula as especificações de RAM / CPU?

Estou tentando escrever uma especificação para um servidor de data warehouse para nossa atualização planejada de data warehouse.

À medida que executamos servidores virtuais nos hosts VMWare, temos a capacidade de adicionar ou remover recursos, conforme necessário. No passado, adicionamos RAM e CPU de forma incremental, conforme necessário. À medida que nossas demandas aumentam, pressionamos por mais recursos. (principalmente disco e RAM).

Pedimos mais. Eles nos dão o mínimo possível.

No entanto, recentemente, sempre que falamos de recursos, agora somos criticados por não especificar a máquina em primeiro lugar, e agora me dizem que os hosts de desenvolvimento estão com o máximo de capacidade, não há mais RAM disponível.

Somos uma pequena organização do governo local com ~ 50 usuários regulares do DW. No uso diário normal, ele funciona bem. Temos um bom desempenho de consulta mdx e nossos relatórios e painéis são rápidos. Os usuários estão felizes.

No entanto, nossos processos ETL são executados durante a noite toda e estamos começando a ver evidências de pressão de memória ao processar datamarts simultaneamente. Na noite passada, o SSIS falhou com avisos sobre um "erro de falta de memória".

Nosso servidor DW existente é o Win 2008 R2 com 4 CPUs e 16 GB de RAM executando o SQL 2012 Std. Eu tenho memória máxima do servidor definida para 12 GB, deixando 4 GB para SO e serviços etc. Nosso DW existente possui 3 datamarts / cubos OLAP, e estamos desenvolvendo mais 2.

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

Nosso novo servidor está planejado para ser o Win 2012 executando o SQL 2016 Enterprise. Ele executará SQL, SSIS, SSRS e SSAS. O armazenamento não é um problema, mas não tenho certeza sobre RAM e CPU.

De acordo com o Guia de referência do Fast Track Data Warehouse para SQL Server 2012 , o mínimo que devo ter é 128 GB para uma máquina de 2 soquetes ... o que parece um pouco excessivo. Os requisitos de hardware e software para instalar o SQL Server 2016 recomendam um mínimo de 4Gb de RAM para o SQL 2016. Isso é bastante diferente!

Então .. Qual é um bom ponto de partida? 32Gb? 64GB? Como justifico minha posição inicial (especificação) para a TI?

Existem bons guias sobre como calcular os recursos do servidor?

Existem boas regras de ouro?

Quais são os principais ingredientes / métricas para o dimensionamento da RAM em um contexto de DW?

• O volume de dados?
• O número de cubos?
• Quanto tempo leva para fazer ETL ou processar um cubo?
• Pico de carga de processamento durante a noite ou desempenho conforme visualizado pelos usuários finais durante o dia?

Ótima pergunta, e eu fiz uma sessão sobre isso na TechEd há alguns anos, chamada Construindo os servidores SQL mais rápidos:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

Nele, explico que, para data warehouses, você precisa de armazenamento que possa fornecer dados com rapidez suficiente para o SQL Server consumi-los. A Microsoft criou uma grande série de documentos técnicos, denominada Arquitetura de referência do Fast Track Data Warehouse, que aborda os detalhes do hardware, mas a idéia básica é que seu armazenamento precise fornecer um desempenho de leitura sequencial de 200 a 300 MB / s, por núcleo da CPU, em para manter as CPUs ocupadas.

Quanto mais dados você puder armazenar em cache na memória, mais lento será o armazenamento. Mas você tem menos memória do que o necessário para armazenar em cache as tabelas de fatos com as quais está lidando, portanto, a velocidade de armazenamento se torna muito importante.

Aqui estão seus próximos passos:

• Assista ao vídeo
• Teste seu armazenamento com o CrystalDiskMark ( veja como )
• Com 4 núcleos, você desejará pelo menos 800 MB / s de taxa de transferência de leitura sequencial
• Se você não tiver isso, considere adicionar memória até que a dor desapareça (e armazenar em cache todo o banco de dados na RAM não é impensável)

Digamos que você esteja lidando com um banco de dados de 200 GB e não tenha capacidade de armazenamento suficiente para manter seus núcleos ocupados. Não é impensável precisar não apenas de 200 GB de RAM, mas ainda mais - porque, afinal, o SSIS e o SSAS realmente querem fazer o trabalho deles na memória, então você precisa ter os dados do mecanismo disponíveis, além de espaço de trabalho para o SSIS e o SSAS.

É também por isso que as pessoas tentam separar o SSIS e o SSAS em diferentes VMs - todas elas precisam de memória simultaneamente.

O Guia de referência do Fast Track Data Warehouse para SQL Server 2012 está realmente um pouco desatualizado, especialmente se você estiver mudando para o SQL Server 2016 (sério? Ligue para mim), não apenas em termos de tempo, mas também de recursos.

No SQL Server 2012, a versão na qual o fast-track se baseia, você só pode ter índices columnstore não agrupados em cluster. Essas são estruturas separadas da tabela principal, portanto incorrem em sobrecarga adicional de armazenamento e processamento devido a cópias compactadas dos dados.

A partir do SQL Server 2014, você pode ter índices columnstore clusterizados. Eles oferecem compactação maciça e aumento potencial de desempenho para consultas agregadas / resumidas. Eles são absolutamente apropriados para tabelas de fatos, portanto, sua tabela de fatos de 32 GB pode parecer mais ~ 8-12 GB. YMMV. Isso muda um pouco a paisagem, não é? Olhando para a sua mesa (e com o polegar no ar), talvez você possa se safar com 32 GB, mas eu atiraria em 64 GB (não é como se você estivesse pedindo 1 TB) e deixaria um espaço para outros serviços e crescimento, a justificativa é que isso permite você mantenha sua maior mesa na memória, permita espaço para crescimento e espaço para outros serviços. Você não precisa contar a eles sobre a compactação. Uma coisa que você deve ter em mente no dimensionamento é que você não está apenas dimensionando seus dados agora, mas como será, digamos, daqui a um ano. Observe também, no entanto, que o desempenho para pesquisas de pontos pode ser horrível, mas ao mudar para o SQL Server 2016, você pode adicionar índices adicionais ou sempre considerar os índices Columnstore para análise operacional em tempo real, embora seja necessário mais memória para isso. :)

A propósito, como você está lidando com os CTPs, atualmente no CTP3.3 ele tem a maioria dos recursos que você deseja usar disponíveis, então você diz que não tem recurso para avaliações, mas que pode obter uma avaliação do Windows Azure , gire uma VM, crie alguns dados de amostra, teste a compactação, o desempenho dos principais recursos e consultas etc gratuitamente. Ou, se você possui uma licença do MSDN, ela está incorporada.

Em resumo, tamanho para permitir que sua maior tabela fique na memória (além de outras coisas) ou configure uma avaliação simples (gratuitamente na nuvem) para obter as evidências concretas que você procura. Lembre-se de desalocar sua VM quando terminar:)

Presumivelmente, ao desenvolver e manter os pacotes ETL em máquinas de desenvolvimento local, você às vezes usa dados de teste de escala semelhante ou maior àquela que você espera na produção e, caso contrário, talvez considere fazê-lo (dados reais anônimos ou dados de teste gerados por algoritmos, se seus dados reais forem sensíveis).

Se esse for o caso, você poderá executar o processo sob várias condições de memória e criar um perfil, para ver o ponto em que mais memória RAM deixa de fazer uma diferença enorme - tão útil quanto as regras práticas e as adivinhações educadas, nada de comparações e perfis pode fornecer respostas muito mais concretas e, como bônus, pode destacar gargalos óbvios que podem ser fáceis de otimizar. É claro que seus ambientes de desenvolvimento / teste podem não corresponder exatamente à produção; portanto, você pode precisar usar a experiência para interpretar como os resultados podem mudar.

Se você estiver executando o SSIS na mesma máquina que os bancos de dados, certifique-se definitivamente de que as instâncias do mecanismo do SQL Server estejam definidas para nunca reivindicar toda a memória. Não apenas a falta de memória pode causar erros de OOM no SSIS, muito antes desse ponto, como também pode causar problemas significativos de desempenho, uma vez que coloca spools de buffers no disco quando poderia mantê-los na RAM. Quanto você precisa reservar para o SSIS e outras tarefas variará bastante, dependendo do processo, portanto, novamente, o perfil é uma boa maneira de avaliar isso. Em geral, é recomendável executar o SSIS em uma máquina separada para facilitar o gerenciamento, embora você possa ter problemas de taxa de transferência e licenciamento de rede a considerar.

Atualizar

Se, de acordo com o seu comentário, não houver recurso disponível para realizar benchmarks realistas para medir onde o desempenho diminui (e / ou erros de OOM e problemas relacionados começam a acontecer) se houver pouca RAM alocada, as coisas ficam consideravelmente mais fáceis de entender sem conhecimento profundo dos processos de armazém e ETL. Uma regra prática para o próprio banco de dados do armazém: você deseja RAM suficiente para armazenar todos os índices mais usados ​​e, em seguida, alguns para permitir dados menos usados ​​e mais uma vez para permitir o crescimento esperado no futuro próximo / futuro médio.

Calcular isso pode ser faf - o sp_spaceUsed não detalha as coisas pelo índice, então você terá que consultar sys.allocation_units e amigos diretamente. Porém, existem alguns exemplos para você começar, http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 / parece o melhor dos primeiros que vieram de uma pesquisa rápida.

Além das necessidades de execução do próprio banco de dados do armazém, lembre-se de adicionar os requisitos de RAM para o SSIS para que ele esteja executando na mesma máquina e verifique se o SQL Server possui limites de RAM para garantir que essa memória esteja realmente disponível para SSIS.

Dos tamanhos gerais de dados que você lista, meu intestino sugere que 32 GB seria o mínimo absoluto que eu recomendaria apenas para o mecanismo de banco de dados e o SSIS, configurando a (s) instância (s) SQL para usar no máximo 26 delas, e como você também está executando O SSRS e outros serviços na mesma máquina, no mínimo sensato, com algumas provas futuras, seriam 64 GB (dois terços dos seus dados atuais devem caber no mesmo após outros serviços e reservas serem cortados). Obviamente, citar meu instinto não o levará muito longe nas discussões com seu pessoal de infraestrutura ...