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

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

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 celles que 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 double de Quand faut - il utiliser la base de données préférable à l' analyse des données à partir d' un fichier texte? Je ne parle que de contextes de système d'exploitation, et cette question est généralisée.

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

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

Les 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, il existe donc un problème de type poule et œuf), et parce qu’il existe de très bons fichiers. implémentations du système .

En passant, certaines installations système essentielles peuvent utiliser des bases de données. Par exemple, sur Linux, PAM peut être configuré pour utiliser des informations dans des bases de données (mais cela est rarement fait en pratique). En outre, 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 la couche VFS 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 pourriez 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 une autre orthogonale la persistance des machines (par exemple , ayant tous les processus persistants, alors vous ne se soucient pas beaucoup 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 académiques ⁽¹⁾ (ainsi que dans les machines Smalltalk et Lisp des années 1980, dans IBM System i , AS / 400 , et dans certains projets de jouets liés à osdev).), mais lorsque vous concevez votre système d'exploitation de cette manière, 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, ce qui représente beaucoup de travail).

Notez que les systèmes d’exploitation à micro - noyau peuvent ne pas nécessiter de fichiers fournis par les couches du noyau, car ils ne sont que des serveurs d’applications (par exemple, des traducteurs Hurd fonctionnant en mode utilisateur). Regardez aussi l' approche unikernel dans MirageOS d'aujourd'hui

Linux (et probablement Windows, qui tire principalement son inspiration de VMS et Unix ) a besoin de fichiers pour fonctionner. À 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 il pourrait être systemd de nos jours), et (presque) tous les autres programmes sont lancés avec execve (2). ) syscall doit donc être stocké dans un fichier. Cependant, FUSE vous permet de donner une sémantique semblable à un fichier à des choses qui ne sont pas des fichiers.

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 qui gère une base de données SQL dans des fichiers et fournit une API pour cela. Il est bien connu qu'Android (une variante de Linux) utilise beaucoup de fichiers sqlite (mais il possède toujours un système de fichiers de type POSIX).

Lisez également sur le point de contrôle des applications (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 de l'application (mais uniquement de conserver l'état complet du processus à l'aide de la machine à points de contrôle).

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

Note 1: Les systèmes d’exploitation académiques persistants incluent Lisaac & Grasshopper , mais ces projets académiques semblent inactifs. Regardez aussi dans http://tunes.org/ ; il est inactif, mais a beaucoup de discussions autour de tels sujets.

Note 2: la notion de fichier a beaucoup évolué au fil du temps (regardez cette réponse à propos de mes premières expériences de programmation): le premier MSDOS sur PC IBM des années 1980 (pas de répertoires!), Le VMS (1978) Vaxen - (à enregistrement fixe) fichiers et fichiers séquentiels, avec un système de gestion des versions primitif), les ordinateurs centraux des années 1970 ( IBM / 370 avec OS / VS2 MVS ) avaient une notion très différente de fichiers et de systèmes de fichiers (en particulier parce qu’à leur époque le rapport temps d ’accès au disque dur Le temps d’accès à la mémoire principale était de quelques milliers d’années. Ainsi, à l’époque, le disque était relativement plus rapide qu’aujourd’hui, même si les disques actuels sont absolumentplus rapide qu'au siècle précédent, le rapport de la vitesse CPU / disque est aujourd'hui d'environ un million; mais nous avons maintenant des disques SSD). De plus, les fichiers sont moins utiles (ou même pas utiles) lorsque la mémoire est persistante (comme sur le tambour magnétique CAB500 , années 1960 ou sur les futurs ordinateurs utilisant MRAM ).

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 raisonnablement fortement liées aux caractéristiques du matériel disponible à l'époque, et ce, depuis lors. Il est difficile de remplacer les anciennes API de lecture / écriture de fichiers par d'autres API de requête / insertion transactionnelles une fois qu'elles ont été établies.

Tous les systèmes de fichiers actuels exigent une compatibilité ascendante avec ces anciennes API.

Microsoft avait envisagé de remplacer le système de fichiers par un système basé sur le SGBDR , dans le développement de Longhorn . C’était trop pour changer, 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 de fonctionnalités telles que le système Filestream de SQL Server (où La table de base de données des données de fichier est exposée au système d'exploitation sous la forme d'un répertoire ordinaire permettant à l' explorateur Windows d' accéder aux données et aux requêtes SQL des mêmes données).

D'autres systèmes d'exploitation ont des systèmes de fichiers SGBDR. Les AS / 400 en avaient l' habitude, même si je n'en ai jamais appris assez sur eux; Je me souviens à quel point il était étrange à l’époque). Je pense que d'autres systèmes mainframe ont le même type d'approche.

La vraie raison est un manque de besoin pour cela. La superposition de bases de données au-dessus des fichiers, plutôt que leur fusion, gère la grande majorité des situations au moins aussi bien qu'une solution fusionnée avec une complexité considérablement réduite. Dans certaines situations, d'autres ont mentionné, nous avons également superposé des parties de fichiers sur des bases de données (telles que des structures d'autorisations). Dans ce cas, la base de données qui gère ces autorisations est remarquablement plus simple qu’un SGBDR commercial.

Les fusionner présente des avantages, mais jusqu'à présent, ceux-ci ont été peu nombreux et suffisamment éloignés pour que le mouvement progresse lentement. Considérez combien il est rare que des 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 tant que je ne l'ai pas supprimé de Excel. tableur aussi. "

Les systèmes de fichiers présentent quelques avantages par rapport aux bases de données relationnelles:

• Ils sont beaucoup plus simples. C'est un gros problème lorsque vous démarrez un ordinateur. Même sous Android , où ils ont un SGBDR pour le stockage, ils ont d'anciennes images simples pour gérer le processus de chargement initial.
  • Il est plus facile de définir leurs limites. Dans une machine illimitée, les RDBM fournissent beaucoup de puissance. Cependant, dans le monde des systèmes de fichiers, il existe de nombreuses limitations dues au fait d’essayer d’être rapide lorsqu’il est superposé directement sur un disque en rotation. Il est plus difficile de prouver qu'une requête de SGBDR ne dépasse pas ces limites, mais de fournir les mêmes garanties pour un système de fichiers.
• Ils gèrent mieux les structures hiérarchiques. Dans de nombreux cas, il est toujours naturel pour les personnes de stocker des fichiers sous une forme hiérarchique. Dans les SGBDR, c'est un cas particulier. Les systèmes de fichiers optimisent pour ce cas particulier, pas les SGBDR.
• Fiabilité. Il est beaucoup plus facile de prouver que deux couches fonctionnent indépendamment que de prouver qu'un système géant fonctionne parfaitement. Les matrices RAID , les journaux à sécurité intégrée en cas de panne de courant et d'autres fonctionnalités avancées sont plus faciles à implémenter dans une couche située sous la couche, qui traite d'éléments tels que les contraintes de clé étrangère ou ACID .

Je pense que les autres réponses fournissent un large éventail de raisons pour lesquelles les systèmes d’exploitation ne reposent pas exclusivement sur des bases de données relationnelles en interne, je vais donc partager un élément d’information intéressant que j’ai découvert par hasard.

Apparemment, certaines technologies 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 (système de fichiers de base de données) est un exemple. Cet extrait de la documentation explique très bien la raison d'être de celui-ci:

Le système de fichiers de base de données (DBFS) exploite les fonctionnalités de la base de données pour stocker les fichiers, ainsi que les atouts de la base de données pour la gestion efficace des données relationnelles, afin de mettre en œuvre 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 conçus pour être utilisés BLOBet CLOBaux interfaces de programmation. Les fichiers de la base de données sont désormais accessibles de manière transparente à l’aide de n’importe quel programme de système d’exploitation (OS) agissant sur les fichiers.

La solution fournit un ensemble d'interfaces (clients en ligne de commande, bibliothèques de codes) pour les données LOB stockées dans des tables de base de données. Ceci 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)

Source: docs.oracle.com

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

Sous Linux, l' dbfs_clientinterface utilisateur possède également une interface de montage qui utilise le FUSEmodule de noyau Système de fichiers du User Space ( ) pour implémenter un point de montage du système de fichiers offrant un accès transparent aux fichiers stockés dans la base de données et ne nécessitant aucune modification du noyau Linux. Il reçoit des appels de système de fichiers standard du FUSEmodule du noyau et les traduit en appels OCI aux procédures PL / SQL du magasin de contenu DBFS .

Par conséquent, la réponse à votre question est qu’en général, il n’ya aucune raison pour un système d’exploitation d’utiliser une base de données relationnelle en tant que système de fichiers (et dans le cas des composants principaux d’un système d’exploitation, cela poserait effectivement des problèmes). En même temps, il est possible de le faire quand un problème l’appelle.

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 les systèmes d’exploitation Windows / Linux n’utilisent-ils pas de bases de données relationnelles (SGBDR)? Ceci est une question de proportions bibliques, mais la réponse courte est: Il n’ya aucun avantage réel à tirer de l’utilisation d’une structure complexe telle qu’un rdbms en tant que système de fichiers.

"Relationnel" est le mot clé 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 implémentés sous forme de bases de données limitées, mais pas de bases de données relationnelles.