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


28

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?


Contanto que você deixe (digamos) 2-3 GB fora da área particionada para excesso de provisionamento, acho que você está seguro com isso. Não vejo muito problema com isso. A maioria dos SSDs já possui uma parte do disco que não é acessível ao sistema operacional. Esse espaço é usado para nivelar o desgaste e superprovisionar, caso o disco rígido esteja muito cheio. Esses GB extras darão mais espaço para o SSD distribuir os dados para evitar danos. Se você é hard-core e deseja continuar com isso, pode descobrir quantos chips de memória seu ssd possui e fornecer 1 GB por chip. 10 chips são 10 GB não particionados.
Ismael Miguel

5
Por pouco que valha a pena, nós importamos rotineiramente muito, muito mais dados do que isso. Uma única de nossas tabelas tem muito mais dados do que você está importando e temos algumas centenas de tabelas. Nós usamos SSDs. Espero que você esteja bem.
ChrisInEdmonton

4
Atualmente, os SSDs são inteligentes o suficiente para lidar com o nivelamento de desgaste, mesmo sem o suporte do SO (mesmo que o SO peça para reescrever o mesmo bloco, o controlador do SSD grava de forma transparente em um bloco diferente a cada vez), então tudo ficará bem.

7
Arenque vermelho. Não se preocupe com a taxa de falhas dos SSDs - será longo o suficiente para que eles ainda durem mais que a ferrugem equivalente.
Sobrique 24/04

2
As pessoas se preocupam demais com seus SSDs. Basicamente, você nunca conseguirá "destruir" seu SSD por acidente, e mesmo fazê-lo de propósito pode exigir semanas ou meses de gravações contínuas. Mesmo se você "destruí-lo", ele ainda fornecerá os dados como somente leitura. Pare de se preocupar e apenas use-o. Você também pode perguntar sobre como a cabeça de leitura / gravação do seu HDD é desgastada pelas acelerações.
mic_e

Respostas:


27

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.


5
"Se não, então espere uma falha eventualmente." Se o servidor não use discos redundantes, ainda definitivamente esperar uma falha em algum ponto, e um plano para ele. É que, com a redundância em vigor, uma única falha do dispositivo de armazenamento tem uma probabilidade muito menor de levar ao tempo de inatividade do sistema.
um CVn

@ MichaelKjörling sim, precisamente. Na minha opinião, "construído corretamente" também pressupõe backups do banco de dados em caso de falha ... Mas, às vezes, mesmo o que deveria ser bom para ser deixado não dito precisa ser dito, obrigado.
Austin T francês

19

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.


12
Posso perguntar por que o voto negativo?
Ctrl-Alt-dlt

Você pode perguntar, mas aparentemente não receberá.
Fund Monica's Lawsuit

12

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.


1
O RAID1 faria muito pouco pelo tipo de dano que você está falando. É provável que o nível de desgaste seja determinístico, o que significa que eles se desgastam exatamente na mesma taxa e maneira, causando erros quase exatamente nos mesmos locais.
Aron

do artigo vinculado: "os eletrônicos no SSD falharão muito antes que o NAND se esgote" ... espere, o que?
Michael

4

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.)


3

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.


2
Os setores são tradicionalmente 1 KiB? Citação, por favor. Em unidades rotacionais, dois tamanhos de setor são comuns: 512 bytes (tradicionais, como nos meus HDDs de 4 TB, em compatíveis com a IBM datam de 1981) ou 4096 bytes ("Advanced Format"). As unidades de alocação no nível do sistema de arquivos podem variar em tamanho, mas isso é uma questão completamente diferente e é puramente uma construção do sistema de arquivos para manter as estruturas de dados rastreando a alocação para um tamanho razoável em sistemas de arquivos que não as aumentam dinamicamente conforme a necessidade ; além disso, duvido que os tamanhos fixos de blocos de 1 KiB sejam muito comuns na prática.
um CVn

@ MichaelKjörling: Obrigado por sua contribuição muito valiosa. Claro que você leu e entendeu a resposta, não foi? O fato relevante é que os SSDs possuem tamanhos físicos de blocos muito maiores que isso, independentemente do tamanho do setor lógico (que eu já vi de 500 a 4096 bytes, mesmo com tamanhos que não são dois). Nenhuma citação necessária.
Damon

1

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.


Estou ciente de que o uso de qualquer disco em sua capacidade máxima 24/7 acabaria danificando-o ... Minha pergunta é se é seguro por um período limitado de tempo (digamos várias vezes de 2 a 3 horas)
christophetd

@christophetd - Depende. Atualize sua pergunta para estimar a quantidade de dados. É mais sobre a porcentagem da unidade. Escrever 20 GB por hora em um SSD de 80 GB é pior do que fazer 20 GB por hora em um SSD de 1 TB.
Ramhound

Na mesma nota: Ter uma unidade quase vazia significa que muitas das células flash 'vazias' são usadas no nivelamento de desgaste. (e uma unidade maior com a mesma quantidade de dados é% enquanto mais vazia).
Hennes 24/04

1

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.


-2

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.


2
Essa resposta realmente não fornece nenhuma informação relevante que não tenha sido dita; além disso, é basicamente um comentário com um link contido nela.
Ramhound

@ Ramhound: você daria sua aprovação para o seu comentário (obrigado, aliás), e isso também seria marcado como obsoleto? Ou você ainda considera as informações já mencionadas / irrelevantes?
serv-inc

Embora a sua não é mais um link, honestamente, a informação técnica em si, não se aplica realmente a questão do usuário com relação à execução de um banco de dados em um SSD I
Ramhound

@ Ramhound: para mim, parecia ser sobre a importação, não a corrida. A julgar pelas downvotes, parece que você está certo
serv-inc
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.