Uma importação maciça de dados MySQL em um SSD pode danificá-lo?

Question

Eu tenho que importar muitos dados (~ 100 milhões de linhas, ~ 100 vezes) em um banco de dados MySQL. Atualmente, ele é 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 massivas e tendem a danificá-las. O que você acha? Isso é realmente um problema nos modernos SSDs?

    

Answer 1

Realmente não é uma resposta direta para isso.

Os SSDs não se importam com gravações contínuas, nem com quantas vezes um determinado setor é sobrescrito. Quando os SSDs surgiram, algo como SQL era uma palavra ruim, já que o sistema operacional em geral tratava a unidade como um disco rígido tradicional e as falhas eram muito frequentes.

Desde então, os drives se tornaram maiores, mais baratos, mais confiáveis, significando mais leitura / gravação e os sistemas operacionais ficaram mais inteligentes.

Os SSDs em SQL não são apenas comuns, mas geralmente são incentivados. Sinta-se à vontade para examinar o site da irmã DBA .

Meus pensamentos são para fazer isso, assumindo que o servidor SQL é construído corretamente com discos redundantes. Se não, espere uma falha eventualmente, de qualquer maneira.

    

Answer 2

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

As gravações são outro assunto. Limpar um bit afeta a integridade do bit e após muito de gravações seqüenciais, o bit deixará de aceitar novas gravações. No entanto, ainda pode ser lido.

Deixe-me apenas dizer que os limites de gravação em novos discos corporativos 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 vai fazer o dobro desse número. Para colocar isso em números, são 14.600 TB escritos 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 esse uso. Eu não tenho certeza se você poderia escrever 8 TB em um HDD 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 um baseado em TLC ou em um MLC ruim, você deve estar bem. E de qualquer forma, RAID 10 e backups são seus amigos por um motivo. E, pelo menos, se o limite de gravação 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 corporativos são especialmente resistentes a problemas de energia. Não há mais temores de queda de cabeça e, claro, um aumento de desempenho enorme para suas necessidades de acesso ao banco de dados.

    

Answer 3

Escrever em SSDs não é necessariamente ruim. É a escrita e reescrita de um único bloco que é ruim. Isso significa que, se você escrever um arquivo, exclua-o e, em seguida, grave-o novamente ou faça pequenas alterações em um arquivo repetidas vezes. Isso causa desgaste nos SSDs. Bancos de dados definitivamente se encaixariam nessa categoria.

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

Wear leveling attempts to work around these limitations by arranging data so that erasures and re-writes are distributed evenly across the medium. In this way, no single erase block prematurely fails due to a high concentration of write cycles.

Em sua situação particular, eu teria os bancos de dados residem no SSD para velocidade, mas backup em uma base diária. Você também pode considerar comprar dois SSDs em um array RAID 1 . A probabilidade de dois SSDs falharem ao mesmo tempo é baixa.

Nota: os arrays RAID NÃO são backups !!!! Não importa se você usa uma matriz RAID ou não, tenha um backup. Não importa se você usa um SSD ou não, tenha um backup.

    

Answer 4

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

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

Aponte, você não está "mexendo" no SSD. Ou seja, você não está fazendo muitas modificações / movimentos / exclusões / etc. que potencialmente reescreveria os mesmos setores muitas vezes. Então, você vai gerar apenas um número muito pequeno de gravações por setor e isso é o 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 convertidos para minimizar o desgaste por meio de algoritmos de nivelamento de desgaste.

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

Answer 5

Isso não é problema.

Primeiro, os SSDs melhoraram muito nos últimos anos. Overprovisioning e wear leveling (e para uma pequena quantia, o comando TRIM, embora não seja aplicável no seu caso) os tornou bastante adequados como discos de uso geral de serviço pesado. Eu não estou usando nada além de SSD no meu PC de desenvolvimento (que regularmente faz muita compilação) sem nem chegar perto da contagem de ciclos de apagamento.

Além disso, esta afirmação:

SSDs do not like massive continuous writes, and that it tends to damage them

é totalmente errado. O oposto é o caso, frequentes pequenas gravações , se alguma coisa, pode causar danos aos SSDs.

Ao contrário dos discos rígidos tradicionais, os SSDs (ou melhor, o flash baseado em NAND) são fisicamente organizados em grandes blocos que contêm logicamente vários setores. Um tamanho de bloco típico é de 512kB, enquanto que 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 era comum 512B). Três coisas podem ser feitas com um bloco de 512kB. Pode ser lido a partir de, parte dele ou tudo pode ser programado (= escrito para), e o todo pode ser apagado. Apagar é o que é problemático porque há um número limitado de ciclos de apagamento, e você só pode apagar um bloco completo.

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

No caso de gravações pequenas, o controlador deve ler um bloco, modificar a cópia, apagar um bloco diferente e programá-lo. Sem o 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 apagar.

Fazer uma importação em 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) e não precisa sincronizar entre cada par de inserções. Isso equivale a um padrão de gravação muito mais compatível com SSD.

    

Answer 6

SSD não gosta disso. Se você mantiver a velocidade de gravação máxima 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.

Aviso de isenção:
Não tente isso com a primeira geração de SSDs. Aqueles onde menos robusto.

    

Answer 7

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

Em média, quantos bytes estão em cada linha?

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

Sua tortura SQL calcula para 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytes dos dados 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

Neste cenário teórico de pior caso você estará escrevendo 42 TB para o disco

De acordo com este artigo , fornecido por @KronoS você deve ser bom para mais 25 rodadas de sua tortura SQL.

    

Answer 8

Como o pôster deste

• 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 [2-16] páginas de KB (a menor unidade gravável)
• as páginas são agrupadas em blocos (128 a 256 páginas) (a menor unidade apagável)
• para que uma página seja reescrita, --- e seu bloco inteiro --- precisa ser apagado primeiro

É por isso que é recomendado

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

Então, uma quantidade realmente grande de uma vez parece muito melhor.