IoT Application Brief

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.

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.

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.