The Video Management System (VMS) allows plugins to provide data about objects detected in video streams. Detected objects consist of sequence rectangle coordinates and custom tags.

This article explains how object metadata is stored, searched, and processed across single-server and multi-server environments.

How analytics metadata works

Analytics metadata is stored in two locations on your storage drive:

• SQL database: object_detection.sqlite in the storage root directory.

• Proprietary database: archive/metadata/<camera_mac>/YYYY/MM/analytics_detailed_*.bin subdirectories.

You can search object metadata by area of interest, object type, custom tag, date, time, and camera source.

Configure storage locations

To select the drive used for metadata storage:

1. Open the VMS Desktop client.

2. Go to Server Settings > Storage Management.

3. Select Use to store analytics data on your desired drive.

Object creation performance

Object creation begins when an analytics plugin detects an object. The storage overhead depends on how long the object remains visible in the stream:

• Data size: An object visible for an average of 3.3 seconds generates approximately 26 KB of metadata.

• Bandwidth impact: This duration creates a stream overhead of roughly 7 Kbps, which has a negligible impact on video stream performance.

Real-world analytics plugins can cause high CPU and memory load depending on their processing algorithms. Account for these plugin resource requirements when planning system hardware.

Object search performance

When you search for objects using the client timeline or notification panel, the VMS reads metadata from storage.

A search covering 2,000 objects from one camera over a 1-hour period requires the VMS server to read 3 MB of data. Storage I/O scales linearly with time frame duration, object count, and camera count.

Storage and system recommendations

To optimize search performance, apply these system design practices:

• Use SSDs: Solid-state drives deliver significantly faster search speeds than traditional HDDs due to higher random-access throughput.

• Avoid remote storage: Do not use CIFS or NFS network drives for analytics metadata. High latency and variable network throughput degrade search responsiveness.

• Allocate sufficient RAM: Additional system memory allows the operating system to cache recent search data, speeding up repeated queries.

• Maintain free disk space: Keep a continuous buffer of free disk space. If a drive fills up before the database rotation script runs, data corruption or service downtime can occur.

Search performance in merged multi-server systems

If a camera moves between servers in a merged system, its metadata splits across multiple machines. When you perform a search, the local server queries all other servers in the network for matching records.

Search speeds in multi-server environments depend on three primary factors:

• The number of servers queried.

• How widely the metadata is distributed across storage drives.

• Network speed and stability between servers.

To prevent slow queries or timeout errors in multi-server systems, ensure all servers maintain high random-read storage performance and stable network connectivity.

Benchmark testing environment

The data in this article was measured using the Stub Analytics plugin running in a virtualized test environment with the following hardware specifications:

• Host CPU: Intel Core i7-6800K, 3.4 GHz, 6 cores, 15M cache, VT-x and VT-d enabled
• Host chipset: Intel C610
• Host memory: 32 GB, DRAM Freq 1066.5 MHz
• Host HDD: WDC WD40EFRX-68N32N0
• Host OS: Windows 10 Home
• Guest CPU: 6 cores
• Guest memory: 4 GB
• Guest OS: Ubuntu 22.04 LTS