Qual armazenamento da AWS você deve usar para um servidor de banco de dados?

O desempenho do banco de dados é fortemente afetado pelo desempenho da memória subjacente. Para leituras, ter muita RAM pode acelerar as coisas, mas para operações pesadas de gravação, o gargalo é o SSD do disco rígido que ele esgota. A AWS tem muitas opções de armazenamento, então qual é a melhor para você?

Instâncias EC2 com foco em banco de dados

Além de apenas armazenamento subjacente, existem muitos outros fatores para o desempenho do banco de dados. A AWS tem muitas classes diferentes de instâncias com níveis individuais dentro delas.

A instância mais orientada a banco de dados é a série R5. Estes são otimizados para desempenho de memória, tanto com velocidade e tamanho de RAM quanto com desempenho de EBS. Eles oferecem uma alta proporção de contagem de núcleos para memória disponível, até 768 GB de RAM no r5.24xlarge.

Também existe a série r5d, uma subclasse de R5 que oferece um disco local direto, não no EBS. A maior camada tem quatro SSDs NVMe de 900 GB. Menor em tamanho do que a capacidade máxima do EBS, mas terá um desempenho estelar e grande latência.

Há também a série D3, que oferece a maior quantidade de armazenamento local possível para uma instância EC2, até 336 TB. Se você deseja executar uma instância particularmente grande armazenando muitos dados, o D3 pode funcionar melhor para você.

Tipos de volume EBS

O EBS tem alguns níveis diferentes. O mais comum é gp3, que é um volume com backup de SSD de uso geral que oferece desempenho sólido a um preço mais alto do que os volumes com backup de disco rígido. gp3 é a última geração, substituindo gp2 e oferecendo desempenho 4x melhor usando SSDs PCIe Gen 4.

gp3 usa um modelo de precificação burst-bucket. Dependendo do tamanho do volume, ele ganha “ Créditos de IO ” por hora que são usados ​​automaticamente para comprar IOPS ou operações de entrada-saída-por-segundo. Isso permite picos rápidos de desempenho quando necessário, mas se você precisa de um desempenho estável e sólido, confiar nisso não é uma boa ideia. Também há um número máximo de IOPS; para gp3, são 16.000.

Os volumes ganham créditos de IO a uma taxa de 3 por GB por segundo. O que significa que se você tiver um volume superior a 1 TB, seu balde estará sempre cheio e você não terá que se preocupar com o desempenho do burst. Qualquer coisa abaixo disso e você estará limitado ao desempenho básico com base em quantos créditos você ganha.

O que isso significa na prática é que, se você precisar de desempenho extra, deverá usar o segundo volume baseado em SSD, io2, também conhecido como SSD IOPS provisionado. Isso permite que você literalmente compre desempenho de disco diretamente, provisionado para seu volume EBS. O melhor nível, io2 Block Express, oferece até 4.000 MB / s por volume e 7.500 MB / s por instância.

Isso é até quatro vezes o desempenho do gp3, mas somente se você puder pagar por isso — a largura de banda é cara e você precisará pagar por cada pedacinho disso. Um volume io2 top de linha pode facilmente custar milhares de dólares por mês, mais do que a instância EC2 que pode estar em execução nele. Isso se soma ao aumento de 83% nos custos de armazenamento por GB.

Embora o io2 seja uma opção para clientes que precisam de cada grama de desempenho que podem obter, a menos que você esteja maximizando sua unidade, os volumes de gp3 de uso geral serão ótimos para muitas pessoas.

Volumes do disco rígido

Existem dois volumes EBS do disco rígido principal, Volumes do HDD otimizado para throughput (st1) e Volumes do HDD frio (sc1). Os nomes são bastante autoexplicativos — st1 é otimizado para velocidades decentes de leitura sequencial (embora desempenho aleatório terrível, como todos os discos rígidos têm). Para aplicativos não críticos que exigem arquivos grandes, o sc1 oferece excelente desempenho de armazenamento local.

Ambos os tipos de volumes também usam o modelo burst bucket, mas atingem um número fixo de MBps com base no tamanho do volume.

Para bancos de dados, porém, o desempenho aleatório de leitura e gravação pode ser muito importante, assim como a latência. É 2020 e seus usuários não deveriam ter que esperar o disco girar e esperar que uma cabeça de leitura magnética busque alguns dados básicos. Sem mencionar como ele lidaria com consultas SQL complexas que poderiam paralisar o disco.

Para qualquer coisa voltada para o usuário, o desempenho é importante e você deve usar um SSD. O único caso em que faz sentido é em aplicativos de leitura pesada em que o banco de dados é pequeno o suficiente para ser mantido principalmente na memória, mas mesmo assim, seria pequeno o suficiente onde o leve prêmio de até mesmo um volume gp3 básico valeria a pena .

No entanto, para big data, analytics e outros bancos de dados internos, o banco de dados pode ser tão grande que o custo do armazenamento local é muito alto para ser executado em SSDs. Se você deseja executar um data lake de alta capacidade ou cluster de vários servidores, pode não se importar muito com a velocidade de disco um pouco pior, especialmente se isso estiver economizando dinheiro no processo.