Um grande volume de dados do MySQL pode ser importado em um SSD?

Eu tenho que importar muitos dados (~ 100 milhões de linhas, ~ 100 vezes) em um banco de dados MySQL. Atualmente, ele está armazenado na minha unidade de disco rígido e o gargalo da minha importação parece ser a velocidade de gravação da unidade de disco rígido.

Ouvi dizer que os SSDs não gostam de gravações contínuas maciças e que isso tende a danificá-las. O que você acha? Isso é realmente um problema nos SSDs modernos?

Realmente não é uma resposta direta a isso.

Os SSDs não se preocupam com gravações contínuas, tanto quanto quantas vezes um setor em particular é substituído. Quando os SSDs surgiram pela primeira vez, algo como SQL era uma palavra ruim, pois o sistema operacional em geral tratava a unidade como um HDD tradicional e as falhas eram muito frequentes.

Desde então, as unidades se tornaram maiores, mais baratas, mais confiáveis, destinadas a mais leitura / gravação e os sistemas operacionais se tornaram mais inteligentes.

Os SSDs no SQL não são apenas comuns, mas geralmente incentivados. Sinta-se livre para ler o site irmão do DBA .

Meu pensamento é fazê-lo, supondo que o servidor SQL seja construído corretamente com discos redundantes. Caso contrário, espere uma falha eventualmente.

As leituras são boas e os SSDs podem ter seus bits lidos sem nenhum efeito prejudicial.

Escritas são outra questão. A limpeza de um bit afeta a integridade do bit e, após muitas gravações seqüenciais, o bit para de aceitar novas gravações por completo. No entanto, ainda pode ser lido.

Deixe-me apenas dizer que os limites de gravação em novas unidades empresariais são enormes. Pegue o novo 845DC Pro da Samsung. É bom para 10 gravações de unidade por dia durante 5 anos em garantia. Eu imagino que ele fará o dobro desse número. Para colocar isso em números, são 14.600 TB gravados ao longo de 5 anos no modelo de 800 GB.
Ou 2920 TB por ano,
ou 8 TB por dia, por cinco anos .

Mostre-me um disco rígido com uma garantia que cubra tanto uso. Não tenho certeza de que você poderia gravar 8 TB em um disco rígido em um dia: - (taxa de transferência média de 50 MB / s * 60 (segundos) * 60 (minutos) * 24 (horas) = ​​4.320.000 MB / dia = 4,32 TB / dia) Acontece que você não pode (em uma unidade média).

Contanto que você use uma unidade como essa, baseada em V-NAND (ou SLC igualmente durável), e não em TLC ou flash MLC ruim, você deve estar bem. De qualquer forma, o RAID 10 e os backups são seus amigos por um motivo. E pelo menos se o limite de gravação do SSD se tornar um problema, você ainda poderá ler os dados armazenados nos bits defeituosos.

Os SSDs também são mais baratos de operar, os modelos mais frios, silenciosos e empresariais são especialmente resistentes a problemas de energia. Chega de medos e, claro, um enorme aumento de desempenho para as suas necessidades de acesso ao banco de dados.

Gravar em SSDs não é necessariamente ruim. É ruim escrever e reescrever um único bloco. Ou seja, se você escrever um arquivo, exclua-o e grave-o novamente ou faça pequenas alterações em um arquivo repetidamente. Isso causa desgaste nos SSDs. Os bancos de dados definitivamente se encaixariam nessa categoria.

No entanto, de acordo com este artigo , petabytes de dados foram gravados em SSDs e ainda funcionam. Provavelmente, isso se deve aos avanços no nivelamento de desgaste :

Use as tentativas de nivelamento para contornar essas limitações, organizando os dados para que as apagamentos e reescrições sejam distribuídas uniformemente pelo meio. Dessa forma, nenhum bloco de apagamento falha prematuramente devido a uma alta concentração de ciclos de gravação.

Em sua situação específica, eu gostaria que os bancos de dados residissem no SSD para velocidade, mas com backup diário. Você também pode considerar obter dois SSDs em uma matriz RAID 1 . A probabilidade de dois SSDs falharem ao mesmo tempo é baixa.

Nota: matrizes RAID NÃO são backups !!!! Não importa se você usa ou não uma matriz RAID, faça um backup. Não importa se você usa um SSD ou não, faça um backup.

Vamos supor que sua importação não envolva atualizações e exclusões. Então você está fazendo todas as inserções. Isso deve apenas gravar novos dados no log de transações.

Isso significa que, à medida que os dados são adicionados, eles sempre estão sendo gravados em um novo setor. Pode haver alguns buffers / swap que são agitados / gravados várias vezes, mas ignorando isso, todas essas inserções resultariam teoricamente em não mais do que uma gravação por setor . Dependendo de como o MySQL é implementado e que tipo de inserção em massa você está executando, você pode gerar um segundo conjunto de gravações mais tarde, quando o log de transações estiver integrado ao arquivo de dados principal (estou entendendo os diferentes mecanismos de banco de dados e assumindo que o MySQL seja um pouco semelhante na forma como os logs de transações são liberados).

A propósito, você não está "agitando" o SSD. Ou seja, você não está fazendo muitas modificações / movimentos / exclusões / etc. que potencialmente reescreveriam sobre os mesmos setores muitas vezes. Então, você basicamente gerará apenas um número muito pequeno de gravações por setor e é isso que realmente importa.

Supondo que você não esteja preenchendo completamente o SSD, deve haver espaço livre suficiente para os pontos de acesso (como buffers / swap) que estão sendo agitados para minimizar o desgaste por meio de algoritmos de nivelamento de desgaste.

(Os índices podem ser outra questão. Como os índices agrupados em muitos bancos de dados envolvem muitas modificações à medida que os dados são inseridos. Geralmente, ao fazer grandes alterações em um ambiente de data warehouse, você desativa os índices durante a importação em massa e os atualiza depois.)

Isso não é problema.

Primeiro de tudo, os SSDs melhoraram bastante nos últimos anos. O excesso de provisionamento e o nivelamento de desgaste (e, em pequena quantidade, o comando TRIM, embora não seja aplicável no seu caso) os tornaram bastante adequados como discos de uso geral para serviços pesados. Não estou usando nada além de SSD no meu PC de desenvolvimento (que faz muita compilação regularmente) sem sequer chegar perto da contagem do ciclo de apagamento.

Além disso, esta declaração:

Os SSDs não gostam de gravações contínuas maciças e tendem a danificá-las

é totalmente errado. O oposto é o caso, gravações pequenas e frequentes , se houver, podem causar danos aos SSDs.

Ao contrário dos discos rígidos tradicionais, os SSDs (ou melhor, o flash baseado em NAND interno) são fisicamente organizados em grandes blocos que logicamente contêm vários setores. Um tamanho típico de bloco é 512kB, enquanto os setores (que é a unidade que o sistema de arquivos usa) são tradicionalmente 1kB (valores diferentes são possíveis, duas décadas atrás, 512B era comum).
Três coisas podem ser feitas com um bloco de 512kB. Ele pode ser lido, parte dele ou todos podem ser programados (= gravados em) e o todo pode ser apagado. Apagar é o que é problemático, porque há um número limitado de ciclos de apagamento e você pode apagar apenas um bloco completo.

Portanto, gravações grandes são muito compatíveis com SSD, enquanto gravações pequenas não são.

No caso de pequenas gravações, o controlador deve ler um bloco, modificar a cópia, apagar um bloco diferente e programá-lo. Sem armazenamento em cache, no pior caso possível, você precisaria apagar 512.000 blocos para gravar 512 kilobytes. No melhor caso possível (gravação grande e contínua), você precisa fazer exatamente 1 apagamento.

Fazer uma importação para um banco de dados MySQL é muito diferente de fazer muitas consultas de inserção separadas. O mecanismo é capaz de recolher muitas gravações (dados e índices) juntos e não precisa ser sincronizado entre cada par de inserções. Isso equivale a um padrão de gravação muito mais compatível com SSD.

SSD não gosta disso. Se você mantiver a velocidade máxima de gravação por 5 a 10 anos (24 horas por dia, 7 dias por semana), poderá acabar com um SSD quebrado.

Ofc. Após 5 anos, a maioria dos servidores atingiu seu fim de vida econômico.

Isenção de responsabilidade:
não tente fazer isso com a primeira geração de SSD. Aqueles onde menos robustos.

Se você estiver realmente interessado em descobrir os detalhes, precisará responder à seguinte pergunta:

Em média, quantos bytes existem em cada linha?

Se você puder me dizer que existem 10 colunas, cada coluna é varchar (100) e a codificação é UTF-8, então, na pior das hipóteses, posso supor que você tenha dados de 4.000 bytes de dados por linha e adicione mais alguns bytes para meta-dados então vamos dizer 4.200 bytes?

Seu SQL de tortura calcula os 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesdados gravados no disco

42.000.000.000.000 / 1000 = 42.000.000.000 KB

42.000.000.000 / 1000 = 42.000.000 MB

42.000.000 / 1000 = 42.000 GB

42.000 / 1000 = 42 TB

Nesse cenário teórico de pior caso, você estará gravando 42 TB no disco

De acordo com este artigo , fornecido pelo @KronoS, você deve ser bom em mais 25 rodadas de seu SQL de tortura.

Como dizia o pôster deste artigo sobre SSDs , o que é realmente prejudicial é repetidamente escrever pequenos pedaços de dados.

• bits são armazenados em células de {1,2,3} bits. Estes têm vida útil limitada.
• as células são agrupadas em páginas de [2-16] KB (menor unidade gravável)
• as páginas são agrupadas em blocos (128-256 páginas) (menor unidade apagável)
• para que uma página seja reescrita, ela --- e todo o seu bloco --- precisa ser apagada primeiro

É por isso que é recomendado

• nunca escreva menos de uma página de uma vez,
• buffer de pequenas gravações e
• solicitações de leitura e gravação separadas
• "Uma gravação grande de thread único é melhor do que muitas gravações simultâneas pequenas"

Então, uma quantidade realmente grande ao mesmo tempo parece muito melhor.