Banco de Dados SQL VS. Vários arquivos simples (milhares de pequenos CSVs)

Estamos projetando uma atualização para um sistema atual (C ++ \ CLI e C #). O sistema coletará pequenas quantidades (~ 1Mb) de dados de dispositivos de ~ 10K (em um futuro próximo). Atualmente, eles são usados ​​para salvar dados do dispositivo em um CSV (uma tabela) e armazená-los em uma estrutura de pastas ampla.

Os dados são inseridos somente (criar/anexar a um arquivo, criar pasta) nunca atualizados/removidos. O processamento de dados é feito pela leitura de muitos CSVs para um programa externo (como o Matlab). Principalmente ser usado para análise estatística.

Existe uma opção para começar a salvar esses dados em um banco de dados MS-SQL. O tempo de processamento (leitura dos CSVs para o programa externo) pode ser de até alguns minutos.

  • Como devemos escolher qual método usar?
  • Um dos métodos consome significativamente mais armazenamento que o outro?
  • Aproximadamente, quando a leitura dos dados brutos de um banco de dados se torna mais rápida do que a leitura dos CSVs? (10 arquivos, 100 arquivos? ...)

Eu apreciaria suas respostas, Prós e Contras são bem-vindos.

Obrigado pelo seu tempo.

0
Essa é uma daquelas perguntas que você só pode responder tentando.
adicionado o autor Gabe, fonte
Você também pode considerar o uso de um banco de dados noSQL.
adicionado o autor HLGEM, fonte

4 Respostas

Bem, se você estiver usando dados em um CSV para obter dados em outro CSV, eu acho que o SQL Server será mais rápido do que o que você criou. Eu suspeito que o SQL Server seria mais rápido na maioria dos casos, mas não posso dizer com certeza. A Microsoft colocou muitos recursos para fazer um DBMS que faz exatamente o que você está tentando fazer.

Com base na sua descrição, parece que você quase criou seu próprio DBMS com base nos dados da tabela e na estrutura de pastas. Eu suspeito que, se você mudasse para o SQL Server, provavelmente encontraria várias áreas em que as coisas são mais rápidas e fáceis.

Possíveis prós:

  • Acesso mais rápido
  • Mais fácil de gerenciar
  • Mais fácil de expandir, se precisar
  • Mais fácil de aplicar a integridade dos dados
  • Mais fácil de projetar relacionamentos mais complexos

Possíveis Contras:

  • Você teria que reescrever seu código existente para usar o SQL Server em vez do seu sistema atual
  • Você pode ter que pagar pelo SQL Server, você teria que verificar se você pode usar o Express

Boa sorte!

0
adicionado
Verdade. O estúdio de gerenciamento é muito fácil de entender, e eles oferecem maneiras totalmente baseadas em UI de editar dados.
adicionado o autor Abe Miessler, fonte
Uma das maiores vantagens que vejo para arquivos CSV é que você pode entrar em um único e editá-lo facilmente. Você pode fazer o mesmo no SQL Server, mas precisa ter uma cópia do estúdio de gerenciamento e saber como realmente edita </​​i> os dados.
adicionado o autor Mike Bailey, fonte
Acordado. Para um usuário empresarial normal, a edição de CSV pode ser mais fácil. Mas, pelo que parece, não parece ser um problema.
adicionado o autor Mike Bailey, fonte

Eu gostaria de tentar acertar essas questões um pouco fora de ordem.

Aproximadamente, quando a leitura dos dados brutos de um banco de dados se torna   mais rápido do que ler o CSV? (10 arquivos, 100 arquivos? ...)

Imediatamente. O banco de dados é otimizado (supondo que você tenha feito sua lição de casa) para ler dados a taxas incríveis.

Um dos métodos consome significativamente mais armazenamento que o   outro?

Até que você esteja nas dezenas de milhares de arquivos, provavelmente não fará muita diferença. O espaço é barato, certo? No entanto, uma vez que você entrar nas grandes ligas, você notará que o DB está ocupando muito menos espaço.

Como devemos escolher qual método usar?

Ótima pergunta. Tudo no banco de dados sempre retorna à escalabilidade. Se você tivesse apenas um arquivo CSV para ler, seria bom ir. Não é necessário DB. Mesmo dezenas, não há problema.

Parece que você pode acabar em uma posição em que você dimensiona para níveis em que você definitivamente desejará o mecanismo de banco de dados por trás de seus dados rapidamente. Em caso de dúvida, a criação de um banco de dados é a aposta segura, pois você ainda poderá consultar os dados de 100 GB em um segundo.

0
adicionado

Se você tem a opção de usar um banco de dados ms-sql, eu faria isso.

Manter dados em uma estrutura de pastas ampla nunca é uma boa ideia. Ler seus dados envolveria a leitura de vários arquivos. Estes podem ser armazenados em qualquer lugar no seu disco. Seu tempo de arquivo-io seria bastante alto. O SQL Server sendo um banco de dados de produção tem esses problemas já resolvidos.

Você está reinventando a roda aqui. É assim que o foxpro gerencia dados, um arquivo por tabela. Geralmente, é uma boa ideia usar tecnologia comprovada, a menos que você esteja realmente criando um servidor de banco de dados.

Eu não tenho estatísticas de teste aqui, mas ler vários arquivos quase sempre será mais lento que um banco de dados se você estiver lidando com uma quantidade significativa de dados. Considerando seus dispositivos de cerca de 10k, você deve considerar o uso de um banco de dados padrão.

0
adicionado

Esta é uma pergunta que muitos dos nossos clientes têm onde eu trabalho. A menos que você precise de arquivos simples para uma infraestrutura existente, ou simplesmente não pense que consegue descobrir o SQL Server, ou se você tiver apenas alguns arquivos com pequenas quantidades de dados para gerenciar, será melhor usar o SQL Server.

0
adicionado