O que é melhor / mais rápido? MySql ou FileSystem?

9

Vamos imaginar um site que seja um diretório de pessoas. Para cada pessoa, pode haver uma foto do perfil e uma biografia.

Admito que minhas consultas SQL poderiam ser melhores, mas em geral o que seria mais rápido e usaria menos poder de processamento.

Para verificar se existe um arquivo e, em seguida, abra-o ou

verifique no MySql para ver se existe uma biografia e exiba-a.

Tenho certeza de que, no caso acima, o sistema de arquivos fumará o banco de dados mysql.

E se eu transformar o banco de dados em um arquivo txt delimitado apenas para leitura?

O que é mais rápido nesse caso?

Existe um certo ponto em que, se o arquivo txt tiver muitos registros, é melhor usar o MySql?

BlueBerry - Vignesh4303
fonte
4
Digamos que você tenha 100 mil pessoas em seu diretório e que deseja a biografia daqueles que nasceram em 1978. De onde você acha que a fumaça virá? Abrindo arquivos de 100K no sistema de arquivos ou uma única consulta no SQL?
precisa saber é o seguinte
11
@ypercube - Eu concordo com você, mas no caso de Linux OS, há um limite para arquivos abertos simultaneamente com cada processador.
Satish Pandey

Respostas:

17

O sistema de arquivos é útil se você estiver procurando por um arquivo específico, pois os sistemas operacionais mantêm uma espécie de índice. No entanto, o conteúdo de um arquivo txt não será indexado, o que é uma das principais vantagens de um banco de dados. Outra é entender o modelo relacional, para que os dados não precisem ser repetidos repetidamente. Outro é entender tipos. Se você possui um arquivo txt, precisará analisar números, datas etc.

Então - o sistema de arquivos pode funcionar para você em alguns casos, mas certamente não em todos.

Rob Farley
fonte
+1, também os sistemas de arquivos não são bons para pesquisas parciais em nomes de arquivos ou outros atributos. Quando o número de arquivos é tão grande, você pode ter um problema ao encontrar arquivos dessa maneira. Dito isto, é comum usar o sistema de arquivos para dados que não são de natureza transacional e onde o conteúdo é sempre acessado como uma unidade, como anexos de documentos e arquivos de imagem.
NoChance
12

Realmente depende do que você está fazendo. Em geral, a velocidade na qual você pode abrir um arquivo para leitura será melhor do que a velocidade na qual você pode estabelecer uma conexão de rede. Portanto, para operações muito simples, o sistema de arquivos é definitivamente mais rápido. O sistema de arquivos provavelmente também superará um RDBMS para taxa de transferência de leitura bruta, pois há menos sobrecarga. De fato, se você pensar bem, o banco de dados nunca poderá ser mais rápido do que o sistema de arquivos em que se baseia em termos de taxa de transferência bruta.

Para operações muito complexas, é provável que o sistema de arquivos seja muito lento. Por exemplo:

Leia 10 linhas desse arquivo de 1 bilhão de linhas e pesquise as linhas correspondentes nesse outro arquivo. Tenho pena de você se tiver que fazer isso. Um bom servidor de banco de dados, no entanto, possui estratégias para fazer isso rápido e bem, para que você não esteja reinventando a roda.

Além disso, você realmente precisa descobrir o que está fazendo. Quais dados você está armazenando? Como você vai transformá-lo? Se forem 100k arquivos de imagem, sua solução será muito diferente do que se for um diretório para 100k pessoas. (Talvez LDAP? Ou um banco de dados SQL? Depende do que você está fazendo, talvez.) A chave aqui é escolher as ferramentas que correspondem ao que você está fazendo e que oferecem espaço para adicionar mais usos, em vez do que parecer mais rápido para alguns. caso de uso bastante abstrato. Os bancos de dados são ferramentas maravilhosas, mas você não pode obter uma boa resposta para uma pergunta como essa.

Finalmente, a otimização prematura é a raiz de todo mal. Escolha ferramentas úteis agora e descubra o resto mais tarde.

Chris Travers
fonte
Obviamente, se você tiver duas instâncias virtuais se comunicando através de uma NIC virtual ou de um banco de dados em execução na mesma instância do servidor de aplicativos, se você tiver uma quantidade razoável de memória, poderá garantir que a leitura de um banco de dados seja mais rápida do que a maioria das leituras fs na maioria das vezes, porque se você confiar no sistema de arquivos, estará à mercê do algoritmo de cache / substituição de página do driver fs, enquanto um banco de dados pode reservar segmentos de memória para que nunca sejam trocados, colocando as necessidades de latência do aplicativo em primeiro lugar . Supondo que você tenha a troca ativada.
Tiro parta
Sua última linha me impulsiona ... @ Chris Travers
Biswadeep Sarkar 18 /
5

O sistema de arquivos pode ser mais rápido inicialmente, mas duvido. No entanto, à medida que o tamanho dos dados aumenta, você provavelmente terá que reestruturar seu sistema de arquivos para manter o desempenho. Além de sua capacidade óbvia de indexar em vários atributos, os bancos de dados tendem a aumentar de escala.

Caches da Web que funcionam de maneira semelhante à que você está considerando, usam a árvore de diretórios para manter o desempenho. Eles também tendem a ter uma escala relativamente fixa, portanto não precisam lidar com uma escala crescente.

Para esse tipo de aplicativo, eu começaria com um banco de dados, pois ele se ajusta melhor às suas necessidades. Escalará muito melhor a longo prazo. Comparado à maioria dos sistemas de arquivos, um banco de dados também terá mais eficiência de espaço.

BillThor
fonte
4
Bem, isso não é um problema. Vamos apenas criar outro arquivo que lista valores e procure compensações. De fato, poderíamos otimizar isso para pesquisar com btrees. Então sabemos onde ler o arquivo! Em seguida, suponho que devemos adicionar uma linguagem de consulta declarativa ao nosso pequeno programa capaz de juntar resultados entre diferentes arquivos delimitados e, talvez, conformidade com ACID ... Com o tempo, bem, por que usar um RDBMS? ;-)
Chris Travers
@ ChrisTravers Estive lá, fiz isso, e estou muito mais feliz usando um banco de dados.
BillThor
5
a idéia era do tipo "Aqueles que não aprendem com o UNIX estão destinados a reinventá-lo mal".
Chris Travers
1

Eu sempre adoro ir a esses fóruns e ler todos os gurus pesados ​​de bancos de dados que o sistema de arquivos não pode fazer tão rápido quanto o banco de dados. Pelo contrário, uma árvore projetada adequadamente, tabelas de hash bem projetadas e salvá-las como objeto em um arquivo produzirão as mesmas velocidades que um banco de dados e dos meus testes. Uma hashtable e uma árvore de diretórios projetadas corretamente vencerão sempre. Muito menos sobrecarga. Recentemente, tenho me distanciado da programação orientada a banco de dados e muito mais na árvore de arquivos por simplicidade e portabilidade de programa. Nenhum banco de dados significa backup fácil, basta fechar a árvore e partir. É muito bom e uma recomendação para programar dessa maneira para clientes antigos com pequenas aplicações. Olhe para a foto grande, tenho tempo para projetar minha própria imagem ou apenas aproveitar o que já existe como o db. Pessoalmente, gosto de salvar meus objetos para arquivar e usá-los posteriormente, apenas fique de olho no tamanho das suas tabelas e analise o uso de um RandomAccessFile para poder procurá-lo rapidamente como um banco de dados e dividi-lo em objetos hashtable . Aproveitar. Lembre-se de que qualquer dado armazenado no arquivo consumirá o dobro do uso da memória, dependendo do seu código. A própria tabela de hash e normalmente onde você a consome para exibição.

JDeCarlo
fonte
3
A única resposta apropriada para isso que consigo pensar é essa .
Mark Storey-Smith
3
@ MarkStorey-Smith, esse é um link interessante, mas é presunçoso sugerir que essa solução esteja no espectro de Dunning-Kruger em algum lugar? :)
David Mann