ナラベルサービスβ版 開発ブログ

ナラベルサービスに関する情報発信

データベースと画像処理

開発中のシステムには,いくつか画像を取り扱う仕組みがある。書影は基本的に,openBDかAmazonを参照しているので,DBへのアクセスはない。

関係してくるのは,ユーザー登録系の画像であるが,おもなケースは2つ。1つはユーザー自身を示す画像。これはユーザー登録時にファイルアップロードから登録できる。もう1つは,配架イメージを撮影した画像。これはテーマごとに登録できる。この2つの画像の処理をDB登録とするか,ファイルベースの処理にするか,かなり迷った。

Grailsでの画像の取り扱いは,ユーザーからのアップロードをあまり考慮していない。そこはあくまでも開発者の考えに任せているというコンセプトが窺える。無制限に増える可能性があるデータの処理をフレームワーク側で対応することは無理がある。

どうしても考慮が必要だったのは,サーバリソースである。ミニマムスタートであることからメモリもCPUも貧弱になる,さらにサーバへの不要なリクエストやDBへの無駄なアクセスは可能な限り避けたいところである。また,サーバ移行の手間を極力避けたい思惑もあった。このよな要件で,結局はDB登録することにした。アップロードされた画像ファイルは,文字列へ変換してDB登録。ページ内表示は,<img src="...." />にDB登録文字列を設定。デメリットとしては文字列変換することにより容量が2割ほど増えてしまったことである。しかし,画面遷移を伴う処理でも,改めて画像データを

取り出す必要がなく(DBアクセスなし)レスポンスへの悪影響はさけられると思われる。サーバ側のメモリがやや心配であるが,当面はこの仕様で様子見である。

 できれば画像は扱いたくないのが本心であるが,利用者視点ではあったほうがよいとアドバイスを受けた。他人の視点は大事であり,感謝したい。

 

#20180406 追記

結局,画像のDB登録は断念した。調べていくうちに,コントロールしながらGrailsの機能を使って画像登録できる仕組みを構築できた。テーマに付属する展示イメージの写真を複数枚つかってスライドショー的な機能を実装したいと考えている最中に,結局DB登録をやめた。Grailsにもファイルアップロードに必要な機能は十分にあった。GrailsというかSpringかもしれないが。

 

#20180413 追記

利用者からuploadされた画像ファイルをサーバに保存する仕組みを作っていたのだが,公式Documentを見ながら作成したのにはまってしまった。送られ来た画像ファイルは

Springのクラスをつかって,ハンドリングするのだが,Jettyを使っている場合,

ファイルの保存先指定ディレクトリに自動的に不要なパス(/tmp)が追加されて

しまう。どうやらこれはJettyの実装の問題らしいが,判明するまでにかなり時間がかかってしまった。回避策はDocumentのやり方をやめて,JavaのPathクラスを使って保存すればOK.思わぬところに落とし穴はあるようである。