Windows / Linuxがリレーショナルデータベース（RDBMS）を使用しないのはなぜですか？

Windows / Linuxがリレーショナルデータベース（RDBMS）を使用しないのはなぜですか？

ファイルシステムを使用してすべてのデータを保存していることは知っていますが、Webサイト/ Webアプリで使用しているようなデータベースを使用する方が効率的だと思いませんか？

ストレージ用のデータベースを介したファイルシステムの使用について詳しく説明してください。

これは、テキストファイルからのデータの解析よりもデータベースの使用を優先すべき場合の重複ではありませんか？私はオペレーティングシステムのコンテキストのみの観点から話しているが、その質問は一般化されている。

今日、ほとんどのデータベース管理システム（例：PostGreSQL、MongoDBなど）は、内部的にOSファイル内にデータを保持しています（過去、一部のDBMSはrawディスクパーティションを直接使用していました）。

^{まだ回転しているハードディスクを使用している最近のコンピューターでは、ディスクはCPUまたはRAMに比べて非常に遅いため、いくつかのソフトウェアレイヤーを追加することは関係ありません。SSDテクノロジーはそれを少し変えるかもしれず、いくつかのファイルシステムはSSD向けに最適化されています。}

ファイル歴史的および社会的な理由ではほとんどのOSに存在します（特に、Cコンパイラーとほとんどのツール（エディター、リンカー）はファイルを必要とするため、鶏肉と卵の問題があります）。システム実装。

ところで、いくつかの重要なシステム機能はデータベースを使用できます。たとえば、Linux PAMはデータベース内の情報を使用するように構成できます（ただし、これは実際にはほとんど行われません）。また、一部のメールサーバーは、そのデータの一部またはほとんどをデータベース（Eximなど）に保存します。

ファイルはデータベースよりもやや抽象度が低いため、（LinuxカーネルのファイルシステムとVFSレイヤーとして）実装が簡単で、使用も高速です。特に、ファイルに対する操作は、データベースに対する操作よりもはるかに制限されています。実際、ファイルまたはファイルシステムは非常に制限されたデータベースとして見ることができます！

あなたがデザインすることができ、オペレーティングシステムを任意のファイルをせずに、他のいくつかの直交して永続機械（例えば、すべての持つプロセスは永続的で、その後はあまり気にしない、明示的に OSが永続的なリソースを管理しているため、ストレージについて）。これは、いくつかのアカデミックオペレーティングシステム^（1）（および1980年代のSmalltalkおよびLispマシン、IBM System i（別名AS / 400）、およびosdevからリンクされた一部のおもちゃプロジェクトでも行われました。）、しかし、この方法でOSを設計する場合、多くの既存のツールを活用することはできません（たとえば、コンパイラとユーザーインターフェイスをゼロから作成する必要があり、それは多くの作業です）。

ことをお知らせマイクロカーネルのファイルシステムは、単にアプリケーションサーバ（例えばのHurdあるため、オペレーティングシステムは、カーネル層によって提供されるファイルを必要としない場合があります翻訳者ユーザランドで動作しています）。今日のMirageOSのユニカーネルアプローチもご覧ください。

Linux（およびおそらくVMS＆Unixからインスピレーションのほとんどを得たWindows ）は、機能するためにファイルを必要とします。少なくとも、initプログラム（カーネルによって開始される最初のプログラム）は、ファイルに保存された実行可能ファイルである必要があり（多くの場合/sbin/init、最近ではsystemdである可能性があります）、そして（ほぼ）他のすべてのプログラムはexecve（2 ） syscallはファイルに保存する必要があります。ただし、FUSEを使用すると、ファイルのような意味をファイル以外のものに与えることができます。

また、Linux（およびおそらく私が知らず、使用したことのないWindowsでも）sqliteは、ファイル内のSQLデータベースを管理し、そのAPIを提供するライブラリです。Androidは広く知られています（Linuxの亜種）は多くのsqliteファイルを使用するます（ただし、POSIXのようなファイルシステムはまだあります）。

アプリケーションのチェックポイント設定についてもお読みください（現在の多くのOSでは、プロセスの状態をファイルに書き込むために実装されています）。極端に言えば、このアプローチでは、アプリケーションファイルを手動で書き込む必要はありません（ただし、チェックポイント設定機構を使用してプロセス状態全体を永続化するためだけです）。

実際、興味深い質問は、現在のオペレーティングシステムがまだファイルを使用する理由であり、その答えはレガシーであり、経済的および文化的な理由です（残念ながら、今日のほとんどのプログラミング言語とライブラリは依然としてファイルを必要としています）。

注1：永続的なアカデミックOSにはLisaacおよびGrasshopperが含まれますが、これらのアカデミックプロジェクトは非アクティブのようです。http://tunes.org/もご覧ください。非アクティブですが、そのようなトピックに関する多くの議論が行われています。

注2：ファイルの概念は、時間の経過とともに大きく変化しました（私の最初のプログラミング体験に関するこの回答をご覧ください）：1980年代のIBM PC（ディレクトリなし！）での最初のMSDOS、1978 VaxenのVMS-（両方とも固定レコードファイルとシーケンシャルファイル、プリミティブバージョン管理システム）、1970年代のメインフレーム（OS / VS2 MVSを備えたIBM / 370）は、ファイルとファイルシステムの概念がまったく異なっていました（特に、ハードディスクアクセス時間とコアメモリアクセス時間は、数千人だった-ので、その時のディスクRANで比較的速く、今日よりも、今日のディスクがある場合でも、絶対に前世紀よりも高速で、今日のCPU /ディスク速度比は約100万です。しかし、現在SSDがあります）。また、ファイルが小さい（あるいはしない）便利なメモリが永続的である場合には（上のようCAB500、または使用して、将来のコンピュータの磁気ドラム、1960 MRAMを）

これは意見に基づくものですが、私はそれが単なる歴史的遺物だと思います。初期のOSは、その時点で使用可能なハードウェアの特性にかなり強く結び付けられたパフォーマンスのために単純なファイルシステム設計を使用していましたが、それ以来同じ方法でした。トランザクションクエリ/挿入APIが確立されたら、古いファイルの読み取り/書き込みAPIを変更することは困難です。

現在のすべてのファイルシステムには、これらの古いAPIとの下位互換性が必要です。

Microsoftは、Longhornの開発において、ファイルシステムをRDBMSベースのものに置き換えることを考えていました。彼らにとってはあまりにも大きな変化でしたが、Windows Search（RDBMSを使用してメタデータのコピーを保存する）とSQL ServerのFilestreamシステム（ファイルデータのデータベーステーブルは通常のディレクトリとしてOSに公開され、Windows Explorerからのデータへのアクセスと、同じデータのSQLクエリの両方が可能になります）。

他のOSにはRDBMSファイルシステムがあります。AS / 400にはこれらがありましたが、私はそれらについて十分に学んだことはありませんでした。当時、それがどれほど奇妙に見えたか覚えています）。他のメインフレームシステムにも同じようなアプローチがあると思います。

本当の理由はそれの必要性の欠如です。ファイルをマージするのではなく、ファイルの上に階層化することで、少なくとも大部分の状況と、大幅に複雑さを軽減したマージされたソリューションを処理します。他の人が述べたいくつかの状況では、データベースの上部にファイルの一部を階層化しています（権限構造など）。その場合、これらの権限を管理するデータベースは、市販のRDBMSよりも著しく単純です。

それらをマージすることには利点がありますが、これまでのところそれらはほとんどなく、その動きはゆっくりと成長しています。「2010年以降に受け取ったすべての請求書の3列目をまとめて合計する」、または「Excelから削除するまでこのファイルを削除させない」と言うのは非常にまれです。スプレッドシートも。」

ファイルシステムには、リレーショナルデータベースよりも優れたいくつかの利点があります。

• 彼らははるかに簡単です。これは、コンピューターをブートストラップするときに大きな問題です。ストレージ用のRDBMSがあるAndroidでも、初期ブートロードプロセスを管理するための単純な古いイメージがあります。
  • 制限を定義する方が簡単です。無制限のマシンでは、RDBMは非常に多くのパワーを提供します。ただし、ファイルシステムの世界では、回転するディスクの上に直接レイヤリングするときに高速にしようとすることに起因する多くの制限があります。RDBMSクエリがこれらの制限を超えないことを証明することは、ファイルシステムに同じ保証を提供することよりも困難です。
• 階層構造をより適切に処理します。多くの場合、人々がファイルを階層形式で保存することは依然として自然です。RDBMSesでは、これは特別なケースです。ファイルシステムはその特別な場合に最適化されますが、RDBMSはそうではありません。
• 信頼性。1つの巨大なシステムが完全に機能することを証明するよりも、2つの層が独立して機能することを証明する方がはるかに簡単です。RAIDアレイ、停電時のフェイルセーフジャーナル、およびその他の高度な機能は、ACIDや外部キーの制約などを処理するレイヤーの下のレイヤーに実装するのが簡単です。

他の答えは、オペレーティングシステムが内部/排他的にリレーショナルデータベースに依存しない理由について、幅広い範囲の理由を提供していると思うので、つまずいた興味深い情報を共有します。

どうやら、使用が正当化されたときに、リレーショナルデータベースをファイルシステムとしてマウントできるテクノロジがあります。Oracle DBFS（データベースファイルシステム）は一例です。このドキュメントの抜粋は、その背後にある理論的根拠を非常によく説明しています。

データベースファイルシステム（DBFS）は、データベースの機能を活用してファイルを保存し、リレーショナルデータを効率的に管理するデータベースの長所を活用して、データベースに保存されたファイルの標準ファイルシステムインターフェイスを実装します。このインターフェイスを使用するBLOBと、データベースへのファイルの保存は、使用するために特別に作成されたプログラムやCLOBプログラムインターフェイスに限定されなくなります。データベース内のファイルは、ファイルに作用するオペレーティングシステム（OS）プログラムを使用して透過的にアクセスできるようになりました。

このソリューションは、データベーステーブルに格納されているLOBデータ用の一連のインターフェイス（コマンドラインクライアント、コードライブラリ）を提供します。これは、WindowsおよびLinuxオペレーティングシステムで使用できます（私が知る限り、統合レベルはシステム間で異なります）

ソース：docs.oracle.com

ドキュメントによると、ファイルシステムはLinuxで透過的に使用できるはずです。

Linuxでは、dbfs_clientユーザー空間のファイルシステム（FUSE）カーネルモジュールを利用して、データベースに保存されているファイルへの透過的なアクセスを提供し、Linuxカーネルの変更を必要としないファイルシステムマウントポイントを実装するマウントインターフェイスもあります。FUSEカーネルモジュールから標準のファイルシステムコールを受信し、DBFS Content StoreのPL / SQLプロシージャへのOCIコールに変換します。

したがって、あなたの質問に対する答えは、一般に、オペレーティングシステムがリレーショナルデータベースをファイルシステムとして使用する理由はないということです（OSのコアコンポーネントの場合、これは実際に面倒です）。同時に、何らかの問題がそれを必要とするときに、それを行うことは可能です。

OSの主な機能は、アプリケーション、ハードウェア、ユーザー間の相互作用を促進することです。

では、なぜWindows / Linux OSはリレーショナルデータベース（RDBMS）を使用しないのですか？これは聖書的な割合の問題ですが、簡単な答えは次のとおりです。ファイルシステムとしてrdbmsなどの複雑な構造を使用することから得られる本当の利点はありません。

「リレーショナル」は「リレーショナルデータベース」の有効な単語であり、ファイルシステムに保存されているほとんどのデータは他のデータとは無関係です。通常、ファイルシステムは、リレーショナルデータベースではなく、限られたデータベースとして実装されます。