Best way of image storeing?
Hi there;
I am coding a image storeing website... Photo albums etc.But storing them in a folder system is getting complex for me... Whats the best way of storing image to folders?
What i did up to now is: every member has its own main folder named with hex numbers... and i rename the uploaded images with hexnumbers again...
The result is like:(first one is user-hex /second one is image-hex.jpeg)
4324AFC3BC2390DE / 45F83AECB43B2A.jpeg
its an unprofessional but simple working way...hard to predict the image hex if the image is published as private picture...
If the user has 2000 photos it maybe hard for a single folder to index the photos...
When i look at professional photo album sites webshots.com or flickr...
Image folders are like 67/434/4543/345/4534/5443F432ACD342.jpeg
so there are too many subfolders...But whats the logic and algorithm behind..How do they name these subfolders?how do they group images in folders?
What can i do with JAVA with best performance on heavy traffic?
Please give me ideas or refer me some web links
thank you
BuraK
[1144 byte] By [
netsonicca] at [2007-11-27 2:03:20]
how you name your files is arbitrary to a large extent
how you store them is a big deal if you have lots of images and are concerned with performance. you might want to store a path to the image in a database table so searches are fast, but I'd really need to know more about your project, use cases, etc.
Is it true that for speed some websites store their images on a separate machine so that they can be loaded in parallel to the page?
I have explained my way above:Every user has a unique userhex code that is the root folder of that user...then i rename the uploaded jpeg files with hex characters...So my way is so simple and path is like below;
Root of user folders/userhex/imagehex.jpeg
an example:
photoarchieve/42AC83BED2F29532/4453FCAD3D5E3A.jpeg
i get the hex codes from database where user_no=xx and image id=xx then make a path string then locate the image in html...
but with my way all images of the user stored in single folder even the user have more than 1 album in his/her account...
need a professional help
thanks a lot
DrLaszloJamf:
i also think to use that method...i cant afford for many terabytes devices like NAS İ will get some raid supported static servers...i will add a server field on images table...when uploading images i will load balance the images on servers...
then rest is easy...but i have no idea how the folder tree must be...how to store images make me thinking a lot.
Message was edited by:
netsonicc
Use Mysql(or other DBMS) and store every image in a BLOB.BLOB accept everything in binary formatOn the net you'll find many examples just to copy and paste to translate your Image in binary format and reverse...
> Use Mysql(or other DBMS) and store every image in a BLOB.What's the advantage to storing the image in the database, versus juststoring the path to the image?
> > Use Mysql(or other DBMS) and store every image in a
> BLOB.
>
> What's the advantage to storing the image in the
> database, versus just
> storing the path to the image?
probably not much, just that data is all in one place. i dunno, maybe the db can cache stuff? i doubt there's much advantage.
also (at least for some databases) you have to set the size of the image storage or blocks or whatever. so if you set that size to 64kb and then insert an image that's 65kb, you've just caused either an error or 128kb of space to be allocated. i.e. databases aren't good at storing different sized stuff efficiently
I was thinking of some other advantages:
1. transactionality: copying the image into the database is of course part of the transaction. Copying it into a directory isn't part of the database transaction
(unless you get fancy)
2. Because the images are separate from the database, data integrity may suffer: images are deleted, renamed, replaced...
disadvantages of database;
1.)database has limits as i know..i mean max grow lenght of database
2.)it will be too much slower than publishing images under light http server...
maybe more...
i am looking a professional solution...any advice about "folder tree system" of archiving images...
> disadvantages of database;
>
> 1.)database has limits as i know..i mean max grow
> lenght of database
If it's a professional system you are developing, then use a professional DB
> 2.)it will be too much slower than publishing images
> under light http server...
Really, so you have profiled this, and you have figures to back up that claim.
> maybe more...
That sounds like you have examined this option thoroughly.
> i am looking a professional solution...any advice
> about "folder tree system" of archiving images...
DBs are the "professional" solution, perhaps you aren't professional enough to purchase the correct solution.
i cant afford for Oracle solution and cant pay 100.000$ or more for its licence...
anyway, if this is the correct way storing all album images into database why dont flickr or why dont webshots or why dont other solutions store images under folder tree system?
i think folder tree system is just the correct way to go with...so my question is how must this folder tree system be?
The cost for Oracle would be well worth it if you are expecting such high user loads.
Oracle can be set up for clustered server environments so database size is practically limitless, pending you have a limitless budget for hardware.
Performance is a whole other issue however.
I believe SQL Server is a bit cheaper than Oracle if money is truly a concern and it can also be made to work with your app server.
> The cost for Oracle would be well worth it if you are
> expecting such high user loads.
Or you could just use MySQL. Google seems to not have a problem with MySQL and they certainly have high user loads.
> Oracle can be set up for clustered server
> environments so database size is practically
> limitless, pending you have a limitless budget for
> hardware.
Huh? Whether you store your images in a folder or in a database, you still run out of hard drive space the same way.
> Performance is a whole other issue however.
>
> I believe SQL Server is a bit cheaper than Oracle if
> money is truly a concern and it can also be made to
> work with your app server.
Again, MySQL is free and very performant.
> i cant afford for Oracle solution and cant pay
> 100.000$ or more for its licence...
>
> anyway, if this is the correct way storing all album
> images into database why dont flickr or why dont
> webshots or why dont other solutions store images
> under folder tree system?
>
> i think folder tree system is just the correct way to
> go with...so my question is how must this folder tree
> system be?
depends on the OS to an extent. for examples, 1000's of files in a Windows folder can hose it up real good. In any case, I would store all the images for each user in 1 folder. So 100 users = 100 folders, no tree needed. If you want to make a tree, store the relationship/hierarchy logical. don't use folders to manage the tree structure unless you just want to i guess.
i am just using mysql with my project...thanks for other database alternatives but my question was about a good directory subtree system to store albums and its images...by the way i hope mysql stays free...it doesnt look so for soon..
> i am just using mysql with my project...thanks for
> other database alternatives but my question was about
> a good directory subtree system to store albums and
> its images...
>
> by the way i hope mysql stays free...it doesnt look
> so for soon..
If it doesn't then use Postgres, by all accounts it's better. It has also been designed to handle transactions, unlike mySql which has recently added them (or they are still planning to - not fully up to date with their timeline)
