多くのCMSがローカルファイルではなくデータベースを使用するのはなぜですか？

Question

ほとんどのオープンソースコンテンツ管理システムは、データベースを使用してフィールドデータを格納し、サーバーのディレクトリにあるファイルを使用して構成設定を行います。このモデルが頻繁に選択される理由と、フィールドデータを格納するサーバー上のファイルを維持することがそれほど効果的でないのはなぜですか？目標が大量のデータを含む大規模な専門サイトである場合、これは変わりますか？

amon · Accepted Answer

ファイルシステムはデータベースであり、具体的には、ファイルシステムに応じて、メタデータが少し追加された一種の階層型Key-Valueストアです。

ファイルシステムを使用することは、特に大規模なレコードの場合、多くの場合適切です。（ファイルシステムは、多くの場合、キロバイトのオーダーの最小レコードサイズを持っています。）ファイルシステムを正しく使用すると、データベースと同様に原子性と耐久性が保証されます。特に、データベースとジャーナリングファイルシステムはどちらも先読みロギングを使用します。

しかし、他のデータベースと比較すると、ファイルシステムには4つの重大な制限があります。

ファイルシステムを複数のサーバー間で共有することはできません。ただし、複数のサーバーが1つのデータベースサーバーに接続する場合があります。
ファイルシステムでは、ファイルはパスによってのみ索引付けされます。主キーへのソフトリンクまたはコンテンツへのハードリンクである別のパスを追加しない限り、セカンダリインデックスを追加することはできません。ファイルを変更するときは、これらのインデックスを手動で更新する必要があります。
単一のファイルに対する操作はアトミックに実行できますが、複数のファイルを含むトランザクションを作成することはできません。通常の回避策は、ロックファイルを用意することです。プロセスがこのファイルのロックを取得すると、それらは排他的な読み取りおよび書き込みアクセス権を持ちます。ロック中はファイルが不整合な状態になる可能性があるため、他の読み取りは行わないでください。プロセスがクラッシュすると、ファイルシステムが不整合な状態になる可能性があります。対照的に、RDBMSには、障害時に変更をロールバックできる適切なトランザクションがあり、他のクライアントのトランザクション前の状態を読み取ることができます。
ファイルシステムには、データの一貫性を保証する手段がありません。たとえば、外部キー制約は完全に不可能です。これにより、データのモデル化がはるかに困難になり、そのデータを読み書きする正しいアプリケーションを作成することがはるかに困難になります。

それほど深刻ではない制限は、ファイルシステムがデータベースよりも遅い場合があることです。しかし、これはユースケースとファイルシステムに大きく依存します。例えば。 ext2などの古いファイルシステムでは、ディレクトリに含まれるエントリが多すぎると、パフォーマンスが大幅に低下します。

一部のアプリケーションは、ファイルシステムをデータベースとして使用するのに適しています。たとえば、Gitはこれを非常に効果的に行いますが、不変のレコードを使用するなど、多くの固有のプロパティも持っています。

ほとんどのアプリケーションでは、RDBMSが推奨されます。アプリケーションに実装する必要がなく、ほぼ無料で多くの保証（耐久性や一貫性など）が得られます。 relationsは、Key-Valueマッピングだけでなく、データでモデル化できます。もちろん、これらの機能にはコストがかかりますが、ほとんどのアプリケーションではそのコストは気付かれません。

したがって、複数のプロセスがある場合は、RDBMSサーバーが推奨されます。

プロセスが1つしかない場合でも、RDBMSの一貫性の保証が必要な場合があります。ただし、別のサーバーを使用する代わりに、SQLiteなどの組み込みデータベースエンジンを使用できます。クエリはネットワーク経由で送信されないため、データベースサーバーよりもはるかに高速です。また、ファイルシステムを使用するよりも高速な場合があります。データアクセスごとに複数のファイルを開く代わりに、データベースエンジンは1つのファイル内をスキップするだけです。

ほとんどのCMSはPHPで実装されています。 PHPリクエストモデル（存続期間の短いプロセス、および多くのプロセスが並行して実行されている可能性があります）は、SQLiteなどの組み込みデータベースに適さないため、ファイルシステムを正しく使用することも困難にします単純なDBとして。代わりに、MariaDBやPostgreSQLなどの外部データベースサーバーが推奨されます。

システムがそのデータをデータベースに格納する場合、構成もデータベースに格納する必要はありません。通常、設定は起動時に一度だけ読み込まれ、アプリケーションによって変更されることはありません。構成データには、CMSの問題ドメインの概念（例：投稿、タグ、ユーザー、アクセス権などの関係。

Jason Rush · Answer

考慮に入れなければならないことがたくさんあります。 1つの例は、ファイルシステムの読み取りと書き込みが一般的に（比較的）遅いことです。データベースは、そのデータの大部分をRAMアクセスされるmuchより高速に保持する傾向があります。データベースは、小さな変更を行う方が優れている傾向があります（つまり、 INIファイルと、単一の行の単一のフィールドを変更する必要があるデータベースとの比較）データベースでの単一の変更でも、変更を書き込むときのファイルのようなロックの種類（さまざまな状況でデータベースでトランザクションまたはロックを使用する必要がある場合もありますが、通常はより効率的です）。

まれですが、設定ファイルが意味をなす場合もあります。