web-dev-qa-db-ja.com

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

Windows/Linuxがリレーショナルデータベースを使用しないのはなぜですか( [〜#〜] rdbms [〜#〜] )?

私は彼らがすべてのデータを保存するためにファイルシステムを使用していることを知っていますが、私たちがWebサイト/ Webアプリで使用するようなデータベースを使用する方が効率的ではないでしょうか?

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

これは テキストファイルからのデータの解析よりもデータベースの使用を優先する必要がある場合 の複製ではありません。

32
Pratik

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

まだ回転している最近のコンピューター ハードディスク は、ディスクが非常に遅い-CPUまたはRAM-に比べると、いくつかのソフトウェアレイヤーの追加は関係ありません。 [〜#〜] ssd [〜#〜] テクノロジーによって少し変化する可能性があり、一部のファイルシステムはSSD用に最適化されています。

Files は、歴史的および社会的な理由から、ほとんどのOSに一般的に存在します(特に、Cコンパイラとほとんどのツール-エディタ、リンカー-ファイルが必要なので、鶏肉と卵の問題があります)非常に良い ファイルシステム 実装がたくさんあります。

ところで、いくつかの重要なシステム設備はデータベースを使用できます。たとえば、Linuxの場合 [〜#〜] pam [〜#〜] は、データベースの情報を使用するように構成できます(ただし、実際にはほとんど行われません)。また、一部のメールサーバーは、一部またはほとんどのデータをデータベースに格納する場合があります(例 Exim )。

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

オペレーティングシステム ファイルなしで設計できますが、他の直交 永続性 機構(たとえば、すべての プロセス が永続的である場合、OSは永続的なリソースを管理しているため、ストレージについては明示的に気にしません。これは、いくつかの学術オペレーティングシステムで行われています(1) (また、1980年代のSmalltalkおよび LISPマシン では、どういうわけか IBM System i 、別名AS/400 、および osdev )からリンクされている一部のおもちゃプロジェクトでは、この方法でOSを設計すると、多くの既存のツールを活用できません(たとえば、コンパイラとユーザーインターフェイスを最初から作成する必要があります)。それは大変な作業です)。

ファイルシステムは単なるアプリケーションサーバーであるため、 microkernel オペレーティングシステムはカーネルレイヤーによって提供されるファイルを必要としない可能性があることに注意してください(例:Hurd translators ユーザーランドで実行)。今日の nikernel アプローチも見てください MirageOS

Linux (そしておそらく [〜#〜] vms [〜#〜]nix )からインスピレーションを得たWindowsにはファイルが必要仕事に。少なくとも、 init プログラム(カーネルによって開始される最初のプログラム)は、ファイル(多くの場合/sbin/init、ただし systemd 最近)、および(ほぼ)他のすべてのプログラムは execve(2) syscallで開始されるため、ファイルに保存する必要があります。ただし、 Fuse を使用すると、ファイル以外のものにファイルのようなセマンティクスを与えることができます。

Linux(そしておそらくWindowsでさえ、私も知らず、使用したこともない)では sqlite は、ファイル内のSQLデータベースを管理し、そのためのAPIを提供するライブラリであることにも注意してください。 Android (Linuxバリアント)が多くのsqliteファイルを使用することは広く知られています(ただし、POSIXに似たファイルシステムはまだあります)。

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

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


注1:永続的なアカデミックOSには LisaacGrasshopper が含まれますが、これらのアカデミックプロジェクトはアクティブではないようです。 http://tunes.org/ も確認してください。それは非アクティブですが、そのようなトピックに関して多くの議論をしています。

注2:ファイルの概念は時間の経過とともに大きく変化しました(- this 最初のプログラミングエクスペリエンスについての回答をご覧ください):最初の [〜#〜] msdos [〜#〜] = 1980年代のIBM PC(ディレクトリなし!)、VMS -on 1978 Vaxen固定レコードファイルとシーケンシャルファイルの両方、プリミティブバージョン管理システムを使用)、1970年代のメインフレーム(--- (IBM/37 with OS/VS2 MVS )は、ファイルとファイルシステムの概念が非常に異なっていました(特に、当時のハードディスクアクセス時間とコアメモリアクセス時間の比率が数千-それで、今日のディスクが前のディスクよりも絶対に高速であっても、ディスクは今日よりも比較的速く実行された世紀、今日のCPU /ディスク速度比は約100万ですが、現在はSSDがあります)。また、メモリが永続的である場合( CAB5 磁気ドラム、1960年代など)、または [〜#〜] mram [〜#〜 ]

60

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

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

Microsoftは Longhorn 開発において、ファイルシステムを RDBMSベースのファイル に置き換えることを考えていました。それは彼らが引き出すにはあまりにも大きな変更でしたが、彼らの努力はWindows Search(RDBMSがメタデータのコピーを格納するために使用される)および SQL ServerのFilestream システム(ファイルデータのデータベーステーブルがOSに通常のディレクトリとして公開され、 Windowsエクスプローラ データへのアクセスと同じデータのSQLクエリの両方が許可されます)。

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

24
gbjbaanb

本当の理由はそれの必要性の欠如です。データベースをファイルをマージするのではなく、ファイルの上に重ねることにより、少なくともほとんどの状況と、複雑さが大幅に軽減されたマージされたソリューションを処理します。他の人が言及したいくつかの状況では、データベース(アクセス許可構造など)の上にファイルの一部を階層化しました。その場合、これらの権限を管理するデータベースは、市販のRDBMSよりも非常にシンプルです。

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

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

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

他の回答は、オペレーティングシステムがリレーショナルデータベースに内部的または排他的に依存しない理由について幅広い理由を提供していると思います。そのため、私が偶然見つけた興味深い情報を共有します。

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

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

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

Oracle DBFS components

出典:docs.Oracle.com

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

Linuxでは、dbfs_clientには、ユーザースペースのファイルシステム(Fuse)カーネルモジュールを使用してデータベースに保存されているファイルへの透過的なアクセスを提供し、Linuxへの変更を必要としないファイルシステムマウントポイントを実装するマウントインターフェイスもあります。カーネル。 Fuseカーネルモジュールから標準のファイルシステムコールを受け取り、それらを[〜#〜] oci [〜#〜]に変換します。 DBFS Content StorePL/SQLプロシージャの呼び出し.

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

3
toniedzwiedz

OSの主な機能は、アプリケーション、ハードウェア、ユーザー間のやり取りを容易にすることです。

では、なぜWindows/Linux OSはリレーショナルデータベース(RDBMS)を使用しないのですか?これは聖書の比率の問題ですが、簡単な答えは次のとおりです。ファイルシステムとしてrdbmsなどの複雑な構造を使用しても、実際に得られるメリットはありません。

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

2
Nik Pfirsig