Por que usar um banco de dados em vez de apenas salvar seus dados em disco?

Em vez de um banco de dados, apenas serializo meus dados em JSON, salvando e carregando-os em disco quando necessário. Todo o gerenciamento de dados é feito no próprio programa, o que é mais rápido e fácil do que usar consultas SQL. Por esse motivo, nunca entendi por que os bancos de dados são necessários.

Por que alguém deveria usar um banco de dados em vez de apenas salvar os dados em disco?

1. Você pode consultar dados em um banco de dados (faça perguntas).
2. Você pode procurar dados de um banco de dados relativamente rapidamente.
3. Você pode relacionar dados de duas tabelas diferentes usando JOINs.
4. Você pode criar relatórios significativos a partir de dados em um banco de dados.
5. Seus dados têm uma estrutura interna.
6. As informações de um determinado tipo são sempre armazenadas apenas uma vez.
7. Bancos de dados são ACID .
8. Os bancos de dados são tolerantes a falhas.
9. Os bancos de dados podem lidar com conjuntos de dados muito grandes.
10. Bancos de dados são simultâneos; vários usuários podem usá-los ao mesmo tempo sem danificar os dados.
11. Os bancos de dados são bem dimensionados.

Em resumo, você se beneficia de uma ampla variedade de tecnologias comprovadas e conhecidas, desenvolvidas ao longo de muitos anos por uma grande variedade de pessoas muito inteligentes.

Se você está preocupado com o excesso de banco de dados, confira SQLite.

Embora eu concorde com tudo o que Robert disse, ele não disse quando você deveria usar um banco de dados, em vez de apenas salvar os dados em disco.

Portanto, leve isso além do que Robert disse sobre escalabilidade, confiabilidade, tolerância a falhas, etc.

Para quando usar um RDBMS, aqui estão alguns pontos a serem considerados:

• Você possui dados relacionais, ou seja, possui um cliente que compra seus produtos e esses produtos têm um fornecedor e fabricante
• Você possui grandes quantidades de dados e precisa localizar informações relevantes rapidamente
• Você precisa começar a se preocupar com os problemas anteriores identificados: escalabilidade, confiabilidade, conformidade com ACID
• Você precisa usar ferramentas de relatórios ou inteligência para solucionar problemas de negócios

Quanto a quando usar um NoSQL

• Você tem muitos dados que precisam ser armazenados que não são estruturados
• Necessidades de escalabilidade e velocidade
• Geralmente, você não precisa definir seu esquema antecipadamente; portanto, se você tiver requisitos alterados, isso pode ser um bom ponto

Finalmente, quando usar arquivos

• Você possui dados não estruturados em quantidades razoáveis ​​que o sistema de arquivos pode manipular
• Você não se importa com estrutura, relacionamentos
• Você não se importa com escalabilidade ou confiabilidade (embora isso possa ser feito, dependendo do sistema de arquivos)
• Você não quer ou não pode lidar com a sobrecarga que um banco de dados adicionará
• Você está lidando com dados binários estruturados que pertencem ao sistema de arquivos, por exemplo: imagens, PDFs, documentos, etc.

Uma coisa que ninguém parece ter mencionado é a indexação de registros. Sua abordagem está correta no momento e presumo que você tenha um conjunto de dados muito pequeno e poucas pessoas acessando.

À medida que você fica mais complexo, na verdade você está criando um banco de dados. Como você quiser chamá-lo, um banco de dados é apenas um conjunto de registros armazenados em disco. Esteja você criando o arquivo ou MySQL , SQLite ou o que estiver criando o (s) arquivo (s), ambos são bancos de dados.

O que está faltando é a funcionalidade complexa que foi incorporada aos sistemas de banco de dados para torná-los mais fáceis de usar.

A principal coisa que vem à mente é a indexação. OK, então você pode armazenar 10 ou 20 ou mesmo 100 ou 1000 registros em uma matriz serializada ou em uma string JSON e retirá-la do seu arquivo e iterá-lo de forma relativamente rápida.

Agora, imagine que você tenha 10.000, 100.000 ou até 1.000.000 de registros. Quando alguém tentar fazer login, você terá que abrir um arquivo que agora possui várias centenas de megabytes de tamanho, carregá-lo na memória do seu programa, extrair uma matriz de informações de tamanho semelhante e, em seguida, repetir centenas de milhares de registros apenas para encontre o registro que deseja acessar.

Um banco de dados adequado permitirá que você configure índices em determinados campos nos registros, permitindo consultar o banco de dados e receber uma resposta muito rapidamente, mesmo com grandes conjuntos de dados. Combine isso com algo como Memcached , ou mesmo um sistema de armazenamento em cache caseiro (por exemplo, armazene os resultados de uma pesquisa em uma tabela separada por 10 minutos e carregue esses resultados caso outra pessoa procure a mesma coisa logo depois) e você terá consultas rápidas, algo que não terá com um conjunto de dados tão grande quando estiver lendo / gravando manualmente em arquivos.

Outra coisa pouco relacionada à indexação é a transferência de informações. Como eu disse acima, quando você tiver arquivos de centenas ou milhares de megabytes, precisará carregar todas essas informações na memória, itere-as manualmente (provavelmente no mesmo encadeamento) e depois manipule seus dados.

Com um sistema de banco de dados, ele será executado em seus próprios encadeamentos ou até em seu próprio servidor. Tudo o que é transmitido entre o seu programa e o servidor de banco de dados é uma consulta SQL e tudo o que é transmitido de volta são os dados que você deseja acessar. Você não está carregando todo o conjunto de dados na memória - tudo o que está enviando e recebendo é uma pequena fração do seu conjunto total de dados.

Quando você possui dados simples, como uma lista de itens descritos nos comentários da sua pergunta, um banco de dados SQL não oferece muito. Muitas pessoas ainda os usam, porque sabem que seus dados podem ficar mais complicados ao longo do tempo e existem muitas bibliotecas que tornam o trabalho com o banco de dados trivial.

Mas mesmo com uma lista simples que você carrega, mantém na memória e depois escreve quando necessário, pode sofrer vários problemas:

O encerramento anormal do programa pode perder dados ou, ao gravar dados no disco, algo dá errado, e você pode acabar matando o arquivo inteiro. Você pode usar seus próprios mecanismos para lidar com isso, mas os bancos de dados lidam com isso usando técnicas comprovadas em batalha.

Se seus dados começarem a crescer muito e a atualizar com muita frequência, a serialização de todos os dados e a economia serão um grande recurso para os recursos e tornarão tudo lento. Você teria que começar a descobrir como particionar as coisas, para que não seja tão caro. Os bancos de dados são otimizados para salvar apenas as coisas que mudam para o disco de maneira tolerante a falhas. Além disso, eles foram projetados, para que você possa carregar rapidamente os pequenos dados necessários a qualquer momento.

Além disso, você não precisa usar bancos de dados SQL. Você pode usar os "bancos de dados" NoSQL que muitos usam, basta usar o JSON para armazenar os dados. Mas isso é feito de maneira tolerante a falhas e de maneira que os dados podem ser divididos, consultados e divididos de forma inteligente em vários computadores.

Além disso, algumas pessoas confundem as coisas. Eles podem usar um repositório de dados NoSQL como o Redis para armazenar informações de login. Em seguida, use bancos de dados relacionais para armazenar dados mais complexos, onde eles precisam fazer consultas mais interessantes.

Vejo muitas respostas focadas no problema de simultaneidade e confiabilidade. Os bancos de dados oferecem outros benefícios além da simultaneidade, confiabilidade e desempenho. Eles permitem não incomodar como bytes e caracteres são representados na memória. Em outras palavras, os bancos de dados permitem que o programador se concentre em "o quê" e não em "como".

Uma das respostas menciona consultas. "Fazer uma pergunta ao banco de dados SQL" se adapta bem à complexidade de uma pergunta. À medida que o código evolui durante o desenvolvimento, consultas simples como "buscar tudo" podem ser facilmente expandidas para "buscar tudo onde a propriedade1 é igual a esse valor e depois classificar por propriedade2", sem que o programador se preocupe em otimizar a estrutura de dados para essa consulta. O desempenho da maioria das consultas pode ser acelerado, criando um índice para uma determinada propriedade.

Outro benefício são as relações. Com as consultas, é mais fácil fazer a referência cruzada de dados de diferentes conjuntos de dados e ter loops aninhados. Por exemplo, a pesquisa de todas as postagens no fórum de usuários com menos de três postagens em um sistema em que usuários e postagens são conjuntos de dados diferentes (ou tabelas de banco de dados ou objetos JSON) podem ser feitos com uma única consulta sem sacrificar a legibilidade.

Em suma, os bancos de dados SQL são melhores que as matrizes simples, se o volume de dados puder ser grande (digamos, mais de 1000 objetos), o acesso a dados em partes não triviais e diferentes do código e o acesso a diferentes subconjuntos de dados.

TLDR

Parece que você tomou uma decisão técnica de armazenamento de dados de curto prazo essencialmente válida para o seu aplicativo - você optou por escrever uma ferramenta de gerenciamento de armazenamento de dados personalizada.

Você está sentado em um continuum, com opções para se mover em qualquer direção.

A longo prazo, você provavelmente (quase, mas não 100% com certeza) se deparará com problemas e poderá ser melhor mudar o uso das soluções de armazenamento de dados existentes. Existem problemas de desempenho específicos, muito comuns, previsíveis, com os quais você será forçado a lidar, e é melhor usar as ferramentas existentes em vez de usar as suas.

Parece que você escreveu um banco de dados (pequeno) personalizado, incorporado e usado diretamente pelo seu aplicativo. Suponho que você esteja confiando em um sistema operacional e sistema de arquivos para gerenciar a gravação e a leitura reais do disco e tratar a combinação como um armazenamento de dados.

Quando fazer o que você fez

Você está sentado em um ponto ideal para armazenamento de dados. Um armazenamento de dados do sistema operacional e do sistema de arquivos é incrivelmente conveniente, acessível e portátil para várias plataformas. A combinação existe há tanto tempo que você certamente terá suporte e executará seu aplicativo em quase todas as configurações de implantação padrão.

Também é uma combinação fácil de escrever código - a API é bastante direta e básica, e são necessárias poucas linhas de código para fazê-lo funcionar.

Geralmente, é ideal fazer o que você fez quando:

• Prototipagem de novas idéias
• Criando aplicativos que dificilmente precisam ser dimensionados, em termos de desempenho
• Restringido por circunstâncias incomuns, como falta de recursos para instalar um banco de dados

Alternativas

Você está em um continuum de opções, e há duas 'direções' que você pode seguir a partir daqui, o que eu penso como 'abaixo' e 'acima':

Baixa

Esta é a opção menos provável de aplicar, mas está aqui por uma questão de integridade:

Você pode, se quiser, ficar inativo , ou seja, ignorar completamente o sistema operacional e o sistema de arquivos e realmente escrever e ler diretamente do disco. Essa escolha geralmente é relevante apenas nos casos em que é necessária extrema eficiência - pense, por exemplo, em um dispositivo MP3 / minúsculo / minúsculo , sem RAM suficiente para um sistema operacional totalmente funcional ou em algo como o Wayback Machine , que requer massa incrivelmente eficiente operações de gravação de dados (a maioria dos armazenamentos de dados troca gravações mais lentas para leituras mais rápidas, pois esse é o caso de uso mais comum para quase todos os aplicativos).

Acima

Existem várias subcategorias aqui - elas não são exatamente exclusivas. Algumas ferramentas abrangem as duas, fornecendo alguma funcionalidade em cada uma, algumas podem mudar completamente de trabalhar em um modo para trabalhar no outro, e algumas podem ser colocadas em camadas umas sobre as outras, fornecendo funcionalidades diferentes para diferentes partes do seu aplicativo.

Armazéns de dados mais poderosos

Você pode precisar armazenar volumes cada vez mais altos de dados, enquanto ainda conta com seu próprio aplicativo para gerenciar a complexidade da manipulação de dados. Está disponível uma grande variedade de armazenamentos de valores-chave, com extensões variadas de suporte para funções relacionadas. As ferramentas NoSQL se enquadram nessa categoria e em outras.

Esse é o caminho óbvio para expandir quando o seguinte descreve seu aplicativo:

• É invulgarmente dependente de leitura pesada
• Você concorda com a troca de desempenho superior por garantias de consistência mais baixa (a curto prazo) (muitas oferecem "consistência eventual").
• Está gerenciando "diretamente" a maior parte da manipulação de dados e a falta de consistência (na prática, você provavelmente acabará usando uma ferramenta de terceiros no início, embora eventualmente a leve para o seu aplicativo ou para uma camada intermediária personalizada escrita) .
• Você está procurando escalar massivamente a quantidade de dados que está armazenando e / ou sua capacidade de pesquisá-los, com requisitos de manipulação de dados "relativamente simples".

Há espaço de manobra aqui - você pode forçar uma melhor consistência de leitura, para leituras mais lentas. Várias ferramentas e opções fornecem APIs de manipulação de dados, indexação e outras opções, que podem ser mais ou menos adequadas para escrever facilmente seu aplicativo específico. Portanto, se os pontos acima descrevem quase completamente seu aplicativo, você pode estar "próximo o suficiente" para trabalhar com uma solução mais poderosa de armazenamento de dados.

Exemplos conhecidos: CouchDB , MongoDB , Redis , soluções de armazenamento em nuvem como o Azure da Microsoft , o Google App Data Store e o ECE da Amazon.

Mecanismos de manipulação de dados mais complexos

A família "SQL" de aplicativos de armazenamento de dados, bem como vários outros, são melhor descritos como ferramentas de manipulação de dados do que os mecanismos de armazenamento puro. Eles fornecem uma ampla gama de funcionalidades adicionais, além do armazenamento de dados e, muitas vezes, além do que está disponível no armazenamento de valores-chave. Você deseja seguir esse caminho quando:

• Você absolutamente precisa ter consistência de leitura, mesmo que isso signifique que você sofrerá um impacto no desempenho.
• Você deseja executar com eficiência manipulação de dados altamente complexa - pense em operações JOIN e UPDATE muito complexas, cubos e fatias de dados , etc.
• Você concorda com a rigidez do desempenho (pense em formatos de armazenamento de dados fixos e forçados, como tabelas, que não podem ser alteradas com facilidade e / ou eficiência).
• Você tem os recursos para lidar com um conjunto de ferramentas e interfaces muitas vezes mais complexo.

Essa é a maneira mais "tradicional" de pensar em um banco de dados ou repositório de dados e existe há muito mais tempo - portanto, há muito disponível aqui e muitas vezes há muita complexidade para lidar. É possível, embora exija alguma experiência e conhecimento e construa soluções simples / evite grande parte da complexidade - você provavelmente acabará usando ferramentas e bibliotecas de terceiros para gerenciar a maior parte disso para você.

Exemplos bem conhecidos são MySQL , SQL Server , Oracle's Database e DB2 .

Terceirize o trabalho

Existem várias ferramentas e bibliotecas modernas de terceiros, que se interpõem entre suas ferramentas de armazenamento de dados e seu aplicativo, para ajudá-lo a gerenciar a complexidade.

Eles tentam inicialmente retirar a maior parte ou todo o trabalho necessário para gerenciar e manipular armazenamentos de dados e, idealmente, permitem que você faça uma transição suave para a complexidade apenas quando e se for necessário. Esta é uma área ativa de empreendedorismo e pesquisa, com alguns resultados recentes que são imediatamente acessíveis e utilizáveis.

Exemplos bem conhecidos são as ferramentas MVC ( Django , Yii ), Ruby on Rails e Datomic . É difícil ser justo aqui, pois existem literalmente dezenas de ferramentas e bibliotecas que atuam como invólucros nas APIs de vários armazenamentos de dados.

PS: se você prefere vídeos ao texto, pode assistir a alguns vídeos relacionados ao banco de dados de Rich Hickey; ele faz um bom trabalho para elucidar a maior parte do pensamento necessário para escolher, projetar e usar um armazenamento de dados.

Um sistema de arquivos se encaixa na descrição de um banco de dados NoSQL, então eu diria que você definitivamente deveria considerar usá-lo ao decidir como armazenar seus dados e não apenas descartá-los de imediato em favor do RDBMS, como algumas respostas parecem sugerir aqui.

Um problema com sistemas de arquivos (e NoSQL em geral) é lidar com relacionamentos entre dados. Se esse não é o principal bloqueador aqui, eu diria que pule o RDBMS por enquanto. Lembre-se também dos aspectos positivos do uso de um sistema de arquivos como armazenamento:

• Zero administração
• Baixa complexidade, fácil de configurar
• Funciona com qualquer sistema operacional, idioma, plataforma, bibliotecas etc.
• Somente a configuração é o diretório
• Trivial para testar
• Trivial para examinar com ferramentas existentes, fazer backup, modificar etc
• Boas características de desempenho e bem ajustado pelo sistema operacional
• Fácil para qualquer desenvolvedor entender
• Sem dependências, sem drivers extras
• O modelo de segurança é trivial de entender e é uma parte básica do sistema operacional
• Dados não acessíveis externamente

( fonte )

Os sistemas de arquivos são um tipo de banco de dados. Talvez não seja um RDBMS como todo mundo está falando, mas certamente um DB no sentido mais estrito. Você fornece chaves (nome do arquivo) para os dados de pesquisa (conteúdo do arquivo), que abstraíram o armazenamento e uma API pela qual o programa se comunica.

Então, você está usando um banco de dados. Os outros posts podem discutir sobre as virtudes de diferentes tipos de banco de dados ...

Um banco de dados é necessário se você tiver vários processos (usuários / servidores) modificando os dados. Em seguida, o banco de dados serve para impedir que eles substituam as alterações uns dos outros.

Você também precisa de um banco de dados quando seus dados são maiores que a memória. Atualmente, com a memória que temos disponível, isso realmente torna obsoleto o uso de bancos de dados em muitos aplicativos.

Sua abordagem é definitivamente melhor do que a bobagem de "bancos de dados em memória". Quais são essencialmente a sua abordagem, mas com muita sobrecarga adicionada.

Você sempre deve se perguntar se um aplicativo específico precisa de um RDBMS. Muitos aplicativos são criados com um processo de design que assume automaticamente todas as ferramentas e estruturas necessárias no início. Os bancos de dados relacionais são tão comuns e muitos desenvolvedores trabalharam em aplicativos semelhantes como antes, que são incluídos automaticamente antes do início do projeto. Muitos projetos podem se safar com isso, por isso não julgue muito severamente.

Você iniciou seu projeto sem um e ele funciona. Era mais fácil para você colocar isso em funcionamento sem esperar até o SQL. Não há nada de errado com isso.

À medida que esse projeto se expande e os requisitos se tornam mais complicados, algumas coisas se tornam difíceis de construir. Até você pesquisar e testar métodos alternativos, como você sabe qual é o melhor? Você pode perguntar aos programadores e eliminar as chamas e 'depende' para responder a essa pergunta. Depois de aprender, você pode considerar quantas linhas de código deseja escrever no seu idioma para lidar com alguns dos benefícios de um banco de dados. Em algum momento, você está reinventando a roda.

Fácil é frequentemente relativo. Existem algumas estruturas que podem criar uma página da web e conectar um formulário a uma tabela de banco de dados sem exigir que o usuário escreva nenhum código. Eu acho que se você luta com o mouse, isso pode ser um problema. Todo mundo sabe, isso não é escalável ou flexível, porque Deus não permita que você tenha acoplado tudo à GUI. Um não programador acabou de criar um protótipo; muitos YAGNI para serem encontrados aqui.

Se você preferir aprender um ORM manipulado pelo idioma de sua escolha, em vez de aprender SQL, tente, mas tente instalar, crie uma tabela e extraia alguns dados de um banco de dados popular com SQL (Select * From; coisas alucinantes). É fácil de fazer. É por isso que alguém os criou em primeiro lugar. Não parece um investimento tão grande para tomar uma decisão informada. Você provavelmente poderia fazer um teste de desempenho também.

Salvar os dados no disco É gravá-los em um banco de dados, especialmente se você colocar cada objeto em seu próprio arquivo, sendo o nome do arquivo a chave do registro. E para minimizar os tempos de pesquisa para a leitura do arquivo, crie subdiretórios com base nos primeiros caracteres da chave.

Por exemplo, key = ghostwriter iria em g / ho / stwriter.json ou g / h / o / stwriter.json ou g / ho / ghostwriter.json ou g / h / o / ghostwriter.json. Escolha seu esquema de nomeação com base na distribuição de suas chaves. Se eles são números de sequência, 5/4/3 / 12345.json é melhor do que o contrário.

Esse é um banco de dados e, se fizer tudo o que você precisa, faça dessa maneira. Atualmente, isso seria chamado de banco de dados NoSQL como GDBM ou Berkeley db. Tantas escolhas. Primeiro, descubra o que você precisa, depois crie uma biblioteca de interfaces para lidar com os detalhes, talvez uma interface get / set como memcached ou uma interface CRUD, e então você poderá trocar as bibliotecas se precisar alterar o formato do banco de dados por um com características diferentes.

Observe que alguns bancos de dados SQL, como PostgreSQL e Apache Derby DB, permitirão que você faça consultas SQL sobre muitos formatos NoSQL, incluindo seus próprios bancos de dados locais. Não tenho certeza sobre o MyBatis, mas pode ser semelhante.

Evite o hype do NoSQL. Leia sobre os recursos, teste o desempenho e a capacidade e escolha com base em quão bem ele corresponde às necessidades do seu aplicativo.

http://www.hdfgroup.org/HDF5/ é outro formato de armazenamento de dados interessante e amplamente usado que as pessoas nem sempre consideram.

Assim que os dados forem atualizados simultaneamente, a abordagem que usa um banco de dados (pode ser um banco de dados na memória) provavelmente será mais correta e com melhor desempenho, enquanto ao mesmo tempo seu código permanece fácil, porque você simplesmente não possui se preocupar com atualizações simultâneas, transações, cache, E / S assíncrona e tudo mais.

Você precisa de um banco de dados para armazenar / recuperar QAs como os que estamos publicando aqui! Um arquivo simples não pode organizar dados relacionados a diferentes tópicos.