0

I need a database that can store a large number of BLOBS. The BLOBs would be picture files and would also have a timestamp and a few basic fields (size, metrics, ids of objects in other databases, things like that), but the main purpose of the database is to store the pictures.

We would like to be able to store the data in the database for a while, in the order of few months. With the data coming in maybe every few minutes, the number of BLOBs stored can grow quite quickly.

For now (development phase) we will be using a MySQL for this. I was wondering if MySQL is a good direction to go, in terms of:

  • Being able to store binary data efficiently
  • Scalability
  • Maintenance requirements.

Thanks,

Goro
  • 9,919
  • 22
  • 74
  • 108
  • 2
    I personally always prefer not storing images in the database, but just as file, with the database as a reference to the images – Rene Pot Oct 03 '11 at 17:50

2 Answers2

1

I suggest to store images on hard disk and in your mysql implementation maintain the metadata of your image including the filename (maybe). So your script can easily pick it up from your local hard drive.

For Reading & storing files, hard disk and most modern OS are really good at it. So I believe mysql is not going to solve anything here.

Srikar Appalaraju
  • 71,928
  • 54
  • 216
  • 264
1

MySQL is a good database, and can handle large data sets. However, there is a great benefit in making your whole database fit into RAM, in such case all database-related activity will be much faster. By putting large and seldom-accessed objects into your database, you're making this harder.

So, I think a combined approach is the best: Save only metadata in the database, and save the files on disk as-is. Better to hash the directories if you're talking about 100,000 of files, then save file under the name of an index field in your database. E.g. such directory structure:

00/00001.jpg
00/00002.jpg
00/00003.jpg
....
....
10/10234.jpg
10/10235.jpg

In this case, your directories won't have too many files, and accessing the files is fast and easy. Of course if your database server is distributed/redundant, things get more interesting, any such approach may or may not be warranted, depending on the load, redundancy/fail over requirements, etc.

haimg
  • 4,547
  • 35
  • 47