Live DB is always on risk (which is most critical last few hrs video) hence milestone recommend RAID 0+1 for Live DB
IPVMU Certified | 10/06/14 02:41pm
By association, ONSSI also has the LiveDB.
The key physical aspect of those drives is the combo high RPM plus SAS reliability (this can be agrued if using Enterprise class drives like we do).
The performance increase result comes from being able to write quicker to the space. Making the space RAID10 will get you max performance.
I have verified the effectiveness of this design setup in my lab many times. The other key thing one has to do is to match up the SIZE of the LiveDB array with the Time it takes to actually perform the Archiving function and the overall camera input rate.
For example, comparing to a regular VMS that does NOT do this (or anything else special to storage), one has the potential to see a nearly 150% recording factor with a LiveDB and local DAS Archiving for the Corporate code level (which is the most efficient). Even with the lower code level there is a similar factor for throughputs rates below 300Mbits.
A key thing to be aware of is thay you MUST define an archiving schedule that will prevent the LiveDB drive from getting full. If you do not get this right, your performance will be miserable because the system will not be able to 'auto clean up' faster than the new camera data comes in.
IPVMU Certified | 10/06/14 02:54pm
Mike, I appreciate the detailed information and trust your lab results. But what's still curious for me, is if, for example, let's say a system has 1TB of live storage drive space and 29TB of iSCSI storage. How is it more efficient to write 1TB of data to a drive, then move that data to iSCSI storage (meaning the incoming video data is written a second time), versus writing all incoming data once to the iSCSI storage unit?
Even if the Live Database drive is faster than the iSCSI connection, aren't you still bottlenecked since data has to go through the iSCSI connection eventually anyways?
1. Why RAID 0+1 : Coz this data is critical last few hrs and hence must be protected from disk damage, it may not be able to retrive if got corrupted.
2. Why 15K RPM SAS : to get fastested possible speed to transfer this data into "Archives"
since the Live DB shall be first written on these drives, then "buffered" and finally "Write" on "Archive" DB...... which means these Drives have to handle the same Data 3 times, (2 Write and 1 Read operation)
3. Disk shall also be formatted with NTFS & highest possible "Allocation Unit Size" (typically 64K).
4. What is Risk : there are chances of getting this DB corrupt hence has to be transfer to Archive DB ASAP. hence Schedule to transfer this DB shall be set as low as possible (typically 1 hr). to match the available SAS drive size and this schedule, typically for 20 cameras , 1 SAS drive shall be allocated.
5. What does some of the other VMS do : - Send DB directly to "Archivers" may not have such risk. provided VMS have machanism to read and reindex such "Archived" DB (if at all got corrupted)
My understanding of the live/archive database configuration (admittedly, from other manufacturers) is that it most certainly does not increase performance. Logically, I'm not sure how it would.
At some point, the video written to the live DB will have to be read and rewritten to the archive DB, meaning the live drive will be doing double duty during that time period, with more load on the machine as it's reading and writing instead of simply writing in the first place. Sure, I can see that being less of a problem with SAS drives, but you could avoid it altogether just by writing to one database.
IPVMU Certified | 10/07/14 12:05am
Here is a link to a white paper that Milestone wrote about how their storage model has improved with it latest versions. It also answers many of the questions posted so far.
Or do a search for 'Milestone storage architecture'.
Here is a sentence that may be the most important one.... Archives become 'sequential' data. The LiveDB structure is NOT sequential due to its nature.
"Once the recordings are stored on the live disks, they can be archived one database at a
time to the archive disks. This way provides better disk performance as the archive
writings now are sequential (one camera at a time), and if the disks are busy for a second
or two, the data is not lost because it is stored in the live database until all of it has been
Another key element of having an Archive space.....even if it is stored on the same large array... it is able to be backed up easily. This is not true of the LiveDB itself.
The tricky part of the iSCSI is the variability of the storage target itself as well as the network it it installed on. The LiveDB serves as a cache buffer to accomodate this variability.
The sales pitch for Milestone is that you can use fast drives for incoming video feed and less expensive drives for long term storage, however with the Corporate software you can if you wish record to one database.
The idea is that the fast drives will handle a huge load and the video will be procesed for motion, once this happens and the amount of incoming data has been reduced it is then moved to a more organised structure on an Archive database. Video on archive disks is then failry static untill someone wishes to review some footage.
We have seen a Raid 10 disk array with high speed SAS drives can handle significant amount of cameras and that a raid 6 array is reliable for long term storage so it is possible that Milestones Live and Archive database has some merit.
DB: doesn’t that refer to the Data Base (SQL usualy)?
While the video records are the video files.
The first is usually measured in GBs while the other depends on the number of cameras and storage duration etc... which could reach up to PBs.
On the subject of SAS vs SATA and recording to the final destination VS temp recording and then shifting:
A SATA based ISCSI storage could reach to more than 400MB/Sec. So, improved performance of SAS over SATA would be noticed in cases of extreme throughput/bandwidth with other factors in play such as RAID controller and others.
The question is what is the ability of the the VMS to handle such a load on a single server. And in case of multiple servers, you will probably require a second storage to contain the growing video files' size, so another 400MB/Sec.
I would doubt the storage or the drives being the bottle neck, i believe it’s still the OS/VMS.
This is my personal experience with live DB and archive DB. If you didn't use the live DB and the system/service crashes for any reason then the milestone service will not be started unless it checks the database to ensure the consistency and by the way it is a property file format as far as I know. So if you have couple of TB of data then it may take hours before starting the service. Long time ago Milestone made some modification and tricks to overcome/eliminate this behavior but this didn't work with me at that time. I don't know where they are standing now in this regard but I didn't buy what they are saying about performance enhancement by doing so. Also, this will make you take into consideration another factor in sizing the servers whether the internal hard drives / RAID controller will be capable or writing to the live DB and simultaneously writing to the archive DB?
IPVMU Certified | 10/12/14 06:23am
Just a curious question, if having a Live DB and then archiving why not use SSD drives for the Live DB?
I think it was developed when MJPEG was the major compression method and the idea was to have 25fps live DB and say 6fps archive DB. As H.264 is not scalable, there is no way for this. Another option to use archive db is when it is located on the network storage and connection is not reliable. Then it is good to record locally first and then move to the network drive when it is possible. So, I see only this 2 options. There is no any other reason to have two db with the same data on the same server.
do you have to even use the archive db? what happens if you tell it you archive every ten years or something? does it slow down?
IPVMU Certified | 10/19/14 05:11am
It's a nice niche feature for use in mobile surveillance in busses, and vehicles in that the local vehicle server can contain the days recordings and then archive it off the vehicle when it returns to the lot via a wireless network to a SAN/etc. Although now a days several other vms have similar features available.