2

近い将来、数百、場合によっては数千のビデオをアップロードして保存する必要がある大規模なサイトに近づく予定です。さらに、多くの画像をアップロードする必要がありますが、それほど多くはなく、サイズも小さくなります。これまで、私は常にphpとmysqlを次のように使用してきました。

  • 画像をアップロードする
  • ファイル名をデータベースに保存します
  • データベース内のフォルダ+ファイル名を参照してファイルを表示します

ただし、データベースに画像とファイルを格納するBLOBについて調査したところ、この潜在的に大規模なプロジェクトに最適な方法がわかりません。これまでと同じようにアップロードを続ける必要がありますか、それともmysqlでBLOBタイプを使用する方が効率的ですか？たくさんの動画や画像をデータベースに保存すると、データが多すぎたり遅すぎたりするのではないかと心配していますが、完全に間違っている可能性があります。あなたが持っているすべての提案を私に知らせてください。

4

2 に答える 2

5

画像の保存BOLBは効率的ではありません。管理が難しいでしょう。データベースが大きくなります。

PHPスクリプトを使用してサーバーからファイルを提供するよりも遅くなります

于 2012-04-05T16:49:59.970 に答える
3

さて、2つの大きな領域は次のとおりです。バックアップと変更

バックアップ

選択したDBエンジンに応じて、バックアップにはロック/ダンプ/ロック解除が必要です。データベースが大きいほど、ロックが長くなります。一部の機能（マスター/スレーブ）を使用してホットシンク（ロックなしのバックアップ）を許可することもできますが、バックアップがデータセットを完全にカバーしないリスクがあり、DBの規模は依然として要因です。大きなファイルが（DB BLOBではなく）単なるファイルである場合は、ファイルシステムのバックアップ戦略を立てるだけで、おそらく静的であるため、複数のコピーを保存することを意味します（これはアップロード時の設計による場合もあります） -サーバーAとサーバーBに保存します）。

変化する

システムは同じままであると思いますか？スケーリングの問題があるようです。システムの成長に合わせて、DBを別のサーバーに移動したり、ファイルストレージを別のサーバーまたはSAN（またはS3など）に移動したりできますか？すべてがDBにロックされている場合は、サイズの増大に対処するためにDBのみのソリューション（大規模で高価なサーバー、マスター/スレーブなど）に依存する必要があります。もちろん、ファイルを1つのDBに保存し（バックアップ要件が少なく、データDBを混乱させない）、他のデータを別のDBに保存することもできます...しかし、ファイルシステムは一種のDBです。

それで

したがって、バックアップとスケーリングでは、BLOBではなくファイルとして大きなファイルを保存する方が優れたソリューションです。ファイルが小さかった場合（たとえば、MP JPGが低い場合）、バランスがずれる可能性があります。ただし、大きなファイルの場合、DB処理のオーバーヘッドには意味がなく、DBサーバーに余分な負荷がかかる必要があります。'それらを分離してください。

于 2012-04-05T16:59:50.690 に答える