Q&A
サーバのどこかのディレクトリに保存するというのは普通のことなのでしょうか？
例えば、登録しているユーザー数が多くなってしまったときに、大量のデータがサーバのストレージにあるというふうになってしまうわけですが、それはあまり望ましくないように感じるのです。と言いいますのは大量のデータがある場合に、その取り扱いというのはDBMSを使った場合が一番良いと思うからです。
すごくベーシックな質問だとは思うのですが、Webシステムにおいて、写真(jpegやpngファイル）というのはどのように取り扱うのでしょうか？
例えば、アカウントに写真を設定するとなったときに、Javaであれば、そのクラスのフィールドとしてPictureクラスの変数に値を設定すると言った感じになるのではないかと思ったのですが、jpegファイルやpngファイルをそのままデータベースに設定したり、できるのでしょうか？
そのほかのもの（名前やパスワードなど）の取り扱いであればわかりますが、写真の場合どうなるのでしょうか？
回答お願いします。
回答7件
0
ベストアンサー
個人的な経験を元に私の感想を書きますが、規模が小さければDBに画像データを格納する方が管理しやすいですが、ある程度の規模（ファイル数や容量）になると、DBとは別のファイルサーバーに画像を保存して、DBにはファイルパスで管理するのが融通が効いて良いですね。
メリット
- DB、ファイルサーバそれぞれのバックアップを別々に取ることが出来る→DBは高頻度でとりたい。ファイルサーバーはデイリーで良い。など
- 画像の差し替えや、変換を後からできる→サイズ縮小、高圧縮化、など
- CDNを使える余地がある→Webサーバーの負荷分散
- DBの負荷を軽減できる→結合や集約した結果、内部的に一時テーブルを作る場合、BLOB型のデータは性能悪化につながることがあるのと、単純に処理するデータ量が減るので負荷軽減が見込める。
デメリット
- 別々にリストアしなければいけない
- 別途ファイルサーバーが必用
- ネットワーク的に複雑化する
- 画像の排他制御をプログラムで行う必要がある（必用ならばですが…）
- ファイル名をユニークに保つ必要が出て来る
なお、Webサーバーのローカルに画像を置く方式もアリですが、Webサーバー自体をスケールアウトした場合や、冗長化した場合に面倒になるので、ファイルサーバーを別に立てるのが良いかなという感じです。
投稿2017/02/21 13:05
編集2017/02/27 08:55
総合スコア1351
0
jpegファイルやpngファイルをそのままデータベースに設定したり、できるのでしょうか？
できます。BLOB型などのキーワードで検索可能だと思います。
ファイル自体をデータベースへ保存せずとも、ファイル自体はサーバーのどこかのディレクトリへ保存しておき、データベースへはそのファイルのパスを保存する方が多いかもしれません。
投稿2017/02/15 07:37
編集2017/02/15 07:38
総合スコア7914
「DBMSを使った場合が一番良いと思うからです。」これはサーバーを管理する方(組織/企業)のポリシーによると思うのでどれを選択するかはご自由にとしか言えないです。
Webサーバーのローカル機材(HDD)に保存しなくてもWebサーバーからアクセス可能な別の機材(SANデバイスなど)へ保存してもいいですし（というよりWebサーバーのスケールアウトを考慮するとローカルのHDDへの保存は選択肢から外れますし。）。
「大量のデータがサーバのストレージにある」「大量のデータがDBサーバにある」「大量のデータを保存しておく機材を別に用意する」のうち要件にあるものを選択すればいいと思います。
（バックアップ・リストアやサーバーのスケールアップ/スケールアウトなど考える必要もあるので）
いまどきだと、AWS S3のような「ファイルを置くのに特化したサービス」も多数あるので、そういうのに任せてしまう、というのも選択肢の1つかなと思います。
データベースシステムに格納することもできるし、データベースにはファイルへのパスを入れておき、別にストレージを用意することもできるとのことですが、それぞれのメリット・デメリットはどのようになるのでしょうか？
私個人的にはデータベースに格納できるのであれば、別にストレージサーバなどを用意しない方がよりシンプルな構成になって、いいのではないかと考えているのですが、パフォーマンス等を考慮した場合、どうなのでしょうか？
普通のデータはともかく、Webサイトに画像を表示するような場合は画像を別リクエストで配信することになるので、画像を表示するためのエントリポイントも必要になって、プログラムとしては煩雑になりますし、DBサーバ・アプリサーバの両方で処理が必要になるので、性能的にもあまり有利ではありません（Data URIを使うとキャッシュできないので、よほど小さな画像以外ではおすすめできません）。
ただし、「ファイルが散らからない」という点はメリットなので、「キャッシュサーバが入っていて直接のレスポンスタイムがあまり影響しない」、あるいは「頻繁に画像の更新や削除を行うため、ファイルで管理するのが煩雑になる」というような場合はDB保存も有用です。
あとはDBに保存した場合、データベースのバックアップ時間・容量(およびリストア時間)にも多大な影響が出ます。これとDBサーバーの負荷など考慮し許容できるならDBへ格納でもいいんじゃないでしょうか？
画像ファイルのサイズが1枚あたり数十MB以上のものを保存する場合はDBへの保存はお勧めしません。
インラインでHTMLに埋め込んで重くならない程度の画像であればDBに保存することはありますね。
viewにそのまま渡せて楽なので:-P
<img src="data:image/png:base64,XXXXXXXXXX" alt="hogehoge">
0
まあ、データベースに登録することもできますし、データベースにファイル名を登録して、画像ファイルは物理ファイルでストレージに保存するというやり方もあります。
また、ファイル名を登録しなくても、ユーザーIDや日付などの組み合わせ等により一意なファイル名(もしくはハッシュ)を生成して、そのファイル名でストレージに保存するという方法もあります。
大体この3パターンが使用されると思います。
投稿2017/02/15 07:37
編集2017/02/15 08:20
総合スコア4267
データベースに登録するのではなく、ストレージに保存するというアプローチを取った場合に、ストレージというのはどこのストレージなのでしょうか？
データベースサーバー(マシン)のストレージや、別にストレージサーバーを立ててそのストレージを使用するというのもあります。
データベースシステムに格納することもできるし、データベースにはファイルへのパスを入れておき、別にストレージを用意することもできるとのことですが、それぞれのメリット・デメリットはどのようになるのでしょうか？
私個人的にはデータベースに格納できるのであれば、別にストレージサーバなどを用意しない方がよりシンプルな構成になって、いいのではないかと考えているのですが、パフォーマンス等を考慮した場合、どうなのでしょうか？
画像はキャッシュ管理をしっかりすればリクエストは減るでしょうが、それでもウェブサーバーが画像に対するリクエストも引き受けるため、負荷が増えてしまいます。ストレージサーバー用意すれば、画像のリンクをストレージサーバーにすることで負荷分散させることができます。
0
ECサイトを運営していた経験から言えば、画像関係は別サーバで管理したほうがよろしいかと思います。
理由はいくつかあって、一番の理由は運営していく上で日々増えていく画像の数と、そのファイルを転送するための通信量が侮れない為です。
※画像サイズ規制や、適時、利用していない画像を消すという運用が行われなかった場合･･･恐ろしい数値を見ることになるでしょう。
AWS S3に画像ファイルだけを格納するようなやり方でも十分効果はあると思いますが、日々かかる従量課金に見合った運用になっているならば問題はありません。
実際のやり方は、皆さんが提示されているとおりだと思うので書きませんが、webページの表示時間に密接に関係してくるので、違う観点から画像の取り扱いについて書いてみました。
投稿2017/02/21 06:42
総合スコア278
0
データベースシステムに格納することもできるし、データベースにはファイルへのパスを入れておき、別にストレージを用意することもできるとのことですが、それぞれのメリット・デメリットはどのようになるのでしょうか？
既に複数の回答者様がいろいろなメリット・デメリットを書いてくださっているのに、それでもまだ「メリット・デメリットはどのようになるのでしょうか」などと繰り返すとはどういうことですか？
回答を理解できないのか、それともきちんと読んでいないのか？
何にせよメリット・デメリットが自分で想像できないような人は「画像はファイルで保存、パスのみDB」が無難だと思いますよ。
投稿2017/02/21 06:00
総合スコア907
『自分で想像できないような人は「画像はファイルで保存、パスのみDB」が無難』
ですよね。基本形を教えてあげるのも大事なことだと思います。
0
利用するDBMSによりますが、データベースシステムに格納することは可能です。
http://hijiriworld.com/web/mysql-img-binary/
あるいはファイルシステムと連携し、DBにはファイルシステムのパスを格納し、要求されたら、Webサーバがそれを参照して返却したり、外部から参照できるURLに変換して返却するという方法もあります。
後者の方が一般的かもしれません。
投稿2017/02/15 07:48
総合スコア5488
データベースシステムに格納することもできるし、データベースにはファイルへのパスを入れておき、別にストレージを用意することもできるとのことですが、それぞれのメリット・デメリットはどのようになるのでしょうか？
私個人的にはデータベースに格納できるのであれば、別にストレージサーバなどを用意しない方がよりシンプルな構成になって、いいのではないかと考えているのですが、パフォーマンス等を考慮した場合、どうなのでしょうか？
別に用意しておくと、それ単体で冗長化することが可能です。画像へのアクセスが中心のような（インスタグラムとか）サービスを考えると、webサーバへアクセスし、その後に画像が表示されるような流れになります。
DBに入れるようにすると、webサーバの応答時間が画像の取得、表示までになりますが、分離しておけば、画像の表示部分は別のサーバに依頼することが可能になるといったイメージです。そうすると、画像へのアクセス負荷が高くなった場合、画像サーバのみの負荷分散などを考えれば良いですし、Webアクセスへの影響が少なくて済みます。
0
1．画像ファイルをそのままDBに格納する
→可能です。
<img src="data:image/png;base64,saoifhafwhf....">
と言うような形でHTML上に表示も出来ます。
2．画像ファイルはファイルとしてサーバに置いておき、ファイルのパスだけDB管理する
| ID | 名前 | 画像ファイルパス |
|---|---|---|
| 8012 | 寺 ている | /images/profile/8012.png |
| ↑のようなテーブルデータで、表示するときはこのパスをimgのsrcに入れればOKです |
3．画像ファイルはWEBサーバ以外の倉庫サーバに置いておき、画像のIDだけDB管理する。(倉庫サーバは画像を返答する機能を実装する。)
ブラウザ → WEBサーバ → 倉庫サーバ
← <img src="http://倉庫/8012"> ←image/jpeg
投稿2017/02/15 07:43
総合スコア5405
データベースシステムに格納することもできるし、データベースにはファイルへのパスを入れておき、別にストレージを用意することもできるとのことですが、それぞれのメリット・デメリットはどのようになるのでしょうか？
私個人的にはデータベースに格納できるのであれば、別にストレージサーバなどを用意しない方がよりシンプルな構成になって、いいのではないかと考えているのですが、パフォーマンス等を考慮した場合、どうなのでしょうか？
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/02/22 01:10
2017/02/22 02:25
2017/02/22 08:21
2017/02/22 09:32