Por que o Windows / Linux não usa bancos de dados relacionais (RDBMS)?

Por que o Windows / Linux não usa bancos de dados relacionais ( RDBMS )?

Sei que eles usam sistemas de arquivos para armazenar todos os dados, mas você não acha que é mais eficiente usar bancos de dados como usamos em sites / aplicativos da web?

Por favor, elabore o uso de um sistema de arquivos em um banco de dados para armazenamento.

Esta não é uma duplicata de Quando o uso do banco de dados deve ser preferido em vez de analisar dados de um arquivo de texto? Estou falando apenas em contextos de sistema operacional, e essa pergunta é generalizada.

Hoje, a maioria dos sistemas de gerenciamento de banco de dados (por exemplo , PostGreSQL , MongoDB , etc ...) mantém internamente seus dados nos arquivos do sistema operacional (no passado, alguns DBMSs usavam partições de disco bruto diretamente).

^{Em computadores recentes que ainda usam discos rígidos giratórios , o disco é tão lento - em relação à CPU ou à RAM - que adicionar algumas camadas de software não é relevante. A tecnologia SSD pode mudar um pouco isso, e alguns sistemas de arquivos são otimizados para SSDs.}

Os arquivos estão presentes na maioria dos sistemas operacionais em geral por razões históricas e sociais (em particular, compiladores C e a maioria das ferramentas - editores, vinculadores - desejam arquivos, para que haja um problema de galinha e ovo) e porque há muitos arquivos muito bons implementações de sistema .

BTW, algumas instalações essenciais do sistema podem usar bancos de dados. Por exemplo, no Linux, o PAM pode ser configurado para usar informações nos bancos de dados (mas isso raramente é feito na prática). Além disso, alguns servidores de correio podem armazenar alguns ou a maioria de seus dados em bancos de dados (por exemplo, Exim ).

Os arquivos são abstrações ligeiramente mais baixas que os bancos de dados, para que possam ser mais fáceis de implementar (como os sistemas de arquivos e a camada VFS no kernel do Linux) e mais rápidos de usar. Em particular, as operações nos arquivos são muito mais restritas que as nos bancos de dados. De fato, você pode ver arquivos ou sistemas de arquivos como alguns bancos de dados muito restritos!

Você pode projetar um sistema operacional sem arquivos , mas com algum outro mecanismo de persistência ortogonal (por exemplo, tendo todos os processos persistentes, você não se importa muito explicitamente com o armazenamento, pois o sistema operacional está gerenciando recursos persistentes). Isso foi feito em vários sistemas operacionais acadêmicos ⁽¹⁾ (e também nas máquinas Smalltalk e Lisp da década de 1980, de alguma forma no IBM System i , também conhecido como AS / 400 , e em alguns projetos de brinquedos vinculados pelo osdev), mas quando você projeta seu sistema operacional dessa maneira, não pode aproveitar muitas ferramentas existentes (por exemplo, você também precisa criar seu compilador e sua interface com o usuário do zero, e isso é muito trabalhoso).

Observe que os sistemas operacionais de microkernel podem não precisar de arquivos fornecidos pelas camadas do kernel, pois os sistemas de arquivos são apenas servidores de aplicativos (por exemplo, tradutores Hurd em execução na terra do usuário). Veja também a unikernel abordagem de hoje MirageOS

O Linux (e provavelmente o Windows, que se inspirou mais no VMS e no Unix ) precisam de arquivos para funcionar. No mínimo, o programa init (o primeiro programa iniciado pelo kernel) deve ser um executável armazenado em um arquivo (geralmente /sbin/init, mas atualmente pode ser systemd ), e (quase) todos os outros programas são iniciados com execve (2). ) syscall, portanto, deve ser armazenado em um arquivo No entanto, o FUSE permite que você dê semânticas semelhantes a arquivos para coisas que não são arquivos.

Observe também que no Linux (e talvez até no Windows, que eu não conheço e nunca usei), o sqlite é uma biblioteca que gerencia alguns bancos de dados SQL em arquivos e fornece uma API para isso. É sabido que o Android (uma variante do Linux) usa muitos arquivos sqlite (mas ainda possui um sistema de arquivos semelhante ao POSIX).

Leia também sobre o ponto de verificação do aplicativo (que, em muitos sistemas operacionais atuais, é implementado para gravar o estado do processo nos arquivos). Levada ao extremo, essa abordagem não precisa gravar manualmente os arquivos do aplicativo (mas apenas para persistir todo o estado do processo usando o mecanismo de ponto de verificação).

Na verdade, a pergunta interessante é por que os sistemas operacionais atuais ainda usam arquivos, e a resposta é legada e por razões econômicas e culturais (infelizmente, a maioria das linguagens e bibliotecas de programação atuais ainda deseja arquivos).

Nota 1: sistemas operacionais acadêmicos persistentes incluem Lisaac & Grasshopper , mas esses projetos acadêmicos parecem estar inativos. Veja também http://tunes.org/ ; é inativo, mas teve muitas discussões sobre esses tópicos.

Nota 2: a noção de arquivo mudou bastante ao longo do tempo (veja esta resposta sobre minhas primeiras experiências de programação): o primeiro MSDOS nos PCs IBM dos anos 80 (sem diretórios!), O VMS - no Vaxen de 1978 - (ambos tinham registro fixo arquivos e arquivos seqüenciais, com um sistema de versão primitivo), os mainframes da década de 1970 ( IBM / 370 com OS / VS2 MVS ) tinham uma noção muito diferente de arquivos e sistemas de arquivos (em particular porque, na época, a proporção do tempo de acesso ao disco rígido para o tempo de acesso à memória principal era de alguns milhares - então, o disco era relativamente mais rápido do que hoje, mesmo que os discos de hoje sejam absolutamentemais rápido que no século anterior, hoje a taxa de velocidade de CPU / disco é de cerca de um milhão; mas agora temos SSDs). Além disso, os arquivos são menos (ou até não) úteis quando a memória é persistente (como no tambor magnético CAB500 , década de 1960; ou futuros computadores usando MRAM )

Embora isso seja baseado em opiniões, acho que é apenas outro artefato histórico. Os sistemas operacionais antigos usavam um design simples de sistema de arquivos para obter um desempenho razoavelmente fortemente vinculado às características do hardware disponível na época, e tem sido da mesma maneira desde então. É difícil alterar as APIs de leitura / gravação de arquivos antigos para obter mais APIs de consulta / inserção transacionais, uma vez estabelecidas.

Todos os sistemas de arquivos atuais têm um requisito de compatibilidade retroativa com essas APIs antigas.

A Microsoft pensou em substituir o sistema de arquivos por um baseado em RDBMS , no desenvolvimento Longhorn . Foi uma grande mudança para eles, mas você vê os esforços deles continuarem na forma de Pesquisa do Windows (onde um RDBMS é usado para armazenar uma cópia dos metadados) e recursos como o sistema Filestream do SQL Server (onde um A tabela do banco de dados de dados do arquivo é exposta ao sistema operacional como um diretório comum, permitindo o acesso do Windows Explorer aos dados e consultas SQL dos mesmos dados).

Outros sistemas operacionais possuem sistemas de arquivos RDBMS. Os AS / 400s costumavam ter isso, embora eu nunca aprendesse o suficiente sobre eles; Lembro-me de como parecia estranho na época). Eu acho que outros sistemas mainframe têm o mesmo tipo de abordagem.

O verdadeiro motivo é a falta de necessidade. Os bancos de dados em camadas sobre os arquivos, em vez de mesclá-los, lidam com a grande maioria das situações, pelo menos, assim como uma solução mesclada com complexidade substancialmente reduzida. Em algumas situações que outros mencionaram, também colocamos camadas de arquivos em cima dos bancos de dados (como estruturas de permissões). Nesse caso, o banco de dados que gerencia essas permissões é notavelmente mais simples que um RDBMS comercial.

Há vantagens em mesclá-los, mas até agora esses foram poucos e distantes o suficiente para que o movimento esteja crescendo lentamente. Considere como é raro as pessoas dizerem "Dê-me a terceira coluna de todas as faturas que recebi desde 2010 e as some" - ou "não me deixe excluir este arquivo até removê-lo do Excel planilha também. "

Os sistemas de arquivos têm algumas vantagens sobre os bancos de dados relacionais que os mantêm ativos:

• Eles são muito mais simples. Isso é importante quando se inicia um computador. Mesmo no Android , onde eles têm um RDBMS para armazenamento, eles têm imagens antigas simples para gerenciar o processo inicial de carregamento.
  • É mais fácil definir suas limitações. Em uma máquina ilimitada, os RDBMs fornecem bastante energia. No entanto, no mundo do sistema de arquivos, existem muitas limitações decorrentes de tentar ser rápido quando diretamente em camadas sobre um disco giratório. É mais difícil provar que uma consulta RDBMS não excede essas limitações do que fornecer as mesmas garantias para um sistema de arquivos.
• Eles lidam melhor com estruturas hierárquicas. Em muitos casos, ainda é natural que as pessoas armazenem arquivos de forma hierárquica. Em RDBMSes, esse é um caso especial. Os sistemas de arquivos otimizam para esse caso especial, RDBMSes não.
• Confiabilidade. É muito mais fácil provar que duas camadas funcionam independentemente do que provar que um sistema gigante funciona perfeitamente. Matrizes RAID , diários de segurança contra falhas em períodos de falta de energia e outros recursos avançados são mais fáceis de implementar em uma camada abaixo da camada que lida com coisas como ACID ou restrições de chave estrangeira.

Acho que as outras respostas fornecem um amplo espectro de razões pelas quais os sistemas operacionais não dependem de bancos de dados relacionais internamente / exclusivamente, por isso compartilharei uma parte interessante de informações que encontrei uma vez.

Aparentemente, existem tecnologias que permitem montar bancos de dados relacionais como sistemas de arquivos quando seu uso é justificado. O Oracle DBFS (Sistema de Arquivos de Banco de Dados) é um exemplo. Este trecho da documentação explica muito bem a lógica por trás disso:

O DBFS (Database File System) utiliza os recursos do banco de dados para armazenar arquivos e os pontos fortes do banco de dados no gerenciamento eficiente de dados relacionais, para implementar uma interface padrão do sistema de arquivos para arquivos armazenados no banco de dados. Com essa interface, o armazenamento de arquivos no banco de dados não se limita mais a programas criados especificamente para uso BLOBe CLOBinterfaces programáticas. Os arquivos no banco de dados agora podem ser acessados ​​de forma transparente usando qualquer programa de sistema operacional (SO) que atue nos arquivos.

A solução fornece um conjunto de interfaces (clientes de linha de comando, bibliotecas de códigos) para dados LOB armazenados em tabelas de banco de dados. Isso pode ser usado nos sistemas operacionais Windows e Linux (embora, tanto quanto eu saiba, o nível de integração varia entre eles)

Fonte: docs.oracle.com

De acordo com a documentação, o sistema de arquivos deve ser possível usar de maneira transparente no Linux

No Linux, ele dbfs_clienttambém possui uma interface de montagem que utiliza o FUSEmódulo do kernel do sistema de arquivos no espaço do usuário ( ) para implementar um ponto de montagem do sistema de arquivos que fornece acesso transparente aos arquivos armazenados no banco de dados e não requer alterações no kernel do Linux. Ele recebe chamadas padrão do sistema de arquivos do FUSEmódulo do kernel e as converte em chamadas OCI para os procedimentos PL / SQL no DBFS Content Store .

Portanto, a resposta para sua pergunta é que, em geral, não há razão para um sistema operacional usar um banco de dados relacional como um sistema de arquivos (e, no caso dos componentes principais de um sistema operacional, isso seria realmente problemático). Ao mesmo tempo, é possível fazê-lo quando algum problema o exigir.

A principal função de qualquer sistema operacional é facilitar as interações entre aplicativos, hardware e usuários.

Então .. por que o sistema operacional Windows / Linux não usa bancos de dados relacionais (RDBMS)? Esta é uma questão de proporções bíblicas, mas a resposta curta é: Não há nenhum benefício real a ser obtido com o uso de uma estrutura complexa como um rdbms como sistema de arquivos.

"Relacional" é a palavra operacional em "Banco de Dados Relacional" e a maioria dos dados armazenados em um sistema de arquivos não está relacionada a outros dados. Os sistemas de arquivos geralmente são implementados como bancos de dados limitados, mas não relacionais.