66

多数のサウンド ファイルをデータベースに保存したいのですが、それが適切かどうかわかりません。この方法のメリットとデメリットを教えていただきたいです。

また、それらのファイルへの「リンク」を作成する可能性についても考えましたが、解決策よりも多くの問題が発生する可能性があります。この方向の経験は大歓迎です:)

注: データベースは MySQL になります。

4

9 に答える 9

109

私が知っている、大量の大きなファイルを保存するすべてのシステムは、それらをデータベースの外部に保存します。ファイルのクエリ可能なすべてのデータ (タイトル、アーティスト、長さなど) を、ファイルへの部分パスと共にデータベースに保存します。ファイルを取得するときは、ファイルのパスを抽出し、ファイル ルート (または URL) を先頭に追加して、それを返します。

したがって、「a/b/c/1000」のような部分的なパスを含む「場所」列があり、「http://myserver/files/a/b/c 」にマップします。 /1000.mp3」

データの回復に必要な場合に備えて、メディア データベースを別のサーバー/ディレクトリにポイントする簡単な方法があることを確認してください。また、データベースをファイル アーカイブの内容と再同期するルーチンが必要になる場合もあります。

また、何千ものメディア ファイルがある場合は、それらすべてを 1 つの巨大なディレクトリに格納しないでください。これは、一部のファイル システムではパフォーマンスのボトルネックになります。代わりに、それらを複数のバランスの取れたサブツリーに分割します。

于 2008-09-30T20:11:41.127 に答える
18

適切な実装を使用している限り、それらをデータベースに保存しても問題ないと思います。データベース内の大量のデータがパフォーマンスに影響を与えないようにする方法に関するアイデアについては、この古いが良い記事を読むことができます。

http://www.dreamwerx.net/phpforum/?id=1

私は文字通り何百ものギグをmysqlデータベースにロードしましたが、問題はありませんでした。設計と実装が重要です。間違えると苦しむことになります。

その他の DB の利点 (まだ言及されていません): - 負荷分散された環境でより適切に機能します - より多くのバックエンド ストレージのスケーラビリティを組み込むことができます

于 2008-09-30T20:11:22.077 に答える
9

データベースを使用する利点:

  • サウンド ファイルを他のデータ ビットと簡単に結合できます。
  • データベース セキュリティをバイパスするファイル I/O 操作を回避します。
  • データベースのレコードが削除されたときにサウンド ファイルを削除するための分離操作は必要ありません。

データベースを使用するデメリット:

  • データベースの肥大化
  • データベースはファイル システムよりも高価になる可能性があります
于 2008-09-30T20:04:48.287 に答える
9

さまざまなプロジェクトで両方の方法を試してみましたが、最終的にファイル システムを使用する方が簡単であると判断しました。結局のところ、ファイル システムは、ファイルの保存、取得、およびインデックス作成用に既に最適化されています。

それについて私が持っている1つのヒントは、データベース内のファイルへの「ルート相対」パスのみを保存し、プログラムまたはクエリ/ストアドプロシージャ/ミドルウェアでインストール固有のルートパラメーターを使用してファイルを取得することです.

たとえば、XYZ.Wav を C:\MyProgram\Data\Sounds\X\ に保存する場合、フル パスは次のようになります。

C:\MyProgram\Data\Sounds\X\XYZ.Wav

ただし、パスまたはファイル名を次のようにデータベースに保存します。

X\XYZ.Wav

データベースまたはプログラムの構成ファイルの別の場所に、SoundFilePath のようなルート パスを次のように保存します。

C:\MyProgram\Data\Sounds\

もちろん、データベース パスからルートを分割する場所はユーザー次第です。そうすれば、プログラムのインストールを移動しても、データベースを更新する必要はありません。

また、多数のファイルが存在する場合は、パスをハッシュする何らかの方法を見つけて、1 つのディレクトリに数百または数千のファイルが含まれないようにします (私の小さな例では、最初の文字に基づくサブディレクトリがあります。ファイル名ですが、さらに深くするか、ランダムハッシュを使用できます)。これにより、検索インデクサーも満足します。

于 2008-09-30T20:12:02.857 に答える
5

BLOBを使用してファイルを保存することのいくつかの利点

  • 管理オーバーヘッドの削減-単一のツールを使用してバックアップ/復元など
  • データベースとファイルシステムが同期していない可能性はありません
  • トランザクション機能（必要な場合）

いくつかの欠点

  • データベースサーバーのRAMを、行やインデックスなどを格納するために使用する可能性のある無駄なゴミで爆破します
  • DBバックアップが非常に大きくなるため、管理しにくくなります
  • クライアントに提供するファイルシステムほど便利ではありません（たとえば、Webサーバーを使用）

パフォーマンスはどうですか？あなたのマイレージは異なる場合があります。ファイルシステムは非常に多様であり、データベースのパフォーマンスも非常に多様です。場合によっては、ファイルシステムが勝つことがあります（おそらく大きなファイルが少ない場合）。場合によっては、DBの方が優れていることがあります（非常に多数の小さいファイルがある場合）。

いずれにせよ、心配しないで、その時点で最善と思われることをしてください。

一部のデータベースは、BLOBを提供するための組み込みのWebサーバーを提供します。これを書いている時点では、MySQLはそうではありません。

于 2008-09-30T20:25:13.620 に答える
4

それらを BLOB (または LONGBLOB) として格納し、実際にメディア ファイルにアクセスするときにデータを取得できます。

また

メディア ファイルをドライブに保存し、メタデータを DB に保存するだけです。

私は後者の方法に傾いています。これが世界全体でどのように行われているのかはわかりませんが、他の多くの人も同じことをしていると思います.

リンク (データへの部分的なパス) を保存してから、この情報を取得できます。ドライブ上で物を簡単に移動し、アクセスすることができます。

ファイルに関する他のメタデータと共に、各ファイルの相対パスを DB に保存します。実際のデータを別のドライブ (ローカルまたは UNC パス経由) に再配置する必要がある場合は、基本パスをオンザフライで変更できます。

それが私のやり方です。他の人にもアイデアがあると確信しています。

于 2008-09-30T20:04:40.253 に答える
4

それらを外部ファイルとして保存します。次に、パスを varchar フィールドに保存します。大規模なバイナリ BLOB をリレーショナル データベースに配置することは、一般に非常に非効率的です。スペースを消費するだけであり、キャッシュがいっぱいになると動作が遅くなり、使用できなくなります。そして、得られるものは何もありません。ブロブ自体は検索できません。ただし、メディア メタ データをデータベースに保存することもできます。

于 2011-01-04T17:36:26.437 に答える
2

簡単な解決策は、ファイルの相対位置を文字列として保存し、ファイルシステムに処理させることです。プロジェクトで試してみました (アンケートに Office ファイルの添付ファイルを保存していました) が、うまくいきました。

于 2008-09-30T20:01:12.320 に答える