IoT Application Brief

Sorry, your browser does not support inline SVG.

How YottaDB Solves IoT Challenges

This hypothetical parking use case illustrates YottaDB’s ability to meet application needs from sensors and devices to the cloud.

  • A parking garage with sensors on each parking space to permit a display of the number of free parking spaces would likely not be considered an IoT application.
  • Multiple parking garages downtown that provide their parking rates and available space in real-time to a service feeding the navigation apps of drivers in order to direct inbound commuters to parking available near their destinations would be considered an IoT application.
  • Using a smartphone app, drivers can be automatically charged for parking.
  • A service might provide parking garage operators with information on the availability of parking at nearby competing establishments, and the number of drivers heading downtown, allowing them to dynamically change their prices.
  • Drivers who regularly park in a garage will be more satisfied if the garage is likely to have space available for them, especially on days when demand is high. From the garage operator’s point of view, profitability will be higher if they have regular customers who choose to park with them even on days without high demand because those regular customers find space available on days with high demand. A garage owner may wish to indicate a full garage for the commuting masses even while some spaces are still unfilled, while indicating space availability to regular customers. To maximize profitability, they need to do this as accurately as possible in order to have neither unfilled spaces nor dissatisfied customers who find no parking spaces available even when they have been directed to the garage.

Challenges at the Edge

A parking sensor may have a minimal CPU, and perhaps only ROM (read-only memory) and RAM (random access memory) with no persistent storage. It may run on batteries (and therefore require energy efficient computing), perhaps communicating wirelessly with adjacent sensors in a mesh network which allows aggregation of data at a central location in each garage. Software for this environment must be robust, able to operate indefinitely without attention.

How YottaDB Addresses Edge Device Constraints

YottaDB fits into and runs well on low end computing platforms found in devices and smart sensors – for example, the Raspberry Pi Zero is a Supported platform. Should you want us to, we can port YottaDB to and support it on a computing platform of your choice. YottaDB’s daemon-less database engine is parsimonious in its use of CPU and other system resources. Operation of a YottaDB database can be completely automated with scripting. Depending on the CPU architecture of the platform, the footprint of the YottaDB engine itself is just 10-13MB. On systems without persistent read-write storage, you can install YottaDB in ROM (Read-Only Memory) with the database in a RAM (Random-Access Memory) filesystem.

Using built-in real-time database replication over TCP using certificate-secured TLS (SSL), you can configure and operate a remote real-time copy of the data for persistence, and create scripts on power-up to automatically restore the database of a device from the remote copy. Furthermore, putting a database in a device or smart sensor allows raw data to be stored continuously, not just calculated results. Depending on the application or the sensor, this can allow determination of wear and tear, and possibly predicting failures before they occur.

IoT Security Concerns

A smartphone running a navigation app is a capable computer in its own right, equivalent to a personal computer or laptop, with a four- or eight-core CPU, several gigabytes of RAM, and tens to hundreds of gigabytes of persistent storage. As one cannot predict what other software may reside and execute in the same milieu, security is critical.

How YottaDB Addresses IoT Security

YottaDB has a track record of security proven by decades of use in real-time banking and health care. WIth a philosophy that complexity is the enemy of security, the security model of YottaDB is simple, based on the well-known user-group-world permissions as implemented by the operating system, and easily explained in a few pages in an appendix of the Administration and Operations Guide.

YottaDB lends itself to additional security, such as role-based mandatory access controls implemented by common layered security packages such as Security Enhanced Linux (SELinux). Encrypted databases are a mature, standard feature of YottaDB. Location data, virtual wallets, and other sensitive information can be stored in a YottaDB database on a smartphone. Storing the information on the device makes it available even if the concrete structure of a parking garage blocks cellular signals.

Using encryption over TLS (SSL), and YottaDB’s replication that uses network bandwidth sparingly, an application provider can maintain a copies of device databases in a data centers, to facilitate restoration when users replace devices. The robust protocol used by YottaB replication means that when network connectivity is restored – for example, when a commuter leaves the parking garage – the copy of the device database in the data center catches up automatically and securely.

The Importance of Strong Cloud Security

Security requirements in a cloud are different from those in the edge. In a device or smart sensor, what data exists is narrow in scope, even if it exists in the edge. Systems and software in data centers are in data centers that are well fortified behind layers of defenses.

However, unlike devices in the edge, they have data that is both broad (many customers and many types of data) and deep (covering long periods of time). Apart from the larger value to be gained from a successful attack, even with database encryption, the attack surface is larger because there is a large volume of long-loved data with a somewhat regular structure.

How YottaDB Addresses Data Security in the Cloud

YottaDB’s database encryption uses a different initialization vector for each database block (so two blocks with identical cleartext data will have very different ciphertext), and furthermore allows the encryption key to be changed even as a database is in use, which is not unlike our commuters above being able to change the oil in their vehicles while driving down the highway.

Real-Time, Always-On Performance Demands

Transactional systems are real-time systems. They gather data from edge devices, and in turn, provide real-time data back to the edge. For example, a transactional system would continuously receive location information from vehicles, parking space availability from garages, and then feed that information back to vehicles.

A transactional system may also deal with financial information, such as allowing drivers to pay for parking remotely through their smartphones. A real-time transactional system must also be continuously available with assured response times – it would not be acceptable for such a service to become unavailable, especially during busy times.

How YottaDB Addresses Highly Available, Real-Time Transactional Workloads

YottaDB has functionality for deploying Logical Multi-Site (LMS) application configurations. In the event a primary node goes down, a secondary node can be switched to a primary role in seconds. Unlike traditional, so-called high-availability clusters, which are vulnerable to the loss of the hardware and software of the cluster itself, YottaDB LMS configurations are built with “share nothing” computing nodes.

Furthermore, with today’s computing systems, it is not hard to achieve “five nines” availability in the face of unplanned events such as system crashes. It is much harder to achieve 99.999% availability in the face of planned events, such as application upgrades. YottaDB’s architecture allows for LMS deployment of applications that can remain continuously available even as the underlying hardware and software are upgraded. It can also remain available during application upgrades that involve a change to the schema of the data stored in the database.

YottaDB’s extremely efficient database engine provides for extremely responsive service levels. For financial transactions that require ACID (Atomic, Consistent, Isolated, Durable) properties, YottaDB’s Optimistic Concurrency Control allows the application to exploit parallelism, even in commodity computer systems, to achieve high levels of responsive transaction throughput. This claim is backed by the fact that the YottaDB database engine is in daily production use at several of the world’s largest real-time core banking applications that we know of, with response times in the milliseconds to tens of milliseconds, as well as at least one nation-scale electronic health-record deployment.

IoT Systems Create More Value with More Data

Today’s cloud systems are extremely powerful in CPU, memory, storage and connectivity. They may appear to have unlimited resources for the machine learning/AI applications needed to tell garage owners when to indicate space availability only for regular customers, but it is a truism that applications grow to fill their computing platforms.

If there is unused computing capacity, there is always some new data or service to be considered for improving accuracy – weather, traffic delays, public transportation status, events, etc. Or some new output could be added, such as helping operators set opening prices in anticipation of demand to help maximize profitability. These new inputs and outputs that can drive even more business value are always waiting in the wings to consume that unused capacity.

How YottaDB Address Big Data Challenges for IoT

YottaDB is well suited to the “three V’s” of big data – Volume, Variety, and Velocity.

Volume – YottaDB’s hierarchical key-value (or associative memory, or sparse array – the terms are equivalent) datastore is uses space efficiently thanks to key-compression. With its ability to distribute (or shard) a database over database files at the level of keys, YottaDB’s ability to manage and manipulate large volumes of data is limited only by available storage and the inherent capacity of the underlying computing platform.

Variety – Data organization in YottaDB’s data store is a superset of the relational model – every relational scheme can be stored in YottaDB, but not every YottaDB schema can be stored in an RDBMS. Indeed, the common NoSQL use cases all map simply and efficiently onto YottaDB’s datastore. YottaDB can handle whatever data may be brought in for consideration and manipulation.

Velocity – With YottaDB’s database engine, there is no database daemon to be a bottleneck throttling throughput, and processes cooperate to manage the database to maximize throughput for all processes.

Ready to Try YottaDB?