Hi, In your opinion, is it better to save image files uploaded by the user in the DB as a blob or on the filesystem? In my web application each user will have 1 to 5 image files and these files will often be displayed. In the future the user may be able to manipulate these image files but this is not a priority now. What do you think? Thanks, Frank
Filesystem without question. You shouldn''t clutter any database with binary data if at all possible. Use the right tool for the right job - relational data = database...files = file system. On 4/29/05, Frank Kim <mtmusko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> In your opinion, is it better to save image files uploaded by the user > in the DB as a blob or on the filesystem?-- John W Higgins wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Got a coin? There''s pros/cons for both. Storing it in the db means all your data is in one place. Simple backups, etc. Storing it on your filesystem means better performance. I''m usually a filesystem kinda guy, but my current project (which includes a very simple photo gallery component) has me storing things in the database. A little extra work, but it''s all good. It''s slow to display the thumbnails in development mode (cause it goes through the rails pipeline), but very peppy (does anyone use that word anymore?) in production mode. Steve On 4/29/05, Frank Kim <mtmusko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > > In your opinion, is it better to save image files uploaded by the user > in the DB as a blob or on the filesystem? In my web application each > user will have 1 to 5 image files and these files will often be > displayed. In the future the user may be able to manipulate these > image files but this is not a priority now. > > What do you think? > > Thanks, > Frank > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Before I used to be a pure filesystem guy, but I''m starting to lean towards store the image in the database, use the filesystem as a cache. The only problem is as far as I know, it''s hare to do cross database compatible BLOB support. On April 29, 2005 09:08 am, Frank Kim wrote:> Hi, > > In your opinion, is it better to save image files uploaded by the user > in the DB as a blob or on the filesystem? In my web application each > user will have 1 to 5 image files and these files will often be > displayed. In the future the user may be able to manipulate these > image files but this is not a priority now. > > What do you think? > > Thanks, > Frank > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-- Scott Brooks Network Operations Manager Binary Solutions Ltd. sbrooks-7+OF9GBfT4Xe9wHmmfpqLOTW4wlIGRCZ@public.gmane.org
In article <afb1ad190504290808253e9959-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>, mtmusko- Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> In your opinion, is it better to save image files uploaded by the user > in the DB as a blob or on the filesystem?AOL e-mail attachments faced this very conundrum. Originally, they were stored as files in the file system. This had a few problems, which may translate to your domain: 1. It was difficult to partition the files so that directories, subdirs, servers, etc. were well-balanced 2. Lack of relational integrity with the e-mails that referenced the attachment (forwarding an e-mail within AOL does NOT require re- uploading the attachment) 3. Requires a separate backup solution from the e-mail database itself 4. Requires a custom client/worker/server solution to get remote, asynchronous, replicated, reliable file access 5. No ability to recreate corrupted filesystems 6. Fewer administration/monitoring tools On the other hand, while blobs solved all these problems, they were, of course, slow in a relational database. After benchmarking a number of major relational DBs and some custom blob servers, we ended up working with one of the RDBMS vendors to bring their blob support up to the level we needed. But there''s no guarantee that your average DB will have good blob support, and in general, they don''t (or didn''t). -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
Just to muddy the waters a bit more, I too was faced with the same dilemma recently, and went the filesystem route: I store ~200k full-res JPEGs and scale/cache them on the fly. While I could probably stuff these in BLOBs, I went with files because, as well as images, I also want to support arbitrarily large attachments (e.g. PDFs, Word docs, etc.). The clincher, though, was that I want to use the same setup to stream audio, storing ~50MB full-res FLACs and transcoding/caching to OGG/MP3 on the fly, and I fear the load of moving that much data around will kill my MySQL (4.1) DB server. Plus, all my audio (and image) tools work on regular files, not BLOBs, so I would have to fetch the BLOB and dump it to a file anyway. If anyone has any experience with large (huge!) BLOBs under MySQL, I''d be very interested to hear about it ... -- Steve
One of the big things to consider is how your planning to access the files. File systems are faster, and more reliable, but there are closures you just can''t get with a restrictive tree structure. This can be mitigated with links (assuming your in *nix), and in many cases images are logically organised by the same paradigm as files (Album is equivalent to Directory). Another issue is what extra info is related to the image. If you want the EXIF info, your best bet is a file, but it is probably easier to do tagging with an RDBMS (though I''m working on implementing a photo gallery with tagging that will use FS for storage). If either the memory/file system or the database go bad, your in trouble with the database, where your only really in trouble if the FS goes bad if your using files. Plus your ability to backup, do version control etc is easier with an FS, UNLESS your already doing it for the database (everyone backs up both the files and the database right ;-). It is sort of similar to the binary vs plain text argument. A .jpg is readable anywhere, if the data is locked into a blob, you need a tool to get at it. Rob Kaufman _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hi, I am faced with a similar decision as Frank. What about storing the information pertaining to the uploaded binary files (content-type, extension, original filename, our filename) in a DB where "our filename" is a unique filename, then dump all the files to the FS in an arbitrary directory and generate routes based on whatever meta information you''re tagging the files with? -Caleb
I keep my images (three sizes, thumbnailed on upload) in the database but cache them in the filesystem. That way the data''s all in one place for easy migration, but the performance concerns aren''t real. The cache can always fall back on the db if there''s a problem. Brian On 4/29/05, Caleb Buxton <adbust-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > > I am faced with a similar decision as Frank. > > What about storing the information pertaining to the uploaded binary > files (content-type, extension, original filename, our filename) in a > DB where "our filename" is a unique filename, then dump all the files > to the FS in an arbitrary directory and generate routes based on > whatever meta information you''re tagging the files with? > > -Caleb > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- The years ahead pick up their dark bags. They move closer. There''s a slight rise in the silence then nothing. -- (If you''re receiving this in response to mail sent to bluczkie-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org, don''t be concerned This is my new address, but mail will be forwarded here indefinitely)
On 4/29/05, Brian L. <zorander-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I keep my images (three sizes, thumbnailed on upload) in the database > but cache them in the filesystem. That way the data''s all in one place > for easy migration, but the performance concerns aren''t real. The > cache can always fall back on the db if there''s a problem. > > BrianI do almost the same (except I resize and modify the images on the fly and then cache the result), and my database is sqlite3 (!). Works fine for me.> > > On 4/29/05, Caleb Buxton <adbust-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Hi, > > > > I am faced with a similar decision as Frank. > > > > What about storing the information pertaining to the uploaded binary > > files (content-type, extension, original filename, our filename) in a > > DB where "our filename" is a unique filename, then dump all the files > > to the FS in an arbitrary directory and generate routes based on > > whatever meta information you''re tagging the files with?