Pourquoi Windows / Linux n'utilise-t-il pas les bases de données relationnelles (SGBDR)?

Question

Pourquoi Windows/Linux n'utilise-t-il pas des bases de données relationnelles ( RDBMS )?

Je sais qu'ils utilisent des systèmes de fichiers pour stocker toutes les données, mais ne pensez-vous pas qu'il est plus efficace d'utiliser des bases de données comme nous utilisons dans les sites Web/applications Web?

Veuillez expliquer l'utilisation d'un système de fichiers sur une base de données pour le stockage.

Ce n'est pas un doublon de Quand faut-il utiliser la base de données plutôt que d'analyser les données d'un fichier texte? Je parle en termes de contextes de système d'exploitation uniquement, et cette question est généralisée.

Basile Starynkevitch · Accepted Answer

Aujourd'hui, la plupart des systèmes de gestion base de données (par exemple PostGreSQL , MongoDB , etc ...) conservent en interne leurs données dans des fichiers OS (dans le passé, certains SGBD utilisaient directement des partitions de disque brutes).

^{Sur les ordinateurs récents utilisant encore la rotation disques durs , le disque est si lent - par rapport au CPU ou au RAM - que l'ajout de quelques couches logicielles n'est pas pertinent. - SSD la technologie peut changer cela un peu, et certains systèmes de fichiers sont optimisés pour les SSD.}

Fichiers sont présents dans la plupart des systèmes d'exploitation en général pour des raisons historiques et sociales (en particulier, les compilateurs C et la plupart des outils - éditeurs, éditeurs de liens - veulent des fichiers, donc il y a un problème de poulet et d'oeufs), et parce qu'il sont beaucoup de très bonnes implémentations système de fichiers .

BTW, certaines installations système essentielles peuvent utiliser des bases de données. Par exemple sous Linux PAM peut être configuré pour utiliser les informations dans les bases de données (mais cela est rarement fait en pratique). De plus, certains serveurs de messagerie peuvent stocker une partie ou la plupart de leurs données dans des bases de données (par exemple Exim ).

Les fichiers sont des abstractions légèrement inférieures aux bases de données, ils peuvent donc être plus faciles à implémenter (comme les systèmes de fichiers et VFS couche dans le noyau Linux) et plus rapides à utiliser. En particulier, les opérations sur les fichiers sont beaucoup plus restreintes que celles sur les bases de données. En fait, vous pouvez voir des fichiers ou des systèmes de fichiers comme des bases de données très restreintes!

Vous pouvez concevoir un système d'exploitation sans aucun fichier , mais avec d'autres machines orthogonales persistance ( par exemple, avoir tous les processus être persistants, alors peu vous importe explicitement sur le stockage, car le système d'exploitation gère les ressources persistantes). Cela a été fait dans plusieurs systèmes d'exploitation universitaires⁽¹⁾ (et aussi dans Smalltalk et machines LISP des années 80, en quelque sorte dans IBM System i , aka AS/400, et dans certains projets de jouets liés depuis osdev ), mais lorsque vous concevez votre système d'exploitation de cette façon, vous ne pouvez pas tirer parti de nombreux outils existants (par exemple, vous devez également créer votre compilateur et votre interface utilisateur à partir de zéro, et c'est un beaucoup de travail).

Notez que microkernel les systèmes d'exploitation peuvent ne pas avoir besoin de fichiers fournis par les couches du noyau car les systèmes de fichiers ne sont que des serveurs d'applications (par exemple Hurd traducteurs fonctionnant dans l'espace utilisateur). Regardez aussi l'approche nikernel dans le MirageOS d'aujourd'hui

Linux (et probablement Windows, qui s'est inspiré de VMS & nix ) ont besoin de fichiers travailler. À tout le moins, le programme init (le premier programme démarré par le noyau) doit être un exécutable stocké dans un fichier (souvent /sbin/init, mais cela pourrait être systemd ces jours-ci), et (presque) tous les autres programmes sont démarrés avec execve (2) syscall doivent donc être stockés dans un fichier. Cependant, Fuse vous permet de donner une sémantique de type fichier à des choses non-fichier.

Notez également que sous Linux (et peut-être même Windows, que je ne connais pas et que je n'ai jamais utilisé) sqlite est une bibliothèque gérant une base de données SQL dans des fichiers et fournissant une API pour cela. Il est bien connu que Android (une variante Linux) utilise beaucoup de fichiers sqlite (mais il a toujours un système de fichiers de type POSIX).

Lisez aussi à propos de application checkpointing (qui, sur de nombreux systèmes d'exploitation actuels, est implémenté pour écrire l'état du processus dans des fichiers). Poussée à l'extrême, cette approche n'a pas besoin d'écrire manuellement les fichiers d'application (mais uniquement pour conserver l'état du processus entier à l'aide de la machinerie de point de contrôle).

En fait, la question intéressante est de savoir pourquoi les systèmes d'exploitation actuels utilisent toujours des fichiers, et la réponse est héritée et pour des raisons économiques et culturelles (malheureusement, la plupart des langages de programmation et des bibliothèques veulent toujours des fichiers).

Note 1: les OS académiques persistants incluent Lisaac & Grasshopper , mais ces projets académiques semblent être inactifs. Regardez aussi dans http://tunes.org/ ; il est inactif, mais a suscité de nombreuses discussions sur ces sujets.

Note 2: la notion de fichier a largement évolué au fil du temps (regardez ce réponse sur mes premières expériences de programmation): la première MSDOS = sur les PC IBM des années 1980 (pas de répertoires!), le VMS - sur 1978 Vaxen avait à la fois des fichiers à enregistrement fixe et des fichiers séquentiels, avec un système de version primitif), les mainframes des années 1970 (--- (IBM/37 avec OS/VS2 MVS ) avait une notion très différente des fichiers et des systèmes de fichiers (en particulier parce qu'à leur époque le rapport du temps d'accès au disque dur au temps d'accès à la mémoire centrale était quelques milliers - donc à cette époque le disque fonctionnait relativement plus vite qu'aujourd'hui, même si les disques d'aujourd'hui sont absolument plus rapides qu'au siècle précédent, aujourd'hui le CPU/le rapport de vitesse du disque est d'environ un million; mais nous avons maintenant des SSD). De plus, les fichiers sont moins (ou même pas) utiles lorsque la mémoire est persistante (comme sur CAB5 tambour magnétique, années 1960; ou les futurs ordinateurs utilisant MRAM )

gbjbaanb · Answer

Bien que ce soit basé sur l'opinion, je pense que c'est juste un autre artefact historique. Les premiers systèmes d'exploitation utilisaient une conception de système de fichiers simple pour des performances qui était raisonnablement fortement liée aux caractéristiques du matériel disponible à l'époque, et c'est la même chose depuis. Il est difficile de modifier les anciennes API de lecture/écriture de fichier pour plus d'API de requête/insertion transactionnelles une fois qu'elles ont été établies.

Tous les systèmes de fichiers actuels doivent être rétrocompatibles avec ces anciennes API.

Microsoft a pensé à remplacer le système de fichiers par un basé sur RDBMS , dans le développement Longhorn . C'était trop de changement pour eux, mais vous voyez que leurs efforts se poursuivent sous la forme de Windows Search (où un SGBDR est utilisé pour stocker une copie des métadonnées) et des fonctionnalités telles que Filestream de SQL Server système (où une table de base de données de données de fichiers est exposée au système d'exploitation en tant que répertoire ordinaire permettant à la fois Explorateur Windows l'accès aux données et les requêtes SQL des mêmes données).

D'autres systèmes d'exploitation ont des systèmes de fichiers RDBMS. AS/400s en possédait, même si je n'en ai jamais assez appris à leur sujet; Je me souviens à quel point c'était étrange à l'époque). Je pense que d'autres systèmes mainframe ont le même type d'approche.

Cort Ammon · Answer

La vraie raison est son manque de nécessité. Placer des bases de données sur des fichiers, plutôt que de les fusionner, gère au moins la grande majorité des situations ainsi qu'une solution fusionnée avec une complexité considérablement réduite. Dans certaines situations que d'autres ont mentionnées, nous avons également superposé des parties de fichiers au-dessus des bases de données (telles que les structures d'autorisations). Dans ce cas, la base de données gérant ces autorisations est remarquablement plus simple qu'un SGBDR commercial.

Il y a des avantages à les fusionner, mais jusqu'ici ceux-ci ont été peu nombreux et assez éloignés entre eux pour que le mouvement se développe lentement. Considérez à quel point il est rare que les gens disent "Donnez-moi la 3ème colonne de chaque facture que j'ai reçue depuis 2010 et additionnez-les" ou "ne me laissez pas supprimer ce fichier avant de l'avoir supprimé d'Excel feuille de calcul également. "

Les systèmes de fichiers ont quelques avantages par rapport aux bases de données relationnelles qui les maintiennent:

toniedzwiedz · Answer

Je pense que les autres réponses fournissent un large éventail de raisons pour lesquelles les systèmes d'exploitation ne s'appuient pas sur des bases de données relationnelles en interne/exclusivement, je vais donc partager une information intéressante sur laquelle je suis tombé une fois.

Apparemment, il existe des technologies qui vous permettent de monter des bases de données relationnelles en tant que systèmes de fichiers lorsque leur utilisation est justifiée. Oracle DBFS (Database File System) est un exemple. Cet extrait de la documentation explique assez bien la raison de cela:

Le système de fichiers de base de données (DBFS) exploite les fonctionnalités de la base de données pour stocker des fichiers et les atouts de la base de données dans la gestion efficace des données relationnelles, pour implémenter une interface de système de fichiers standard pour les fichiers stockés dans la base de données. Avec cette interface, le stockage de fichiers dans la base de données n'est plus limité aux programmes spécifiquement écrits pour utiliser les interfaces de programmation BLOB et CLOB. Les fichiers de la base de données sont désormais accessibles de manière transparente à l'aide de tout programme de système d'exploitation (OS) qui agit sur les fichiers.

La solution fournit un ensemble d'interfaces (clients en ligne de commande, bibliothèques de codes) pour les données LOB qui sont stockées dans des tables de base de données. Cela peut être utilisé sur les systèmes d'exploitation Windows et Linux (bien que pour autant que je sache, le niveau d'intégration varie entre eux)

Oracle DBFS components

Source: docs.Oracle.com

Selon la documentation, le système de fichiers devrait pouvoir être utilisé de manière transparente sous Linux

Sous Linux, le dbfs_client possède également une interface de montage qui utilise le module de noyau Système de fichiers dans l'espace utilisateur (Fuse) pour implémenter un point de montage du système de fichiers qui fournit un accès transparent aux fichiers stockés dans la base de données et ne nécessite aucune modification de Linux noyau. Il reçoit les appels de système de fichiers standard du module de noyau Fuse et les traduit en [~ # ~] oci [~ # ~] appels aux procédures PL/SQL dans le DBFS Content Store .

Par conséquent, la réponse à votre question est qu'en général, il n'y a aucune raison pour qu'un système d'exploitation utilise une base de données relationnelle comme système de fichiers (et dans le cas des composants principaux d'un système d'exploitation, cela serait en fait gênant). En même temps, il est possible pour quelqu'un de le faire lorsqu'un problème l'exige.

Nik Pfirsig · Answer

La fonction principale de tout système d'exploitation est de faciliter les interactions entre les applications, le matériel et les utilisateurs.

Alors ... pourquoi le système d'exploitation Windows/Linux n'utilise-t-il pas les bases de données relationnelles (SGBDR)? C'est une question de proportions bibliques, mais la réponse courte est: il n'y a aucun avantage réel à tirer de l'utilisation d'une structure complexe telle qu'un rdbms comme système de fichiers.

"Relationnel" est le mot opérationnel dans "Base de données relationnelle" et la plupart des données stockées dans un système de fichiers ne sont pas liées à d'autres données. Les systèmes de fichiers sont généralement mis en œuvre en tant que bases de données limitées, mais pas relationnelles.