Eu posso armazenar muitos dados (<= 4 GB) em uma coluna de tabela. Mas é uma boa idéia?

Question

Para encurtar uma longa história, uma parte do aplicativo em que estou trabalhando precisa armazenar um grande volume de dados em um banco de dados, para que outra parte do aplicativo seja adquirida posteriormente. Normalmente, isso seria <2000 linhas, mas ocasionalmente pode exceder 300.000 linhas. Os dados precisam ser armazenados temporariamente e podem ser excluídos posteriormente.

Eu tenho brincado com várias idéias e uma coisa veio à mente hoje. o LONGTEXT O Datatype pode armazenar no máximo 2^32 bytes, o que equivale a 4 GB. Agora, isso é muitas coisas para enfiar em uma linha de mesa. Lembre -se, os dados provavelmente não excederiam 60-80 MB no máximo. Mas minha pergunta é: é uma boa ideia fazer isso?

As duas soluções com as quais estou procurando são algo assim:

• Inserindo todos os dados como linhas individuais em uma tabela "temporária" que seria truncada após o acabamento.
• Inserir todos os dados como uma string serializada em um LONGTEXT coluna consecutiva que seria excluída após o acabamento.

Puramente da perspectiva de desempenho, seria melhor armazenar os dados como potencialmente> 300.000 linhas individuais ou como 60 MB LONGTEXT entrada?

Se for uma lavagem, provavelmente irei com o LONGTEXT A opção, pois facilitaria a redação do aplicativo que capta os dados. Também se vincularia melhor a mais uma parte, o que aumentaria o desempenho geral do aplicativo.

Eu apreciaria qualquer pensamento sobre isso.

Answer 1

Serializando todos esses dados em um LONGTEXT... blasfêmia !! :)

Sério, porém, ocorre -me que, se você fizer isso, você não teria escolha a não ser extrair tudo em uma peça gigante. Se você o espalhar em linhas individuais, por outro lado, poderá buscá-lo em lotes menores.

Pelo menos, dando a si mesmo essa opção parece a coisa inteligente a fazer. (Lembre -se de que subestimar os requisitos futuros de tamanho de uma vez que os dados podem ser um erro fatal!)

E se você projetar suas tabelas corretamente, duvido muito que 60mib de dados se espalhem por 300.000 linhas seriam menos eficientes do que buscar 60mib de texto e analisá-lo no front-end.

Em última análise, a pergunta é: você acha que seu front-end pode analisar o texto com mais eficiência do que o MySQL pode buscá-lo?

Answer 2

Isso deve ficar bem enquanto você Use um mecanismo de armazenamento de memória. No MySQL, isso significa usar o mecanismo de armazenamento de memória em vez de Innodb ou Myisam. Caso contrário, o uso do disco trará seu aplicativo de joelhos.

Answer 3

Que tipo de dados e como serão usados? Provavelmente será muito melhor armazená -lo e processá -lo em memória do seu aplicativo. Pelo menos, será muito mais rápido e não carregará o motor DB.

Answer 4

Você sempre pode armazená -lo no banco de dados como o formato de 300.000 linhas e usar o Memcached para armazenar em cache os dados para que você não precise fazê -lo novamente. Observe que o Memcached o armazena na memória da máquina; portanto, se você estiver usando muitos desses dados, poderá definir um vencimento baixo. Mas o Memcached acelera significativamente o tempo para buscar dados, porque você não precisa fazer consultas a cada página carregar.

Answer 5

Se você estiver apenas escrevendo um Blob Grande e Temporário, considere escrever em um arquivo temporário em um sistema de arquivos compartilhado.