On 12/30/05, Cynthia Kiser
<cynthia.kiser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> On 12/29/05, Joe Youngquist
<joemanfoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > If your building a large system, then it''s likely best to
place the images
> into the database and have your application pull them from the DB, create a
> cache file that would then be referenced...if your making a personal site
> then you can just upload to a folder (path of your choosing, say,
''/images''
> or ''/graphics'').
>
>
> Interesting. I assume this is for ease of deployment/backup, i.e. all the
> important data lives in the database. But what about performance? I am
> storing images in an Oracle database for an application written in a
> different language and framework. One of the things I am looking into is
> breaking image storage out of the database in hopes of improving
> performance.
>
> Joe, would you like to go into more detail about explicit creation and use
> of a cache file? And do you have any data on relative performance of images
> stored in a database and images stored in a file system and referenced via
a
> database? (I don''t have any benchmarks, just notions from watching
page
> reloads. Perhaps some performance measuring should be my first step.)
Putting the images in the database is at least 50 times slower than
reading them from disk, usually slower. Also, it will make your
database backups take forever, if there are a significant number of
them. Given that, I''d say it''s more about scaling than about
performance or backups. You can stand up as many application servers
as you want without worrying about syncing up the images to all of
them.
One approach would be to make an include_image() helper that talked to
your Image model. The helper would first check to see if
/images/wherever/image_file_name.png already existed locally. If so,
serve it up and you''re done. If not, grab the matching BLOB from the
model, and write it out to disk for next time.
Try searching Google and this mailing list for mentions of MemCached.
Even though that deals with slabs of memory instead of files on disk,
the principles are pretty much the same; whenever you get something
from the db, keep a copy locally in case you need it later, and have
all your find_stuff() code check there before executing any queries.
If you have DBAs, make sure they know what you''re going to do. They
might balk at adding 50GB of BLOB data to their precious servers. Heh.