4

I was thinking of building an app to serve audio content. The first question I get is how to store it. Two obvious solutions that occur are:

  1. Dump in database as BLOB
  2. Dump in filesystem, and store path in DB

There was a similar question here and the answer urged to store in file-system. I can think of at least one disadvantage of storing in files, i.e. I loose all backup, recovery and other awesome features of databases.

Also I wanted to know how both solutions would fare in terms of scalability.

Does anyone know how flickr or youtube does it?

Or does anyone has even more creative(scalable :)) ideas?

Community
  • 1
  • 1
Suraj Chandran
  • 24,433
  • 12
  • 63
  • 94

6 Answers6

6

Your file system should have backup and recovery procedures setup if this data is important. (The rest of the application is backed up right?). So you shouldn't use a database just for the backup and restore capability.

Storing the files outside of the database allows you to separate your database and file servers which will be a plus on the scalability side.

jzd
  • 23,473
  • 9
  • 54
  • 76
2

I would definitely go for Filesystem. storing and deliviring (large) files is exactly what it was made for.

Jan Galinski
  • 11,768
  • 8
  • 54
  • 77
2

Storing files in a file system would allow for using Content Delivery Networks. Outsource the storage may bring several benefits.

Boris Pavlović
  • 63,078
  • 28
  • 122
  • 148
  • 1
    It is pretty easy to use a CDN, even if you are storing files in the DB. For example, Akamai will act as a proxy and only care about how your content is delivered over HTTP, not how it is stored on your servers. – Guillaume Feb 28 '11 at 15:02
2

This is a classic question. And a classic argument, with good points for both solutions. Scalability can be achieved with both solutions. Distributed databases are usually easier to handle than distributed filesystems if you grow to the size where all you media dont fit on a single server (but even that is open to debate). Think MongoDB or other NoSQL scalable databases.

It boils down to what features you need. It is very hard to implement transactionality on a filesystem, so if it is a concern to you, you should use a database.

Guillaume
  • 18,494
  • 8
  • 53
  • 74
1

Backup and recovery of filesystem is much easier to implement than proper and consistent backup of the database. Also if you lose a file on the disk, it's just a file. If you lose a part of the huge table, it's a loss of all files contained or referenced in that table (as the table becomes unreadable).

Of course, for small databases where you can turn off the DBMS and quickly copy all DB files all of the above is not applicable, but this scenario is almost the same as having data files on the disk.

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • 1
    I dont agree with that. There are plenty of good Database backup solutions. And if you have part of your data on the filesystem and part in a DB, it gets pretty hard to have a coherent backup strategy. – Guillaume Feb 28 '11 at 15:08
0

I think that both ways are viable. But the backup issue i definately there. Both solutions are scalable given the right design. But big files are probably better of in the file system.

Regards, Morten

Morten
  • 3,778
  • 2
  • 25
  • 45