Disco e amp; Planejamento de Capacidade RAM
O planejamento de capacidade de disco e memória para um servidor de banco de dados é uma arte em preto. Mais é melhor. Mais rápido é melhor.Como diretrizes gerais, eu ofereço o seguinte:
- Você quer mais espaço em disco do que você precisará EVER .
Faça a sua melhor estimativa de quanto espaço em disco você precisará para os próximos 3 a 5 anos, depois duplique. - Você precisará de RAM suficiente para manter os índices do banco de dados na memória, lidar com sua maior consulta pelo menos duas vezes e ainda ter espaço suficiente para um cache de disco do SO saudável. O tamanho do índice dependerá do seu banco de dados, e tudo o mais depende muito do seu conjunto de dados e estrutura de consulta / banco de dados. Eu vou oferecer "Pelo menos 2x o tamanho da sua maior tabela" como sugestão, mas note que essa sugestão quebra em operações de data warehousing realmente grandes, onde a maior tabela pode ter dezenas ou centenas de gigabytes.
Todo fornecedor de banco de dados tem algumas instruções sobre o ajuste de desempenho do seu disco / memória / kernel do SO - gaste algum tempo com esta documentação antes da implantação. Isso ajudará.
Benchmarking de carga de trabalho e planejamento de capacidade
Supondo que você ainda não tenha implantado…
Muitos sistemas de banco de dados são fornecidos com o Benchmarking Tools - Por exemplo, o PostgreSQL é fornecido com pgBench .Essas ferramentas devem ser sua primeira parada no benchmarking do desempenho do banco de dados. Se possível, você deve executá-los em todos os novos servidores de banco de dados para ter uma ideia de "quanto trabalho" o servidor de banco de dados pode fazer.
Armado agora com um benchmark bruto que é ABSOLUTELY MEANINGLESS vamos considerar uma abordagem mais realista ao benchmarking: Carregue seu esquema de banco de dados e escreva um programa que preencha com o dummy dados, em seguida, execute as consultas do seu aplicativo em relação a esses dados.
Isso avalia três coisas importantes:
1. O servidor de banco de dados (hardware)
2. O servidor de banco de dados (software)
3. O design do banco de dados e como ele interage com (1) e (2) acima.
Note que isso exige muito mais esforço do que benchmarks pré-construídos simples, como pgBench : você precisa escrever algum código para fazer o preenchimento, e você pode precisar escrever algum código para fazer as consultas & relatar tempo de execução.
Esse tipo de teste também é substancialmente mais preciso: como você está trabalhando com seus esquemas e consultas, pode ver como eles serão executados e oferece a oportunidade de criar perfis e melhorar seu banco de dados / consultas.
Os resultados desses benchmarks são uma visão idealizada do seu banco de dados. Por segurança, suponha que você atingirá apenas de 50 a 70% desse desempenho em seu ambiente de produção (o restante é um colchão que lhe permitirá lidar com crescimento inesperado, falhas de hardware, alterações de carga de trabalho, etc.).
É tarde demais! Está em produção!
Uma vez que seus sistemas estão em produção, é realmente muito tarde para "benchmarking" - você pode ativar o registro de consultas / temporização brevemente e ver quanto tempo as tarefas demoram para executar e executar algumas consultas de "teste de estresse" contra dados grandes define durante as horas de folga. Também é possível observar a utilização da CPU, da RAM e da E / S (largura de banda do disco) do sistema para ter uma ideia de quão carregado está.
Infelizmente, tudo isso fará com que você tenha uma ideia do que o sistema está fazendo e um conceito vago de quão próximo da saturação ele está.
Isso nos leva a…
Monitoramento contínuo
Todos os benchmarks do mundo não irão ajudá-lo se o seu sistema de repente estiver vendo padrões de uso novos / diferentes.
Para melhores ou piores implantações de banco de dados não são estáticas: seus desenvolvedores mudarão as coisas, seu conjunto de dados crescerá (eles nunca parecerão encolher) e seus usuários de alguma forma criarão combinações insanas de eventos que você nunca previu em testes.
Para fazer um planejamento de capacidade adequado para seu banco de dados, você precisará implementar algum tipo de monitoramento de desempenho para alertá-lo quando o desempenho do banco de dados não estiver mais atendendo às suas expectativas. Nesse ponto, você pode considerar ações corretivas (novo hardware, esquema de banco de dados ou alterações de consulta para otimizar o uso de recursos, etc.).
Note: This is a very high level and generic guide to sizing your database hardware and figuring out how much abuse it can take. If you are still unsure about how to determine if a specific system meets your needs you should speak to a database expert.
There is also a Stack Exchange site specifically dedicated to database management: dba.stackexchange.com. Search their question archive or browse the tags specific to your database engine for further advice on performance tuning.