Development of a high-performance in-memory database architecture for intelligent video surveillance in critical patient care

Abstract

Objectives:

This research aims to engineer a specialized, high-speed database architecture tailored for intelligent video surveillance in critical healthcare environments. The primary objective is to overcome the input/output operations per second (IOPS) bottlenecks and latency issues inherent in traditional SQL and general-purpose NoSQL systems, which impede real-time clinical decision-making.

Methods:

We conceptualized and implemented “SubDataBase-0.91s,” a task-specific Database Management System (DBMS) residing entirely in Random Access Memory (RAM). The architecture employs a direct memory access model with periodic, asynchronous synchronization to the file system to ensure persistence. Performance was rigorously benchmarked against industry standards—Microsoft SQL Server, OracleDB, MySQL, PostgreSQL, MongoDB, and Redis—utilizing Node.js automation scripts to simulate high-velocity write/read cycles typical of video analytics streams.

Results:

The proposed RAM-resident architecture demonstrated a dramatic reduction in data access latency. Specifically, SubDataBase-0.91s achieved a write/read speed increase of 8.6 times compared to MySQL (the slowest control) and outperformed Redis (the fastest commercial in-memory control) by a factor of 0.78 in specific surveillance-related transactional workloads.

Conclusion:

The study confirms that stripping away universal ACID (Atomicity, Consistency, Isolation, Durability) compliance overhead in favor of a streamlined, memory-mapped architecture significantly enhances the throughput required for real-time patient monitoring. This solution provides a scalable foundation for next-generation “Smart Hospital” infrastructure.

1 Introduction

1.1 The evolution of data persistence in modern computing

The landscape of data storage has undergone a fundamental transformation over the last two decades, driven by the shifting nature of the data itself. Historically, Relational Database Management Systems (RDBMS) like OracleDB, Microsoft SQL Server, and PostgreSQL were architected for transactional consistency. These systems rely on the ACID (Atomicity, Consistency, Isolation, Durability) properties to ensure that financial ledgers and enterprise resource planning (ERP) records remain pristine. They utilize B-Tree indexing and write-ahead logging (WAL) to guarantee data integrity on magnetic disk storage. While robust, this architecture introduces significant Input/Output (I/O) overhead, making it ideal for banking systems working with structured data but suboptimal for high-velocity, unstructured streams.

As the internet era matured, the volume of data exploded, necessitating the “NoSQL” revolution. Systems like MongoDB, CouchDB, and Cassandra abandoned rigid schemas in favor of flexible JSON or BSON document storage. These systems prioritize the CAP theorem’s Availability and Partition Tolerance over strict Consistency, allowing for massive horizontal scaling. MongoDB, for instance, excels at storing heterogeneous data from web applications and IoT devices. However, even NoSQL databases often rely on standard file system calls and garbage collection routines that introduce non-deterministic latency spikes—a critical flaw when applied to real-time life-safety systems.

1.2 The data deluge in modern healthcare

The integration of Internet of Medical Things (IoMT) and intelligent video surveillance into clinical workflows has precipitated a massive surge in data velocity and volume. Modern hospitals are no longer mere physical facilities but complex cyber-physical systems generating terabytes of data daily. This data is heterogeneous, ranging from scalar vitals (heart rate, SpO2) to high-dimensional vector data (video feeds, thermal imaging).

The critical challenge lies not in the capture of this data, but in its storage and retrieval speed. Traditional RDBMS architectures were designed for transactional integrity rather than the high-velocity, append-only nature of video event logs. While they offer robust consistency, the overhead of transaction logs, locking mechanisms, and disk I/O scheduling introduces unacceptable latency for real-time AI analytics (see Figure 1).

Figure 1

1.3 The specific challenge of intelligent video surveillance (IVS)

Intelligent Video Surveillance represents a unique class of “Big Data” problem. Unlike a typical web application that is “Read-Heavy” (many users viewing content), a surveillance system is “Write-Heavy” (constant recording). When augmented with Artificial Intelligence (AI) for patient monitoring, the data profile changes again. It becomes “Write-Intense, Compute-Intense, and Latency-Critical.”

1.4 Latency constraints in critical care

In clinical environments, the time between a physiological event and medical intervention is critical. We define the “Latency-Critical Window” as the maximum allowable delay for data persistence and visualization. For conditions such as ventricular fibrillation or post-operative tube dislodgement, delays exceeding 1-2 s—common in disk-bound RDBMS during log flushes—can compromise patient outcomes.

1.5 The latency gap in real-time diagnostics

1.5.1 Case study: the “golden hour” scenario

To contextualize the necessity for a millisecond-latency database, consider the clinical concept of the “Golden Hour” in stroke and trauma care, where time is directly correlated with tissue survival.

1.5.1.1 Scenario: post-operative ICU monitoring

Context: A 65-year-old patient recovering from cardiac bypass surgery is in the ICU. The patient is monitored by an intelligent camera system trained to detect “agitation” and “tube dislodgement” (a common, life-threatening complication).

1.5.1.2 Event chain in a traditional SQL environment

1.5.1.3 Event chain in a high-speed RAM environment (proposed)

1.6 Hardware enablers: the shift to in-memory computing

The feasibility of keeping entire surveillance databases in RAM has drastically changed in recent years. In 2010, server RAM was expensive ($100/GB). Today, commodity servers can easily support 512 GB or 1 TB of RAM. This shift allows us to reconsider the fundamental assumption of databases: that “Disk is for Storage, RAM is for Cache.” For a 24 h loop of surveillance metadata (excluding raw video files, which go to disk storage), the event logs fit comfortably within 4–8 GB of RAM. This realization is the cornerstone of our proposed solution. By treating RAM as the primary persistence layer (with asynchronous disk backing), we can achieve speeds limited only by the system bus bandwidth, rather than mechanical drive heads or NAND flash controllers.

1.7 Novelty, contributions, and scope

1.7.1 Novelty

While In-Memory Database Systems (IMDBS) like SAP HANA and Redis are established, they incur a “General Purpose Tax”—overhead from query parsing (SQL/MQL), network protocols (TCP/IP), and concurrency control (MVCC) required to support broad use cases. The novelty of SubDataBase-0.91s lies in its task-specificity. By utilizing a lock-free Ring Buffer with direct pointer arithmetic () and bypassing the OS network stack entirely via shared memory, we achieve latencies physically impossible for general-purpose systems.

1.7.2 Contributions

1.7.3 Scope

This system is strictly designed for High-Velocity, Append-Only streams (e.g., video analytics, patient vitals). It is not intended for complex analytical queries (OLAP), billing, or inventory management, where traditional ACID-compliant SQL databases remain superior.

1.8 Comparison of database paradigms

To understand the necessity of a custom solution, we must analyze the structural limitations of existing paradigms. Table 2 illustrates the trade-offs faced by system architects in healthcare. This paper proposes a radical simplification: a purpose-built, RAM-resident storage engine that bypasses the operating system’s file cache and network stack overheads for local operations, synchronizing to disk only for persistence. This approach specifically targets the “Event” and “Frame Meta-data” layer of the surveillance stack.

The remainder of this paper is structured as follows: Section 2 reviews the existing literature on surveillance storage systems and identifies critical architectural gaps. Section 3 mathematically formulates the latency constraints and analyzes the write amplification bottleneck in traditional DBMS. Section 4 presents the high-level architecture of SubDataBase-0.91s, focusing on the zero-copy memory model. Section 5 details the core implementation, including the lock-free ring buffer and asynchronous persistence strategy. Section 6 provides real-world case studies from a hospital deployment. Section 7 presents rigorous experimental benchmarks, validity analyses, and ablation studies. Finally, Section 8 concludes the paper and outlines future directions for hardware acceleration.

2 Related works

The domain of Intelligent Video Surveillance (IVS) sits at the intersection of computer vision, network engineering, and database management. While significant advancements have been made in image recognition algorithms (YOLO, ResNet), the underlying storage infrastructure has largely remained stagnant, relying on paradigms developed for different eras of computing. This section reviews the current state of commercial ecosystems, analyzes academic proposals, and identifies the critical gaps that necessitate the development of a dedicated In-Memory DBMS.

2.1 Commercial surveillance ecosystems and architectural limitations

The global market for video surveillance is currently dominated by integrated hardware-software solutions that prioritize capacity over velocity. These systems generally fall into three architectural categories: Traditional NVR/DVR, Cloud-Hosted, and Hybrid Enterprise solutions.

2.1.1 Network video recorders (NVR) and file system fragmentation

2.1.2 Cloud-based solutions and the latency penalty

2.1.3 Enterprise and hybrid solutions

High-end solutions from Hikvision (HiWatch) and Dahua utilize sophisticated RAID arrays and caching hierarchies. However, their internal databases are proprietary “Black Boxes.” This closed architecture prevents deep integration with custom medical AI models (e.g., specific posture detection for post-op recovery), forcing hospitals to rely on generic APIs that may not expose real-time raw data handles.

Table 3 summarizes the technical bottlenecks of these prevailing commercial architectures.

2.2 Limitations of general-purpose database paradigms

Beyond commercial appliances, system architects often attempt to build custom surveillance stacks using general-purpose databases. However, both SQL and NoSQL paradigms exhibit specific frictions when applied to high-velocity video metadata.

2.2.1 The RDBMS impedance mismatch

2.2.2 NoSQL and time-series databases

2.3 Academic research in high-performance storage

Academic literature has addressed various aspects of storage optimization, though rarely with a focus on RAM-resident persistence for healthcare.

2.3.1 Analytics-aware storage

Ma et al. [1] proposed storage systems optimized for retrieval, using metadata tagging to speed up forensic searches. However, their approach focuses on post-event analysis (e.g., “Find all red cars from yesterday”) rather than real-time visualization (e.g., “Alert me immediately if a patient falls”). The buffering mechanisms used to optimize disk writes in their model actually increase the time-to-visibility for live events.

2.3.2 Edge computing and digital twins

Rajavel et al. [2] and several other researchers [3–6] have explored edge computing architectures where processing occurs near the sensor. While they successfully offload CPU tasks from the central server, they often gloss over the storage layer, assuming a local SQLite or text-file log is sufficient. Our research indicates that as Edge AI becomes more complex (tracking 50+ skeletal points per person), the local storage I/O becomes the new bottleneck, necessitating a high-performance engine like SubDataBase-0.91s even at the edge.

2.4 Case study: anatomy of a storage failure in a hybrid system

To illustrate the critical failure modes of traditional architectures, we analyze a documented failure scenario in a pilot Smart Hospital deployment using a hybrid SQL/Redis architecture.

Figure 2

2.5 Gap analysis

Existing literature and commercial products fundamentally treat the database as a ‘Black Box’ component, assuming that standard tuning parameters can solve latency issues (7–9). There is a distinct paucity of research on designing storage engines specifically for the write patterns of AI-video streams (10, 11).

This paper fills these gaps by presenting the architecture and implementation of “SubDataBase-0.91s,” a system that discards universality in favor of extreme, domain-specific performance.

2.6 Comparison with enterprise in-memory database systems

While generic NoSQL systems (e.g., Redis, MongoDB) are common in web stacks, enterprise-grade In-Memory Database Systems (IMDBS) such as SAP HANA, VoltDB, and Microsoft SQL Server Hekaton have set the standard for high-performance transactions (19, 20). However, their architecture presents specific limitations for edge-based video surveillance:

3 Problem definition

The challenge of engineering storage for Intelligent Video Surveillance (IVS) in healthcare is not merely a matter of capacity; it is a complex problem of temporal consistency and high-concurrency throughput. Unlike standard IT workloads, which follow predictable diurnal patterns, hospital surveillance data is stochastic and bursty. This section mathematically formulates the latency constraints, analyzes the “Write Amplification” phenomenon in traditional DBMS, and models the system failure points under high load.

3.1 Mathematical formulation of system latency

3.1.1 The variable latency of

Figure 3

3.2 The data tsunami: throughput quantification

To understand the scale of the problem, we must quantify the data generation rates of a modern “Smart Hospital.” Table 5 illustrates the IOPS (Input/Output Operations Per Second) requirements for different deployment scales, assuming a setup where every frame is analyzed for potential metadata generation (e.g., continuous heart rate monitoring via facial capillary analysis).

As shown, a single department generates nearly 2,000 logical writes per second. Standard SATA SSDs often saturate around 10,000 random IOPS, meaning a single departmental server is operating near its theoretical limit just to sustain baseline recording, leaving no headroom for read queries by doctors.

3.3 The “write amplification” bottleneck

3.4 Case study: the “thundering herd” failure mode

To demonstrate the fragility of current architectures, we define a failure mode specific to mass-casualty or emergency scenarios, termed the “Thundering Herd.”

3.4.1 Scenario

3.4.2 Failure analysis in SQL/hybrid systems

3.5 The read-while-write contention paradox

3.6 Summary of architectural requirements

4 Storage systems for video surveillance

The architecture of the storage layer is the distinct determinant of performance in an Intelligent Video Surveillance (IVS) system. While the camera hardware determines image quality and the AI model determines detection accuracy, the storage engine determines the system’s “responsiveness.” This section deconstructs standard storage models, mathematically quantifies their inefficiencies, and details the structural design of the proposed RAM-resident solution.

4.1 Standard relational data schemas

Most commercial surveillance systems (e.g., Milestone, Genetec, custom SQL implementations) rely on a variation of the classic “Three-Pillar” relational schema. This structure, designed for referential integrity, becomes a liability under high-velocity write loads.

Figure 4

4.1.1 The “fat table” problem

In a standard SQL implementation, the “events_log” table typically contains the following columns: “ID” (BigInt), “Timestamp” (DateTime), “CameraID” (FK), “EventType” (Varchar), “Confidence” (Float), “SnapshotPath” (Varchar), and “Metadata” (JSON/Text).

4.2 Case study: the schema migration outage

A critical failure mode of relational databases in agile healthcare environments is the “Schema Lock.”

4.2.1 Scenario

4.3 The computational cost of serialization (JSON/BSON)

Modern “schemaless” databases (MongoDB, PostgreSQL JSONB) attempt to solve the schema rigidity problem by storing data as documents. While flexible, this introduces a hidden computational tax: Serialization.

For every event written to a NoSQL database, the CPU must transact the following pipeline (defined in Equation 4):Where is the time taken to convert an in-memory object (struct) into a text-based (JSON) or binary-tagged (BSON) string.

4.3.1 Mathematical comparison

As shown, the “overhead” of flexibility is a 95% reduction in theoretical throughput. For a dedicated safety system where the data structure is known (Time, Location, Type), this flexibility is unnecessary.

4.4 Architecture of the proposed solution: SubDataBase-0.91s

To address the identified limitations—Locking, Schema Rigidity, and Serialization—we developed “SubDataBase-0.91s.” The architecture mimics the design of high-frequency trading (HFT) engines rather than web databases.

4.4.1 Direct memory mapping (zero-copy IO)

The core innovation is the bypass of the OS Kernel’s network stack. In a standard setup (e.g., connecting to localhost MySQL), data travels: “App User Buffer Kernel Buffer TCP Stack Kernel Buffer DB Buffer.”

SubDataBase uses a Shared Memory model (or Memory Mapped File in Windows/Linux): “App -¿ Shared RAM -¿ DB Reader.”

This reduces the latency floor from (TCP loopback) to (RAM access), a 2,000 improvement in physical transport speed.

4.4.2 The ring buffer implementation

By including “padding” bytes in the struct definition, we solve the “Schema Migration” problem discussed in Section 4.2. If we need to add a new field later, we simply claim bytes from the padding, requiring no table rebuilds and zero downtime.

4.4.3 Asynchronous persistence (the “lazy-write” strategy)

4.5 Summary of architectural advantages

Table 7 summarizes how the proposed architecture specifically targets the failure modes of previous generations.

This design moves the bottleneck from the disk I/O controller to the DDR4/DDR5 RAM bus, effectively solving the throughput challenge for the next decade of medical surveillance scaling.

5 Problem solution: SubDataBase-0.91s implementation

To resolve the latency bottlenecks identified in the problem definition—specifically the mismatch between generic database IOPS and surveillance throughput requirements—we designed and implemented “SubDataBase-0.91s.” This section details the internal mechanics of the engine, focusing on its memory addressing logic, concurrency models, and the specific algorithms used to achieve deterministic microsecond-level latency.

5.1 Core engine architecture

The fundamental design philosophy of SubDataBase-0.91s is “Hardware-Sympathetic Programming.” Unlike general-purpose databases that abstract hardware details behind layers of query optimizers and virtual machines, SubDataBase is tightly coupled to the underlying x86-64 memory architecture.

5.1.1 Memory layout and addressing mathematics

In traditional RDBMS, locating a record involves traversing a B-Tree structure ( complexity). In SubDataBase, we utilize direct pointer arithmetic ( complexity).

The memory block is divided into fixed-size “Pages,” but unlike OS pages (4 KB), our pages align with the “EventRow” structure size (see Listing 1) to prevent fragmentation. Let be the base memory address of the database. Let be the size of a single event row (128 bytes). The address of the -th event is calculated as (Equation 5):This calculation takes a single CPU cycle. To handle the circular buffer logic (Ring Buffer), the index is effectively , where is the maximum capacity of the allocated block (as demonstrated in Listing 2).

This “Zero-Search” architecture is why read operations consistently clock under 100 nanoseconds, regardless of database size.

5.2 Concurrency control: lock-free writing

A critical requirement for high-velocity streams is preventing “Writer Blocking.” Standard databases use Mutexes or Read-Write locks. If a writer holds a lock, readers must wait.

5.3 Persistence strategy: the “twin-log” system

To satisfy the durability requirement without stalling the main memory thread, we implemented a “Twin-Log” asynchronous persistence strategy utilizing nnCron.

Clinical Safety Justification (The ACID Trade-off): In critical patient care, the risk of delayed action often exceeds the risk of data volatility. A standard ACID database might delay a “Cardiac Arrest” alert by 500 ms waiting for a disk commit confirmation. SubDataBase-0.91s eliminates this wait. While there is a theoretical risk of losing the last 0.91 s of data during a catastrophic power failure, this “Bounded Volatility” is acceptable because the primary goal of the system—immediate staff mobilization—requires the alert to be displayed instantly, not persisted instantly.

Clinical Implications of Bounded Volatility & Safeguards: The “Bounded Volatility” model implies a maximum theoretical data loss of 1 s (the asynchronous flush interval) during catastrophic power failure. Clinically, if an event occurs at and power fails at , the event is pushed to the dashboard at (safeguarding immediate response), even if it is not persisted to disk. To mitigate this, the system employs a UPS-Interlock Signal. Upon detecting mains power loss via GPIO interrupts, the daemon intercepts the SIGTERM signal and forces an immediate synchronous flush (msync(MS_SYNC)) of dirty RAM pages before battery depletion.

5.3.1 Failure recovery algorithm

5.4 Case study B: resilience under “hard kill” conditions

5.5 Implementation of the visualization bridge

SubDataBase is not just a storage bucket; it is designed to drive the frontend UI directly. The “Visualization Bridge” is a WebSocket server embedded within the database process.

5.6 Comparative code complexity

One of the hidden advantages of this implementation is the reduction in code complexity. Table 8 compares the lines of code (LOC) required to implement the “Event Insert” logic in our custom engine vs. a standard ORM-based stack.

This drastic reduction in complexity minimizes the surface area for bugs and security vulnerabilities, a crucial trait for medical-grade software.

5.7 Advanced feature: the “time-travel” ring buffer

To support forensic analysis (e.g., “Show me what happened 10 s before the fall”), SubDataBase implements a “Time-Travel” read pointer. Since the data in the ring buffer is strictly chronological and contiguous in physical memory, fetching the “previous 10 s” is a simple memcpy operation.

5.7.1 Logic

5.8 Summary of implementation specifications

Table 9 provides the final technical specifications of the deployed engine.

The implementation successfully proves that for task-specific, high-velocity workloads, a custom memory-mapped architecture vastly outperforms generic commercial solutions.

5.9 Security implementation

6 Usage example and case studies

To validate the theoretical advantages of the memory-resident architecture, we conducted a series of real-world deployments and high-stress simulations. These case studies were designed to test the system not just under “sunny day” conditions, but under the specific edge cases that cause traditional database architectures to fail in clinical environments.

6.1 Case study A: the “smart ward” deployment at VIT

The primary field test was conducted in a prototype “Smart Ward” environment established at the Vellore Institute of Technology (VIT). The physical setup replicated a standard post-operative recovery room.

6.1.1 Experimental setup

6.1.2 Scenario execution: the bed fall event

A standardized “Bed Fall” scenario was enacted by a stunt actor to measure the end-to-end system latency. The timeline of events was captured using a high-speed external camera (240 FPS) to verify timestamps.

Figure 5

Figure 6

6.1.3 Qualitative clinical feedback

Beyond empirical latency metrics, feedback was gathered from the nursing staff utilizing the “SubDBView” iPad application. Staff reported that eliminating the 2-to-5 second “refresh lag” typical of polling models significantly reduced alarm fatigue and ambiguity. Because alerts (e.g., “Bed Exit Attempt”) appeared synchronously with the physical sound of patient movement, trust in the system’s accuracy was demonstrably higher compared to legacy systems where digital alerts trailed physical events.

6.2 Visualization client architecture

The speed of the database allows for a fundamental shift in client-side architecture. Traditional hospital dashboards use a “Polling” model, asking the server “Are there new events?” every 2–5 s. This introduces an artificial delay.

The “SubDBView” application utilizes a “Push” model. Because the database write operation is virtually instantaneous, the write function itself acts as the event dispatcher.

6.2.1 Data packet structure

Listing 3 shows the lightweight JSON payload pushed to the client. Note that the payload contains only metadata; the heavy image data is referenced via a pointer (“frame_ptr”), which the client loads lazily only if the nurse taps the alert.

6.2.2 Zone mapping logic

The application performs real-time coordinate transformation. The coordinates from the camera’s 2D frame are mapped to the 3D floor plan of the ward using a homography matrix stored in the application cache. This allows the nurse to see exactly where in the room the incident occurred (e.g., “Near Bathroom Door”) rather than just viewing a camera feed.

6.3 Case study B: the “thundering herd” stress test

To test the system’s resilience under mass-casualty or catastrophic failure conditions, we simulated a “Thundering Herd” scenario. This represents a situation where an external trigger (e.g., an earthquake tremor or fire alarm) causes all patients in a hospital wing to move simultaneously, triggering maximum write load from all cameras.

6.3.1 Simulation parameters

6.3.2 Comparative results

We compared SubDataBase-0.91s against Redis (In-Memory Key-Value) and PostgreSQL (Relational), with the detailed behavioral metrics presented in Table 10.

6.4 Longitudinal stability and memory analysis

A common criticism of custom memory-management solutions is the risk of memory leaks over time. We conducted a 72 h continuous “Burn-In” test to verify stability.

Figure 7

6.5 Extended performance benchmarks

To provide a comprehensive reference for future implementations, we benchmarked the system across varying hardware tiers, from Edge devices to Server racks.

The results in Table 11 confirm that the architecture scales linearly with memory bandwidth. Even on a Raspberry Pi 4, the system outperforms a standard MySQL server running on enterprise hardware, making it an ideal solution for “Edge AI” cameras where power and thermal budgets are constrained.

6.6 Operational dashboard for database monitoring

To assist hospital IT administrators, a built-in “Health Check” endpoint was developed. This lightweight JSON endpoint exposes the internal state of the Ring Buffer.

6.7 Summary of case studies

7 Experimental evaluation and methodology

To validate the performance of SubDataBase-0.91s, we conducted a series of benchmarks focusing on write latency, system throughput, and recovery time.

7.1 Experimental setup and hardware configuration

Benchmarks were conducted across three distinct hardware tiers to evaluate scalability. The specific configurations are detailed in Table 12. All tests were performed in a controlled environment with background operating system services minimized.

7.2 Workload generation and statistical validation

7.3 Scenario A: high-concurrency stress test

This scenario, previously described as the “Thundering Herd” effect, simulates a mass-casualty event where all connected sensors trigger simultaneously. Conditions: Traffic was spiked from a baseline of 50 events/s to a sustained peak of 5,000 events/s for a duration of 60 s; the resulting system latency impacts are summarized in Table 13.

7.4 Validity analysis

7.5 Ablation study

To identify the source of the performance gains, we disabled specific optimizations in SubDataBase-0.91s and measured the performance drop. Table 14 summarizes these findings.

8 Conclusion and future scope

8.1 Summary of findings

This research demonstrates that for the specific domain of intelligent video surveillance in healthcare, general-purpose databases introduce unnecessary abstraction layers. By implementing a specialized, RAM-resident storage engine (SubDataBase-0.91s), we achieved an 8.6 speed improvement over MySQL and significantly outperformed Redis in write-heavy workloads. This speed translates directly to patient safety: faster data storage means faster alert visualization.

8.2 Limitations

The primary limitation is the RAM dependency. The dataset size is hard-capped by the server’s physical memory (4 GB in our prototype). While sufficient for a 7-day loop of metadata, it cannot store long-term historical video archives. Therefore, a hybrid architecture is recommended: SubDataBase for the “Hot” data (last 24 h) and a traditional SQL warehouse for “Cold” data archiving.

8.3 Future work

8.4 Integration with traditional SQL warehouses (hybrid architecture)

While SubDataBase-0.91s acts as the “Hot Store” for real-time visualization, long-term archival and OLAP (Online Analytical Processing) queries require a traditional SQL warehouse. To achieve this without introducing locking contention to the RAM buffer, we propose a “Lazy-ETL” background worker.

Challenges: The primary challenge is preventing the archival read process from stalling the high-velocity write pointer in the ring buffer. Solution: The ETL worker reads exclusively from the asynchronous snapshot file (export-0.data), completely decoupling the SQL insert load from the primary memory plane (refer to Listing 4 for the implementation).

References

• 1.

  MaSChenXLiZYangY. A retrieval optimized surveillance video storage system for campus application scenarios. J Electr Comput Eng. (2018) 2018:1–10. 10.1155/2018/2526135

  • CrossRef
  • Google Scholar
  • View reference in article

• 2.

  RajavelRRavichandranSKHarimoorthyKNagappanPGobichettipalayamKR. IoT-based smart healthcare video surveillance system using edge computing. J Ambient Intell Humaniz Comput. (2022) 13:3195–207. 10.1007/s12652-021-03157-1

  • CrossRef
  • Google Scholar
  • View reference in article

• 3.

  ZhukovaNMotienkoALevonevskiyDSubbotinAAnhPT. Smart room for patient monitoring based on IoT technologies. In: Proceedings of AICCC ’23. (2024). p. 151–8.

  • Google Scholar
  • View reference in article

• 4.

  TsaiM-HVenkatasubramanianNHsuC-H. Analytics-aware storage of surveillance videos. IEEE conference proceeding for SMARTCOMP 2020 (Piscataway, NJ: IEEE). (2020) 25–32. 10.1109/SMARTCOMP50058.2020.00024

  • CrossRef
  • Google Scholar
  • View reference in article

• 5.

  ManTOsipovVYZhukovaNSubbotinAIgnatovDI. Neural networks for intelligent multilevel control based on data fusion. Inf Fus. (2024) 110:102427. 10.1016/j.inffus.2024.102427

  • CrossRef
  • Google Scholar
  • View reference in article

• 6.

  SubbotinAZhukovaNGudilovM. Problems of building digital twins of escalators at subway stations. Lect Not Netw Syst. (2024) 1018. 10.1007/978-3-031-62269-4_13

  • CrossRef
  • Google Scholar
  • View reference in article

• 7.

  KhanJLiJPAhamadBParveenSUl HaqAKhanGA, et al. SMSH: secure surveillance mechanism on smart healthcare IoT system. IEEE Access. (2020) 8:15747–67. 10.1109/ACCESS.2020.2966656

  • CrossRef
  • Google Scholar
  • View reference in article

• 8.

  HaseenaSJameelAAl-MuhaishHAl-MughanamTJavidOAl-WesabiFN. Prediction of age and gender based on human face images using deep learning. Comput Math Methods Med. (2022) 2022. 10.1155/2022/1413597

  • CrossRef
  • Google Scholar
  • View reference in article

• 9.

  VodyahoAZhukovaNDelhibabuRSubbotinA. Continuous agile cyber–physical systems architectures based on digital twins. Future Gener Comput Syst. (2024) 153:350–9. 10.1016/j.future.2023.11.024

  • CrossRef
  • Google Scholar
  • View reference in article

• 10.

  XueFWangQGuoG. Transfer: learning relation-aware facial expression representations with transformers. In: ICCV 2021. (2021). p. 3601–10.

  • Google Scholar
  • View reference in article

• 11.

  ToshevASzegedyC. DeepPose: human pose estimation via deep neural networks. In: CVPR 2014. (2014). p. 1653–60.

  • Google Scholar
  • View reference in article

• 12.

  JuangL-HWuM-N. Fall down detection under smart home system. J Med Syst. (2015) 39:1–12. 10.1007/s10916-015-0286-3

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 13.

  FleckSStraßerW. Smart camera based monitoring system and its application to assisted living. Proc IEEE. (2008) 96(10):1698–714. 10.1109/JPROC.2008.928765

  • CrossRef
  • Google Scholar
  • View reference in article

• 14.

  AlamoodiAHGarfanSZaidanBBZaidanAAShuwandyMLAlaaM, et al. A systematic review into the assessment of medical apps. Health Technol. (2020) 10:1045–61. 10.1007/s12553-020-00451-4

  • CrossRef
  • Google Scholar
  • View reference in article

• 15.

  Maldonado-BascónSIglesias-IglesiasCMartín-MartínPLafuente-ArroyoS. Fallen people detection capabilities using assistive robot. Electronics. (2019) 8(9):915. 10.3390/electronics8090915

  • CrossRef
  • Google Scholar
  • View reference in article

• 16.

  SunKXiaoBLiuDWangJ. Deep high-resolution representation learning for human pose estimation. In: CVPR 2019. (2019). p. 5693–703.

  • Google Scholar
  • View reference in article

• 17.

  ZengDLinZYanXLiuYWangFTangB. Face2exp: combating data biases for facial expression recognition. In: CVPR 2022. (2022). p. 20291–300.

  • Google Scholar
  • View reference in article

• 18.

  WuYArulrajJLinJXianRPavloA. An empirical evaluation of in-memory multi-version concurrency control. Proc VLDB Endow. (2017) 10(7):781–92. 10.14778/3067421.3067427

  • CrossRef
  • Google Scholar
  • View reference in article

• 19.

  DiaconuCFreedmanCIsmertELarsonP˚AMittalPStonecipherRet alHekaton: SQL server’s memory-optimized OLTP engine. In: Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data. (2013). p. 1243–54.

  • Google Scholar
  • View reference in article

• 20.

  LamWLiuLPrasadSRajaramanAVacheriZDoanA. SAP HANA: the evolution from a common database platform for real-time business. Proc VLDB Endow. (2012) 5(12):1814–25. 10.14778/2367502.2367520

  • CrossRef
  • Google Scholar
  • View reference in article