|
|
Posted by Nick DeNardis on 12/23/06 14:13
eholz1,
What I mean by the "mod 30" hash folder is basically what I did was
setup 30 folders numbered (0-29) inside a directory. Then when ever a
photo is uploaded it would go to a temporary area then its primary key
would be modded by 30 to get a number between 0 and 29 then the photo
would be placed in that folder. So like this:
1. User uploads photo to temp directory.
2. Info is grabbed from the photo.
3. The information is inserted into the database.
4. The primary key is modded by 30, so $folder = ($primary_key % 30);
5. The photo is moved into that $folder.
6. A thumbnail is also created in the $folder/thumbs/ directory.
The things that would be stored in the database about the image are the
filename, hash folder so it does not have to be recalculated, original
width, original height, thumbnail width, thumbnail height, filetype,
filesize, and other things related to the user but nothing really too
crazy is stored in the database.
I hope this helps.
Nick D.
On Dec 22, 4:03 pm, "eholz1" <ewh...@gmail.com> wrote:
> Hello Nick and Seaside (an den See!!),
>
> The only reason I have for putting the image data in the table is for
> learning and fun(??).
> but it does seem like a better idea (now) to use a file system scheme,
> like Nick mentions.
>
> I will do a little research on the term "mod 30 hash folder" (i am
> fairly new to this!!), and see what I can do with it. I may need to
> get back and ask more questions.
>
> Thanks for the good info,
>
> eholz1 aka ewholz
>
> Nick DeNardis wrote:
> > Very True, I use to run a photo hosting web site and I experimented
> > with this in the beginning and oh man once there was 100,000+ images in
> > there the MySQL DB slowed down quite significantly. Almost 3 gigs of
> > data in a MySQL table is not the way to do it, I have found the file
> > system does a much better job holding and serving images.
>
> > What I ended up doing is just creating a simple mod 30 hash folder
> > setup to store all the actual photos and then have a table to store all
> > the attributes of the photos. This improved the performance very
> > significantly over the pure MySQL setup. Also separating the photos
> > into 30 different folders helped in case I actually had to do any
> > folder scans, it would not need to scan though all the photos just
> > 1/30th of them.
>
> > I hope this helps.
> > Nick D.
>
> > On Dec 21, 10:57 pm, "seaside" <seaside...@mac.com> wrote:
> > > eholz1 schrieb:
>
> > > > Hello Members,
>
> > > > I am setting up a photo website. I have decided to use PHP and MySQL.
> > > > I can load jpeg files into the table (medium blob, or even longtext)
> > > > and get the image(s) to display without a problem.Just a small performance note:
>
> > > If you use blobs and various other types, MySQL is likely to fall back
> > > in table-scan mode which might slow down your queries very much. A
> > > table-scan needs to read the full table data, at least much more, than
> > > an index.
>
> > > Even if you use some indexes, MySQL might not use them - the exact
> > > behaviour depends on your indexes and queries.
>
> > > Are there good reasons to keep image data in tables and not in file
> > > systems - other than simpler coding, e.g.?
Navigation:
[Reply to this message]
|