Achieving distributed device situational awareness through cloud-based data management

Many use-cases from large-scale distributed systems require the correlation of real-time and historical data to achieve situational awareness and transform raw data into information. Traditional RDBMS databases cannot keep up with the data rates present in these large distributed systems, and are inefficient at running the kinds of queries needed to retrieve important information.

The recent explosion of virtualization and cloud based data management systems, known as NoSQL databases, allows us to approach these problems in an innovative way.

Use-cases for real-time data management are emerging in a large number of seemingly unrelated fields such as heavy industry, financial services, cyber security, transportation and aerospace and defense. Finding solutions to the situational awareness problem is essential to enable the next phase of the wired and wirelessly distributed and mobile society.

In this article I will outline how to achieve situational awareness by connecting a distributed system to cloud-based data management tools. Using examples from several fields I will show how real-time and historical data can be combined to give the analyst a complete picture of emerging situations, as well as post-event analysis.

When talking about cloud-based solutions many immediately jump to large public offerings such as Amazon Web Services. These kinds of systems are not suitable for real-time distributed systems, and therefore are not the focus of this article. When referring to cloud computing in this article I’m referring to the definition of computing as a service. Integrating cloud computing with real-time distributed systems requires the existence of a private and dedicated cloud. (Figure 1 below).

Figure 1. Real-time wired and wirelessly distributed systems in the cloud require the use of a private and dedicated cloud management system.

The CAP Theorem and Implications

Distributed real-time data management is subject to Brewer’s Theorem, also known as the Consistency-Availability-Partitioning (CAP) theorem. Brewer’s theorem states that a distributed computer system cannot simultaneously provide Consistency, Availability and tolerance to network Partitioning (Brewer, 2000). Adding real-time requirements further constrains the system capabilities to the point where it may not be able to provide more than one of these desired properties: Availability.

One fundamental property of some NoSQL databases (Apache Cassandra) which is very useful in this context is the homogenous nature of system nodes. There are no super-nodes, and the system can interact with any node interchangeably. Therefore as long as the system has access to a single node data storage can continue, although correlation, retrieval and distribution may fail if the data is not in the available partition of the system.

The CAP theorem combined with real-time constraints places a greater burden on understanding and gathering requirements as well as designing scalable system. I would argue that in all software design understanding and categorizing requirements is the most essential project phase. In the case of large-scale data management systems it is even more important — there are fundamental and challenging trade-offs to consider and design for.