ZoneMinder Forums

Why does zoneminder use a flat database for images wouldn't storing all the jpeg in a database make more sense.

Points:
Easily deploy and grow system because mysql's distributed nodes.

Effective of using a high performance db.

Centralize system for backups.

Mysql has built in error recovery.

No file system limit files per directory (not as important now)

Maybe easier later to cluster ZM



Just my 2cents

I think actually it makes it harder. For one don't store things in a database if there isn't a good reason to do so. There is no lookup performance lost with the current flat file system, so there is no gain of a database. You mention high performance of a database but its pretty hard to beat the time to read a straight file from disk vs a database. Mysql does have error recovery to a point, but if disk errors occur (only thing to really screw up current system) mysql is also fairly screwed at recovering that data. I would say in most cases disk corruption you will lose more with mysql than with flat files (as each file is separate so each has to be uniquely corrupted).

Maybe easier to cluster for redundancy but short of that division of labor with mysql is going to be harder. With zoneminder it is fairly easy to have separate cameras on separate file systems(with NFS they could even be different servers) but dividing up things in mysql is trickier.

There are many redundant networked file system setups and having all the images in a flat file system makes it easier for admins to do things with them or write 3rd party items to grab things as they are all just there.


Just my thoughts on the idea.

I agree with mitch. If the DB does crash then repairing the stock zm database repairing / optimizing it can be a 5-30 minute deal, depending on data. If you had gigabytes of images you could be repairing it for hours, if not days.

You might look at the gallery2 forum / FAQ lists to see why they do not suggest putting images in the tables. If you really need a backup of the images raid5, iSCSI, rsync are all options.

Personally I don't believe storing thousands of images on the disk is effective either, but *shrug*.

Just wondering because i have been using Vbulletin and it insist on storing everything in db.

Might not be a horrible idea for exporting/backing up old events, though. I haven't found a backup script I'm happy with yet, might try cobbling one together that spits it out that way into a backup table, and has an import to take it back in/split it into folders. Would be a nice feature.

I've worked with a few different document imaging systems and all of them use a database to index images that are stored in a file system, a.k.a. data warehousing. While on the surface there appears to be a better reason to store them in a database, there were always things that would have made it a nightmare to do it that way versus data warehousing. One company moved to storing images in their database from data warehousing because it was easier to deal with data restores and to help protect against manipulating the images, but in the end it would have been much better to have put the extra effort into other methods and continuing with data warehousing. It's usually an application specific situation that causes the issues at some point, but I'd have to think the document imaging folks know what they're doing.

When dealing with hundreds of thousands of images, that are constantly writing to disk and deleting, I do not believe you can touch the performance the way it is now. On a small installation it wouldn't be much difference but when you start looking at 20 or 30 cameras, the database would require a lot of maintenance. Just my $0.02.