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

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?

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.

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.

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.

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.