Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの？」を調べてみた（ファントムファイル） - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた！』でした。 想定読者 ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人 イントロダクション 皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか？ 帳票や大きな画像ファイルなどを扱う際、大きく分けて２つの設計方針があります。 ・DBに直接保存する ・DB外部に保存し、パスなど

[rdlf]

DBにファイルを入れるとDBのバックアップが辛くなる（なった）のでS3に置くようになった。

[jiro68]

DBとは別にファイルシステムに置いておく方がポピュラーだと思う。ただし、データの一部である事は確かなのでバックアップ、リストアを含めての運用設計が必要。

[nakag0711]

DBのサイズが巨大になってしまうのも何かと問題になる

[prograti]

以前作ったシステムで機微な情報を写した画像データをDBに格納することはしましたね。外部ストレージだと画像差し替え時に古い画像が残ったままになったり、ユーザー削除時にファイルを消し忘れたりミスしやすいので

[tinsep19]

RDSのストレージコスト払うならS3のコストがいいよって思うくらいかな。

[rryu]

MySQLはストリーム読み出しみたいなことができないのでファイル全体がメモリ上に置かれてしまうので、扱ったファイルサイズの分だけアプリケーションサーバのワーカーのメモリフットプリントが増えていくのが一番つら

[m50747]

DBに画像入れたケースで件数が多いとマイグレーション終わらなくてサービス止めたケース見て肯定派から否定派に。バックアップも辛くなるしファイルキャッシュ乗らなくなるし。ちゃんとリスクを知って設計すれば良し

[diveintounlimit]

dbにファイルを格納する処理何度か見てきたけど、問題しか起こしてないし最悪DBが死ぬので、まったくオススメしない。

[yohskeey]

前に画像をDBに突っ込むようにしたシステムに関わったけど、レコードが多くなく画像も小さく軽量シンプルだったからその設計で進めた。なお後に任意の画像を取り込んで保存できる拡張が入った。

[turanukimaru]

HDD保存で良くない？と言いはするんだけどファイル名とか入れ替え処理どうするか決めてくれって言うとだいたい管理する自信が無いと言われるので雑にBLOBに突っ込むことは多い。方針だけ決めてくれりゃいいんだが。

[tmatsuu]

SQLiteのBLOBはファイルシステムよりも高速だとか、DBへ格納しておいた方がマイグレーションは楽、キャッシュすればいいなどの話はありつつも、seekができないなどデメリットも多いので場合によって判断しましょう

[dot]

アップロードされたファイル等はキャッシュの乗せやすさとか取り回しのし易さ考えると、今のところS3がベストプラクティスかなあーと思ってる。

[Kazumi007]

DBに入れるパターン見たことないな。経験が少ないのかな。

[hogeaegxa]

ファイルも含めてトランザクション管理したいことがあったらデータベースもいいんだろうな。でもちょっとそういうユースケースは思い浮かばないな

[taruhachi]

既出だけど、要件次第かな。手掛けている業務においてDBに格納すべきという結論になったことは特に無いけど。

[strawberryhunter]

1件だけBLOBにgzipしたCSVファイルを保存するシステムを設計したけど、ファイルシステムに保存した方が無難。

[murasuke]

(どうでもいいファイルで)バックアップとリカバリに時間がかかりすぎるのは困る。ファイルはRAIDで冗長化すれば十分では？

[PrivateIntMain]

勝手に改ざんされたり消されたりすると困るからってインボイスの帳票バイナリはDBに突っ込む設計になった。数もたかが知れてるし何も言わなかったが、7年後想定の負荷テストとか無かったのでちょっと心配。

[iww]

『「実装考慮が十分で、正しくファイルシステムに帳票を保存する設計 」のことはファントムファイルと呼んでいない』 今度DBにファイルを格納せざるを得ないことになったので ちょっと勉強する

[kkobayashi]

時代とともにアンチパターン（ベストプラクティス）も変わってくるということかな

[nharuki]

置き場所をカジュアルに一元化できるという点がDB内にBLOBを配置する一番のメリットだと思っている。でもやっぱりサイズ次第で性能は低下する印象だな～。

[sds-page]

全部同じクラウドに載ってるなら表向きDBにあるけどファイルの実体だけ切り離して別に保存してあるとかオプションでありそうだけど

[Magicant]

ファントムファイルの話は一台のサーバー上に DBMS もストレージもアプリケーションも同居してた CGI 時代の発想なので……

[da-yoshi]

餅は餅屋の原則

[emt0]

基本はS3かな。格納するファイルの属性にもよるけど重要な物だとしてもDBには今は格納しないかな。役割分担させた方が管理もしやすいし

[rck10]

DBの本質はacid特性を容易に実現出来ることであり、耐障害性にある。逆に、他でそれが実現出来るorしなくてもいい環境ならDBに拘らなくてもいい。でも、acidの自力実装するくらいなら、DBに頼った方がマシ。

[pmint]

この「ファントムファイル」ができる理由は誰も分からない感じ？更新頻度・ロックの要否で考えないと。/ RDBのフィールドには検索用に生成したデータを残す。外で使うデータはシリアライズして単一フィールドに残す。

[mk173]

検索対象でなければ、どこにおいても良いような

[infobloga]

バックアップ/リストア/マイグレーション考えるとDB格納はありえないよね。ファントムファイル対策はいろいろ設計パターンがあるし、要件によっては「放置」が適切な場合もある。

[hiroshitoda]

DBに格納する設計で5年ほど運用した経験に照らすとすべてのケースにおいてデメリットの方が多くおすすめできない。ファイルシステムへの格納では、パス文字列の保管ではなくファイル名列+メタデータ各列とすべき。

[toyoshi]

理想はDBに入れることなんだろうけど現実にはネットワークやI/Oの問題がありDBに入れてたら全ての運用が大変になった。

[s_masao]

ファイルとDBの2つのリソースを制御する場合、厳密な管理には2フェーズコミット相当の実装が必要だ。エラー時の設計ができないなら、DBの中に突っ込んどけと言いたい。トランザクションが必ず正常終了するのは幻想だ。

[cl-gaku]

利用者に紐づかなくて数がしれてるようなのはBLOBにしちゃう

[mayumayu_nimolove]

DBに入れるのはURL

[getcha]

WordPress が全部つっこんでかなったっけ。マイクロサービスもそうだが、一つのアーキテクチャーが銀の弾丸になる事はない。適材適所。

[shoh8]

s3に入れてしまえば安くて楽という、シンプルで強力な方法使えるようになったなあ。これによって依存度高まるawsビジネス

[tettekete37564]

直感的にメガ単位のバイナリをDBにつっこむのは良いこと無さそうだけどDBの偉い人に怒られそうだな、と思う程度の立場からすると実体験の情報はありがたい

[nakamura-kenichi]

昔アバターアイテム管理でやったなあ。結構痛し痒しやったけど、今時サーバレスとか、サーバのアクセス申請面倒くさいとか適材適所が結構あるやろな。クラウドなリソースならスケールでコスト検討してもええんやで。

[tpircs]

ファイルシステムに置くとトランザクションを自前で管理しなきゃならないのが面倒なところだけど、性能やらを考えるとDBに入れるのためらう。DB側で良い感じにしてくれると最高なんだけど。