|
|
Posted by Jerry Stuckle on 01/09/08 20:39
NC wrote:
> On Jan 8, 8:05 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> NC wrote:
>>
>>> The only significant difference is the DB server load. Since <img
>>> data="*"> tags are not (yet?) commonly supported by browsers, you need
>>> a separate instance of an image display script (and a separate
>>> connection to the DB server) to display each image. So if your Web
>>> page has 100 images on it, it will require 101 nearly simultaneous
>>> connections to display itself and the images, as opposed to one
>>> connection if images were stored in the file system. Granted, image
>>> retrieval connections would be very short, but at high loads, this
>>> architecture would be patently inferior to disk-based alternative.
>> Not true. <img> tags are handled identically by the client, whether the
>> image comes from the database or the file system. The client doesn't
>> know or care if the image is from a database or not.
>
> The client doesn't indeed, but the DB server does. Let's say we have
> a script img.php (error handling omitted for brevity):
>
> $id = (int) $_GET['id'];
> mysql_connect('server', 'user', 'password');
> mysql_select_db('images');
> $result = mysql_query("SELECT imageData FROM images WHERE id = $id");
> $record = mysql_fetch_row($result);
> header('Content-type: image/jpeg');
> echo record[0];
>
> Let's further say that there is a script index.php that includes this
> fragment:
>
> for ($i = 1; $i <= 100; $i++) {
> echo "<img src='img.php?id=$i'>";
> }
>
> So when index.php runs, it outputs 100 <img src='img.php?id=*'> tags,
> so 100 instances of img.php are also run and each makes a connection
> to the DB server.
>
> Please feel free to point out any errors in the above argument.
>
No errors at all. But if it's serving from the file system, then the
server has to make the connection to the file system, also. Sure, it is
less handling. But it's not that significant in most site.
Additionally, how many sites do you know which serve 100 images in a
single page? Not many - the load time would be so slow it wouldn't be
funny.
>>> Also, if you use MyISAM tables, storing large images in them will
>>> bring you to the limit of table file size much more quickly. If your
>>> average image is 1 MB and your file system's maximum file size is 2 GB
>>> (there are still some older Linux servers whose file systems have this
>>> constraint), you will only be able to store about 2,000 images until
>>> your table exceeds the maximum allowed file size.
>> Few Linux implementations have a 2GB limit any more. Most are at least
>> 4GB, and some implementations are much larger.
>
> Yes, but it's an issue the OP needs to check on before commencing
> development.
>
Yes, and they need to ensure they aren't running under MS DOS, with it's
640K limit, also :-)
Seriously - if they're running that old of a kernel, it's time to
upgrade anyway.
>> Also, the typical image size is *much smaller* than 1MB.
>
> Depends on where you are and what you do. The OP mentioned an "image
> competition", which could be en event where average image size is much
> LARGER than 1 MB. A digital photo shot by a professional (or even top-
> of-the line amateur) camera can easily be 10 MB, so can a piece of
> digital artwork or a magazine page layout.
>
Sure, but they typically aren't uploaded to the server at that size, and
if they are, I hope the developer will trim them down to size. Load
time for 10MB files would be terrible, especially on DSL.
>>>> Our company is starting an image-competition soon, and I am not sure
>>>> if I should write the php script to insert the binary code into a
>>>> mySQL database or if I should just store the files in a dedicated
>>>> folder and the data about them in the mySQL database.
>>> Large image sharing sites invariably stick to the second approach.
>>> Moreover, images may be stored on separate servers, optimized for
>>> serving static content.
>> An over-generalization. Many have images stored in the database itself.
>
> Please name one. I, meanwhile, will follow my own advice and do the
> same. In his book, "Building Scalable Web Sites", Cal Henderson,
> chief software architect of Flickr, describes Flickr's image storage
> facility (p.152): disk-based and redundant, with synchronous writes to
> primary storage and asynchronous writes to multiple backup storage
> locations.
>
> Cheers,
> NC
>
Sure, that's one way. But it's not the only way.
IBM's document management system (don't know what it's called nowadays)
has been doing it since the mid 80's, at least. I do it on some of my
sites. And I've seen other people do it.
You don't see it as much on the web because too many people who have
never tried it claim it's a bad way to do things.
In fact, a database can often be the better way to go. It can, for
instance, handle 100K images in one table quite easily. There aren't
many file systems which can handle that many images in a single directory.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|