0

Im designing a social network. I have many questions regarding the design methodology and database design but according to the stackoverflow FAQ its better to make the question specified and focused. Or I will just list all the questions in one post. My question is: If you have a feature in the social network where user can create a photo albums, let’s assume that each user has 3 albums and each contain 10 photos that means each user has 30 photos each which will be stored in 3 deferent size large, medium, and small.

30 photos x 200000 users = 6 000 000 M phots. That means 6000 000 million rows in DB not an issue for MySQL

Now my main question is how do you let the server handle the image data. Do you divide them into folders OR you simply add them all in one folder ….. ANY EXPERT HAD FACED THIS. Suggestions please… thx…?

Specification

MYSQL DB PHP Shared Linux hosting for first 6 months.

Anmar
  • 33
  • 7

1 Answers1

0

I'll not be using a classical file system for this task. There is inherent limitation of hierarchical file storing (folder depth, number of file in a folder, name, auto indexation that will crash etc..).

Use some blobs directly in database. Bing Map is storing all of his data into blobs; several To of images.

Beside that, this is working on a Microsoft SQL server, with mysql you'll need some configurations tricks.

Boblepointu
  • 28
  • 1
  • 1
  • 7
  • Many AGREE that storing images in DB is considered inefficient way + i dont have a special requirements that force me to use DB BLOB as the storage for the photos. I prefer file system. HOWEVER; im asking more on how to organize it and how many files in a folder etc... Basically how to go about it... – Anmar Apr 18 '13 at 12:21
  • Many agree.. But only some have benchmarked the thing. With 6 000 000+ files, your file system will simply crash, backup will be inneficient, management complicated and debugging become a pain. If Bing Map is storing images as blobs, i trust them. If someone on the internet say otherwise, he'll have to prove me why it's not efficient, or showing me an efficient system based on filesystem. File systems are the old way to do it. Db the new Look at the first answer, here : http://stackoverflow.com/questions/4654004/mysql-binary-storage-using-blob-vs-os-file-system-large-files-large-quantities – Boblepointu Apr 18 '13 at 12:31
  • Okay lets analyse it: 6 000 000 photos dem:800X600 each one size maybe 70kb midum size: 20KB small size:10kB Multi = 5.8GB ..... I think its pretty much possible and maybe faster.... still need to read alot about it first.. BUT i start seeing your point – Anmar Apr 18 '13 at 12:39
  • I see your too. It's not a matter of size, it's a matter of indexation, iteration of filenames and synchronisation btw db and fs. Everything is said in the link above so i'll not extend my point. If you want a file system storage, choose wisely the filesystem (ntfs limit 32 folder en depth for example). Db side, you'll need to store every metadata of the image (path, size, color.. wtv you want). Don't access everytime the disk is my only advice. – Boblepointu Apr 18 '13 at 12:48