fbpx
Connecting database performance and business value – a fast edge database is a money saver

Connecting database performance and business value – a fast edge database is a money saver

We frequently get asked:   “Why does database performance matter?” “What is the business value of database speed?” 

As a developer, it seems clear that database performance matters. At the very least, a fast database that gives you out-of-the-box speed saves time and nerves during development. Any piece of the tech stack that works superfast makes a developer’s job easier. But there is more to it. And in the following, we will reason why and how database performance impacts businesses to hopefully inspire ideas on how to quantify this for your business case.

Data should be available when need where needed

We all dream of a future transformed by data. Cars that drive themselves to be repaired before a failure occurs. Fridges that are restocked while we are at work. Reducing resource waste to an absolute minimum. Building sustainable cities and communities.[1] It is truly amazing what is possible today…

Then reality hits: Before you can implement amazing solutions to make the world a better place for everyone, someone needs to solve the technical challenges, including hidden requirements. For example: you need the necessary data, and you need it available when needed where needed. This often isn’t that simple. Data persistence, database speed, and data synchronization are typical non-functional or “hidden” requirements. These are prerequisite technologies to allow the application to access, process and possibly depict the data required to answer a request (from another application or from a user), and thus enable the functionalities /  features. All in all, this is a pretty fundamental requirement. And it pays off to build your app on top of a solid foundation. Because, if you built your application on a solid foundation, every feature you dream up, no matter when,  and any next feature will be easier and faster to implement. 

Functional and non-functional requirements – the hidden challenges of your IoT project

While you need data in any application, most often no one will write down where and how to handle it  as a user story or requirement. As opposed to features, e.g. “being able to search for names in the address book”, data persistence, database speed, and often even data synchronization are “hidden requirements”. Data is just expected to be available where needed when needed. Whether  the data you need really will be available when you need it, depends strongly on the database the application is using and and where this database runs. On top, the mechanisms you employ to exchange data between different devices (end devices, servers, ….) matter.

Hidden requirements are one of the major reasons why the Industry 4.0 dream is still in many respects a dream and not a reality – in Europe at least. Despite it being a topic for more than 10 years. [2]

Database performance 

What is a database?

A database is a piece of software that allows the storage and systematic use of digital information. A database typically allows developers to store, access, search, update, query, and otherwise manipulate data in the database via a developer language or API. These types of operations are done within an application, in the background, typically hidden from end users. Most applications need a database as part of their technology stack.

What is database performance?

We like and therefore use the following definition from Craig Mullins (2002): “Database performance can be defined as the optimization of resource use to increase throughput and minimize contention, enabling the largest possible workload to be processed.” [3]

Why does it matter if the database runs on the edge or in the cloud?

An edge database holds data on the (end) devices, where the data is used – and typically additionally sends some parts of the data to a central place like an on-premise server or the cloud. As opposed to this, a server / cloud-based database holds all data on the server / in the cloud. Where the data sits, determines from where, when and how it can be accessed. If all data is on a central server or the cloud, the prerequisite to accessing this data is a working network connection.

Online

Offline

It follows that edge applications are based upon a distributed computing paradigm, allowing edge devices to be autonomous. On the other hand, cloud-based applications are based on the centralized computing paradigm, where one central instance is in charge, with all other devices being dependent upon this central instance. This significantly affects the response time of the application, the availability of the application, and last not least the bandwidth needed for the application, which also translates into cloud costs.

Location matters: while a fast database gives you fast response times, if the database sits in the cloud and needs to be called from edge devices, you need to factor in  the duration it takes to request the data and get a response. And with any networking you cannot guarantee response times or ensure it is always available. While this is not the database performance itself, it highly affects application performance. 

The impact of database performance on your business

Database performance matters. Whether your solution needs the speed, because of the necessity to re-act in (near) realtime, or to keep your users (customers, employees, …) happy, productive, buying, or just to save costs for stronger edge hardware and the cloud. “Considering that even a single moment of latency or downtime can cost companies thousands of dollars, the speed advantages of edge computing cannot be overlooked.” [4]

The necessity of database speed for mission-critical, security relevant, (near) real-time functionalities 

If you need near real time functionalities, every piece in the tech stack matters, but the database has a particularly strong impact on the response rates of your application. Consider autonomous driving, healthcare and security applications, or IIoT solutions for production lines: Any application supporting such a scenario needs to respond reliably with speed. “This is not the same as a lag in loading your favorite cat pictures. A lag in a moving vehicle scenario is a matter of life and death.” [5]

Accordingly, if end devices like cars, smartphones, health trackers, machines on the factory floor are involved, a purely cloud-based application is not an option. Data needs to be stored and used on the devices directly. Thus, an edge database is necessary. Ideally, an extremely fast one.

Examples of use cases with a need for database speed

Autonomous driving capabilities are a special edge computing case that requires significant compute power to run the algorithms in real-time within the control unit of the car. As can be easily deducted from first-hand driving experience, during this kind of constant information processing and instantaneous decision making, every millisecond counts. Information processing speed and reliability (guaranteed QoS parameters)  is of the essence for autonomous driving.

Moving to a purely monetary example, let’s consider roadside tolling. In roadside tolling, the edge devices on the side of the road need to process the information from a moving vehicle in order to identify the car, bill according to usage, and detect violators. Ideally, it even informs the car owner of the result. As the car is constantly moving and can be going fast, all of this needs to happen in a very short amount of time. A super fast database lookup on the edge is key to avoid money loss and deliver good customer service. 

For a final example,  let us look at additive manufacturing. 3D printers use layering techniques with a variety of materials to quickly create custom designed parts. During the layering process, the controller needs to quickly and efficiently incorporate small changes in the environment (e.g. an increase in temperature) to ensure quality and accuracy of the part. Faster and more precise manufacturing is currently limited by the I/O throughput. With a fast database, the I/O throughput is higher, allowing for more complex and finite production.

In short: A superfast database is not a nice to-have, it is a must-have. The database speed a database brings out-of-the-box is critical for such an application.

 

The impact of database speed on Sales, Conversions, Retention (or at least, nerves) 

There is a reason Google forces companies to optimize their websites and mobile applications for performance: There is a wealth of research and evidence that suggests response rates of websites and mobile applications impact user behavior significantly. [6] Even more, there are several studies providing evidence that response rates impact actual buying behavior. [7] While there is less research on other digital applications like e.g. a desktop app or workplace software, some studies have shown that needing to work with slow applications decreases employee satisfaction and productivity. [8]

The impact of database speed on battery, CPU, hardware and related resources

Another hidden requirement typically is resource-efficiency with regards to CPU, RAM, Disc space and battery / electricity. For any application running in the cloud, these requirements are balanced in the backend as the cloud scales vertically. It “only” adds to cloud costs (and is a waste of energy – not to mention all the infrastructure / hardware enabling that waste). 

On the edge, you typically work with restricted devices, meaning you can only use the devices’ resources, which can be pretty limited. Therefore, inefficient applications can push a device to its limits, leading to e.g. slow response rates, crashes, and battery drain. Security is a cross-the-stack functionality that often impacts performance. Adding security to every layer accordingly means the performance impact will be significant. 

How database performance impacts the business value of your IoT application

All applications on one device share the available hardware capabilities; resource allocation is managed by the operating system. Accordingly, the more resources an application or the database uses, the less resources are available for other uses. The faster a database executes its operations, the less CPU it uses, the less battery / electricity, and typically also memory. In practice that means there are more resources available on the device to run e.g. Edge AI or Edge ML applications.

From a business value perspective that means:

  • You can save on hardware costs (CPU, RAM, Disc, Memory, …): either do more on existing / chosen hardware, upgrade hardware later or choose smaller and thus less expensive hardware. 
  • You can save on energy and cloud costs: The more efficient, the less electricity, the less cloud costs. This can add up tremendously as projects scale.
  • You can add more features, deliver more functionalities, make your application more secure within a given environment. 
  • You can deliver a smooth, fast user experience, enabling applications that deliver in near-realtime. 

    In sum, it clearly impacts the cost structure and value you can deliver.

Database performance impacts business value, directly and indirectly

As projects scale in size and scope, hidden requirements like database performance often become clear. At scale, small issues like delayed data, or data volumes, become big headaches. Ideally, these sorts of requirements would be at the heart of the design stage of any project – and budgeted for at the beginning. The choice of database clearly has a huge impact on the business success of IoT applications.

[1] See https://www.weforum.org/agenda/2018/01/effect-technology-sustainability-sdgs-internet-things-iot/ for IoT impact on Sustainable Development Goals (SDG)
[2] https://restart-project.eu/much-know-industry-4-0/
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=13&cad=rja&uact=8&ved=2ahUKEwiGidSA6trnAhVQY8AKHTpSDUIQFjAMegQICBAB&url=https%3A%2F%2Fwww.mdpi.com%2F2076-3387%2F9%2F3%2F71%2Fpdf&usg=AOvVaw3cx44OOMfNzJ_BJlCG8Gfj
[3] Database Administration: The Complete Guide to Practices and Procedures By Craig Mullins 2002
[4] https://www.vxchnge.com/blog/the-5-best-benefits-of-edge-computing
[5] https://www.zdnet.com/article/why-autonomous-vehicles-will-rely-on-edge-computing-and-not-the-cloud/
[6] https://developers.google.com/web/fundamentals/performance/why-performance-matters https://www.thinkwithgoogle.com/intl/en-154/insights-inspiration/research-data/need-mobile-speed-how-mobile-latency-impacts-publisher-revenue/
https://www.machmetrics.com/speed-blog/how-does-page-load-time-affect-your-site-revenue
https://datadome.co/bot-management-protection/website-performance-how-to-increase-your-business-by-blocking-bots/
[7] https://developers.google.com/web/fundamentals/performance/why-performance-matters
https://www.thinkwithgoogle.com/intl/en-154/insights-inspiration/research-data/need-mobile-speed-how-mobile-latency-impacts-publisher-revenue/
https://www.machmetrics.com/speed-blog/how-does-page-load-time-affect-your-site-revenue
https://datadome.co/bot-management-protection/website-performance-how-to-increase-your-business-by-blocking-bots/
[8] https://drum.lib.umd.edu/handle/1903/1233
https://www.tandfonline.com/doi/abs/10.1080/01449290500196963

 

ObjectBox Go 1.1

ObjectBox Go 1.1

The 1.1 release of ObjectBox for Go is now available, bringing new features such as Box insert() and update() semantics, a new AsyncBox with all write operations (put, insert, update, delete), improved Queries with order and aliases; as well as some fixes and quality of life improvements, such as time. Time support or more forgiving generator code validation. For the full list of changes see the changelog.

To upgrade to the latest version, run go get -u in your project and don’t forget to re-run the generator to make sure all the code is in sync and you get the new features:

Async Box

The new AsyncBox gives you asynchronous processing for write operations such as Put, Insert, Update, Remove, RemoveId.

First a quick reminder how a standard (synchronous) Box works:

Now, let’s have a look at the new AsyncBox. Let’s say tasks are processed in multiple iterations by calling a “WorkOn(*Task)”. Let’s also assume that WorkOn() sets a “finished” flag on the object if it was able to complete a task in an iteration. In that case, the task can be removed from the database. Otherwise, partial progress on the task should be saved for the next iteration.

So, what’s the advantage of using AsyncBox in this example? Because we don’t wait for updating or removing a task, we just created an efficient pipeline: we can spend all computational resources on WorkOn(), while AsyncBox performs persistence in the background. Both steps never have to wait for each other.

The second advantage of AsyncBox is “transaction merging.” Because “WorkOn” takes some time, we operate on a single object at a time. A synchronous solution would require a transaction per object, introducing significant disk overhead. AsyncBox can reduce the amount of transactions required and thus dramatically improve throughput.

You may also have noted the usage of “Update()” instead of the standard “Put”. An update is different from a put as it only persists the object if it already exists in the database. Let’s say our example has another process that removes Tasks; a standard put operation might “resurrect” a task previously removed by the other process. If we don’t want that to happen, we can use update semantics. The new update and insert operations are also available in the standard Box API.

Please let us, and everyone else, know what you like about this release and ObjectBox in general. We’d love to hear from you to know what you’d like to see next.


Looking for an easy way to sync data between devices? Check out ObjectBox Sync, sign up for early access, and look out for the release early 2020!

ObjectBox EdgeX v1.1 – database with ARM32 support

ObjectBox EdgeX v1.1 – database with ARM32 support

With EdgeX Foundry just reaching v1.1, we continue to provide ObjectBox as an embedded high-performance database backend so you can start using ObjectBox EdgeX v1.1 right away. If you need data reliability and high-speed database operations, ObjectBox is for you. Additionally, starting with ObjectBox EdgeX 1.1, you can use it on 32-bit ARM devices.

Combining the speed and size advantages of ObjectBox on the EdgeX platform, we empower companies to analyze more data locally on the machine, enabling new use cases.

With ObjectBox-backed EdgeX we’re bringing the efficiency, performance and small footprint of the ObjectBox database to all EdgeX applications. It is fully compatible, so you can use it as a drop-in replacement: you call against the same REST and Go EdgeX APIs. As simple as that;no need to change any code.

Performance comparison of EdgeX database backends

EdgeX Foundry comes with a choice of two database engines: MongoDB and Redis. ObjectBox EdgeX brings an alternative to Redis and MongoDB to the table.  Because ObjectBox is an embedded database, optimized for high speed and ease of use while also delivering data reliability, it enables a new set of use cases. As we all know, benchmarks are hard to do. This is why all our benchmarks are open source and we invite you to check them out for yourself. To give you a quick impression of how you could benefit from using ObjectBox, let’s have a look at how each compares in basic database operations on “Device Readings”, one of the most performance intensive data points.

Note: The Read and Write operations (all CRUD (Create, Read, Update, Delete) operations are measured in objects / second). The benchmarks test internal EdgeX database layer performance, not the REST APIs throughput.

These benchmarks provide a good perspective why you should consider ObjectBox with EdgeX. Benchmark sources are available publicly in ObjectBox EdgeX github repo.

So, why is ObjectBox EdgeX faster?

First of all, you are probably aware of the phrase “Lies, damned lies, and statistics benchmarks”. Of course, you should look at performance for yourself and consider based on your specific use case needs. That’s why we make our benchmarks available as open source. It is a good starting point.

To make it easier to compare ObjectBox (in addition to our open source benchmarks) here are some of the high-level “unfair advantages” that make ObjectBox fast:

  • Objects: As you can derive from its name, ObjectBox is all about for objects. It’s highly optimized for persisting objects. The EdgeX architecture and Go sources are a great fit here as it puts Go’s objects (structs) in the center of its interface. This means, we can omit costly transformations and this helps with speed.
  • Embedded database: Redis and MongoDB are client/server databases running in separate processes. ObjectBox, however, is running in the same process as EdgeX itself (each EdgeX microservice, to be precise). This has definite efficiency advantages, but it also comes with some restrictions: Whereas you can put Redis/MongoDB in separate Dockers or machines, this option is not available for ObjectBox yet.
  • Transaction merging: ObjectBox can execute individual write operations in a common database transaction. This means, we can reduce the costly transactions for a number of write operations. This is a great way to add on performance, delaying the transaction end by single digit milliseconds.

Get started with ObjectBox EdgeX

The simplest way to get started is to fetch the latest docker-compose.yml and start the containers:

You can check the status of your running services by going to http://localhost:8500/. At this point, you have the REST services running at their respective ports, available to access from your EdgeX applications.

Find more details, instructions for ARM32, and sources in our GitHub repo at  https://github.com/objectbox/edgex-objectbox.

If you’re new to EdgeX, find out all about the open source  IoT Edge Platform here. The EdgeX project is led by the Linux Foundation and supported by many industry players, including Dell, IBM, and Fujitsu.

We love to hear from you 🙏

We’re very interested to hear about the challenges you are facing on the edge and in IoT. As performance experts, we are always embracing a tough challenge. Reach out to us to set up a pilot project.

Is there something you are missing? Please do reach out to us. We want to make ObjectBox the best edge data persistence layer available. We love to receive your feedback.

What next?

Find out more about ObjectBox EdgeX and get started, go directly to GitHub or download the snap on Snapcraft.

Sync.Drone: a drone project based on ObjectBox

Sync.Drone: a drone project based on ObjectBox

This spring, a student group from Augsburg University of Applied Sciences build a drone application based on ObjectBox Database and Sync. This is a guest blog post by Michelle from the sync.drone project group, describing the project from start to finish and sharing the results. 

The goal: Showcasing the ObjectBox database and Synchronization solution with drones

The goal of the project was to synchronize the colors and flight patterns between two drones to coordinate themselves autonomously in formation flight to showcase the ObjectBox solution. In the future, this technology could be used in many drone applications. First, due to ObjectBox’ speed, more data can be processed faster on each drone, saving resources, specifically battery. This allows drones to fly longer. At the same time, going beyond the scope of this initial showcase, the technology could be used to synchronize swarms of drones, making their use more reliable and flexible – and less dependant upon a constant Internet connection. For example, as an artistic installation, or in emergency situations during a large-scale search for missing persons. Drones can also be used in large warehouses to facilitate the organization of different parts, and pass on the position of a particular part.

 In this article, we will explore the process we used to build our self-synchronizing drones, sharing our software and hardware, so you can try it out yourself.

Hardware: Raspberry Pi, 3D printing, and more

In order to build our drones and turn our vision into reality, we had to consider a number of hardware options. It was important that our drone was compatible and programmable with ObjectBox. The drone had to be localizable and airworthy, so that a safe autonomous flight was possible. All parts had to be compatible so we could easily swap parts if something did not meet our requirements.

We built the drone frame from scratch, using 3D printers. The housing was created in the 3D program Autodesk Inventor and the parts were assembled to a drone frame. We used NeoPixel RGB LED sticks to make the drone glow in color. We chose the following components. 

Microcomputer

A Raspberry Pi was the most suitable central computer on our drone. It offered both performance and size. We chose the Raspberry Pi 3 B+, which would later control the processes of our drone independently.

Tracking system 

After looking at different tracking systems, we chose the “POZYX” UWB tracking system. This ensured an accurate and user-friendly handling.

Accumulator

We had to make sure that the drone’s battery would last long enough to power a Raspberry Pi, LEDs and a POZYX tag in addition to the flight hardware. First started with a 6 cell LiPo battery with 5000mAh. However, later in the project, we replaced the battery with a lighter and more compact 6-cell LiPo battery with 1800mAh.

Engines

The engines (1750 kV) from the Drone-Racing sector had enough power to make the drone fly. Motors with even lower kV would have given the drone more power, but are much more expensive.

Flight controller 

As flight controller we chose the “Omnibus F4 V6” chip, which ran with the open source software “Beta Flight” and was accessible via the so-called Multiwii Serial Protocol (MSP). This allowed us to use the advantages of a proven flight software, and also transfer the flight instructions via USB directly to the flight controller using the MSP.

Electronic Speed Controller (ESC) 

For the ESC , which implements the instructions of the flight controller by direct voltage changes at the motors, we chose a 4-in-1 model. With only one connection cable to the flight controller, all four motors can be controlled at the same time. Usually one ESC is required per motor. It was also compatible with our hardware.

Software – Tracking, Flying and Syncing the Drones

Except for a start signal, the drone was supposed to operate without a remote control. Several drones would coordinate themselves at the same time according to the instructions. We decided to develop the code in three separate “cores”, which were merged at the end of the project. These were divided into “tracking”, “flying” and “syncing”. Using the university git lab as a repository, we were able to simplify development and share the code with the group. This allowed structured work on the code. With the help of ObjectBox and Prof. Dr. -Ing. Alexandra Teynor we were able to assemble the following code parts.

Tracking 

For collision avoidance it was important to implement tracking, so that the drone knows it’s own position. We solved this by using the position calculated by the POZYX tag, which was then transmitted to the Raspberry Pi in the tracking core.  We read the coordinates from the IMU sensors (“inertial measurement unit” = unit of measurement based on multiple sensors ) from the POZYX tag, but not the exact positioning.

The so called “heading”, or yaw of the drone, is read out by a magnetometer. However, this internal “compass” reacts to disruptive factors and can deliver inaccurate results. We solved the correction of the heading via an algorithm using OpenCV. This algorithm uses a small camera module on the drone and special markings on the ground to detect its orientation. This allows the direction vectors of the drones to be calculated more accurately.

Flying

In the flying core, the flight instructions were developed based on the tracking core data, and then implemented by passing this data on to the flight controller. First of all the drones have to be lifted off the ground. For this purpose we used a laptop keyboard control, which forwarded flight instructions to the drone via a web socket.

Flight control

The Raspberry Pi establishes a serial connection to the flight controller via USB. As soon as this connection is established, flight instructions are transmitted in the form of inclination values for roll, pitch, yaw and throttle (thrust). These values may lie between 1000 and 2000. In a neutral position, roll, pitch and yaw are at an average value of 1500.  

Using Python, we calculated the required roll, pitch, yaw and throttle values and assembled them using the Multiwii Serial Protocol. This was translated into pure byte code and sent to the flight controller via the USB cable. The flight controller now tries to reach the corresponding values. In order to turn to the right, the left motors are turned slightly up and the right motors slightly down. The ESC received the commands for the desired motor speed from the flight controller. It then applied the required voltage to each motor according to its instructions. The communication between the flight controller and ESC happened either by an analog (PWM) signal or a digital signal (D-Shot).

Keyboard control 

The computer runs a Python script that registers keystrokes and converts them into instructions. For example, pressing the right arrow key creates the command “raise-roll” and pressing the left arrow key triggers the command “lower-roll”.

The drone also runs a Python script that opens a web socket to which the PC script connects. Each time a key is pressed on the laptop, a corresponding command string is generated (e.g. “raise-yaw”) and sent to the drone via the web socket. As soon as a string arrives, the relevant value (roll, pitch, yaw, throttle) is increased or decreased.

To prevent the drone from crashing if a connection is lost, the values are flattened algorithmically.

ObjectBox Database and Sync Drone Implementation  

In the syncing core, the position data of all drones as well as the LED color, should be exchanged and commands passed on. The RGB color space of the LEDs was mapped to the x-, y- and z-position. In this way, the sync features of the drones could be displayed without them flying. For the implementation we used the ObjectBox database and the ObjectBox Sync Server.

Originally, we had planned to use the ObjectBox Go Binding because it is precompileable and very fast. However, the POZYX system we choose used Python. There was also already a Python implementation available for our flight controller, but none available for Go. Luckily, ObjectBox offered to develop and provide a small Python binding of their database according to our needs. This included all ObjectBox functions that were relevant to us. It was officially released in version 0.1.0 specifically for our project. As a result, the ObjectBox database could be easily integrated into our code.

Realization of syncing

In Python version 0.1.0, ObjectBox incorporated the basic features we needed. For our application the simple CRUD functions and the Sync feature, which synchronizes the data in near real time, were sufficient. The database is compact and the speed and ease of use is optimized for restricted IoT devices, for example the Raspberry Pi used in this project.

The sync server is started by running the init-server.py script on the master drone. At first, an empty database (model) was initialized. The master drone then communicates with the other drones via WLAN network connection and synchronizes the ObjectBox database between the respective devices.

Three entities (classes) are stored:
– the identification and position data of the anchors
– the identification and position data of the tags
– the color values of the LEDs.

The drone stored it’s position and LED color in the database. The master drone then reads out this information and overwrites it  with the values calculated by the master drone (e.g. LED color or target position in the future).

Thank you!

At the end of our project, we had three drones. Depending on the position of the master drone, all drones could synchronize their LED colors. Unfortunately we were not able to finish the flight due to a defect in the flight controller and a delayed delivery of parts. Finally we decided to publish the code for the drone control on GitHub. Additionally, you can get inspired on our website as well as on our social media platforms. 

Furthermore, we would be happy, if the project would be continued by another group of students in the future. With our work we have created a basis for many more ideas. In summary, our project still has a lot of ambitious potential for the future.

Thanks to ObjectBox for this great opportunity – we mastered many problems along the way and learned a lot. Thanks for the constant support.We also thank our professors Prof. Dr. -Ing. Alexandra Teynor, Prof. KP Ludwig John and our coach Sandra Hobelsberger for their professional advice and patience. Finally, we would like to thank HSA_Innolab for their additional financial support and FabLab for their advice and resources.

In collaboration with interactive media students of the University of Applied Sciences in Augsburg.

 

The best IoT Databases for the Edge – an overview and compact guide

The best IoT Databases for the Edge – an overview and compact guide

For many IoT projects, relying on the cloud for data storage and analysis is inefficient has many limitations, including:

  • Dependence on an Internet Connection: Cloud-based solutions only work when an active Internet connection is available. However, many IoT applications need to function offline, e.g. autonomous driving.
  • Lack of Speed: The time delay between an action and its response is significant in a cloud application due to the round-trip the data needs to take. A near real-time response is, however, critical for many IoT use cases.[1]
  • Data Security / Privacy / Data ownership: There are added risks (data breaches and/or tampering) when transferring data through the network as opposed to keeping/using data directly at the source of its creation.
  • Broadband Limitations: The growth of data volumes and IoT devices exceeds the speed by which broadband infrastructure can be extended. This puts a hard limit on the growth of applications depending on the cloud.[2]
  • High Cloud Costs: The more data is sent to the cloud and stored in the cloud, the more the cloud costs. Many companies find costs for cloud applications are higher than expected.[3]

For IoT projects that cannot work soley cloud-based due to e.g. hardware or network/bandwidth limitations or a need for realtime response rates, Edge Computing is an scalable and sustaiable solution. In order to bring computing closer to the source of the data, you need an IoT database optimized for the edge

What to look for in an IoT Database for the Edge

There are several factors to consider when choosing an IoT database for the edge. The five most important criteria to take into account are the edge-capability, performance, ACID-support, language support and data type support.

Edge-capability

Of course, in order to qualify as edge-capable, the database needs to run directly on a broad spectrum of edge devices – either embedded or in-memory. Many IoT devices are physically small and have limited resources, so a database for the edge needs to have a small footprint. For that reason, the list below does not include databases with a core library larger than 10MB.

Performance

Many edge cases have a need for speed; for example: In additive manufacturing making necessary adjustments to the next layer added to an asset needs to happen in near real-time. Because this decision is based on a multitude of environmental factors from the factory floor, tons of data from sensors need to be processed extremely quickly.

ACID-compliance

Depending on whether you can afford to lose some of your data sometimes, you need to check if the database is fully ACID compliant – and under which conditions any benchmarks have been run. What does ACID mean? In the database world, this popular acronym refers to how data in transactions is handled by a database and stands for: Atomicity, Consistency, Isolation, Durability. In short, a fully ACID-compliant database is transactionally safe and ensures that, despite errors, power failures etc., no data is lost and the transactions are always executed in a valid way.

Language support

Another important criteria obviously is the language used to implement the database: Does it match your project’s language and developer skills? Generally speaking it is more efficient to keep to one language; this is also why many developers love to avoid dealing with SQL.

Data Type support

Finally, you need to decide on the overall structure data shall be stored in. In this article, we will only focus on full databases that enable complex computing on small devices – thus it only includes traditional databases, i.e. those that are relational, object-oriented or graph-based. Databases that are limited to time-series data only (e.g. InfluxDB, TimescaleDB) or any ORMs will not be discussed here.

IoT Databases for the Edge

In order to help you in choosing the best IoT database for your next project swiftly, we had a look around and compared available databases. Here is a list of IoT databases for use on the edge:

Badger calls itself a distributed, fast graph database. It is an ACID-compliant, NoSQL, LSM tree-based key-value store written fully in and available only for Go. As Badger does not focus on being run on IoT devices, it supports easy horizontal scaling, synchronous replication to prevent data loss, load balancing and using the full capacity of SSDs instead of the RAM. Central or P2P synchronization are not available.

Berkeley DB is an ACID compliant embedded key-value store. Due to a static library size of less than 1 MB, and runtime dynamic memory requirements of only a few KB, it is suitable for a variety of edge devices. The database is usable in many different languages, such as C++, C#, Java, Perl, PHP, Python, Ruby, Smalltalk and Tcl. Berkeley DB does not offer any synchronization support.

LevelDB is a key-value storage library that provides an ordered mapping from string keys to string values. It is written in C++ and has bindings for languages such as C, Go, NodeJS and Java. LevelDB runs on-disk and is queried without SQL. Applications need to use it as a library, as the database does not provide any server or command line interface. Indexes and synchronization are not supported.

ObjectBox is a fast, object-oriented, ACID-compliant database with strong relation support. It was designed specifically for Edge IoT and embedded and mobile applications. ObjectBox has a memory footprint of less than 1 MB. Language support includes C, Go, Java, Kotlin, Swift, Python (Beta), and Dart. Centralized synchronization support is currently in an alpha stage and distributed / P2P synchronization is a work in progress.

Realm, which has been acquired by MongoDB in summer 2019, is an ACID-compliant NoSQL database. It has been strongly focused on mobile platforms from its start and is only beginning to move into IoT. It offers central as well as P2P synchronization. Supported languages include Java, Kotlin, Swift, C# and NodeJS.

Redis is a key-value database, which is per default not ACID-compliant. However, it offers an optional durability transaction concept, which when turned on reduces the database performance significantly. In contrast to other database systems, it works in memory with user commands not being data queries, but specific operations to be performed on abstract data types. Redis has many different client bindings, e.g. C, C++, Dart, Go, Java, NodeJS, Python and Rust.

RocksDB is a persistent key-value store for SSD and RAM storage. It is not ACID-compliant, but works using concurrent transactions with conflict resolution. This embedded NoSQL database supports Java, Python, NodeJS, Go, PHP and Rust, to name only a few languages. Synchronization in any form is not natively possible with RocksDB.

SQLite is the only fully SQL-based relational database library in this list. SQLite comes with a small footprint and is fully ACID-compliant. It offers encryption as a paid service. There is no support for synchronization.

Let us know your thoughts!

Different use cases call for different databases, and we hope that this list gives you a good starting point for your edge computing project. Let us know your thoughts in the comments below – what is your favorite database work with with and why?

[1] https://www.networkworld.com/article/3224893/what-is-edge-computing-and-how-it-s-changing-the-network.html
[2] https://www.bloorresearch.com/technology/5g-iot-and-edge-computing/
[3] https://www.networkworld.com/article/3224893/what-is-edge-computing-and-how-it-s-changing-the-network.html

Car Tolling – A case for Edge Computing

Car Tolling – A case for Edge Computing

Governments often face tight budgets on infrastructure development; car tolling is increasingly seen as the answer for raising funds¹, making it more and more prevalent. From 2008 to 2018 the total length of tolled roads in Europe increased by 23%² and tolling revenue in Europe increased by 37%³ to €31.3 bn. per year; similarly, from 2010 to 2015 the United States experienced a 63% increase in transponders and 52% more tolling revenue, resulting in $13.8 bn. in 2015. On top, despite car sharing efforts, car ownership and traffic is still increasing in many countries, e.g. Germany, France and India. Increasing amounts of traffic, devices, and data points bring current tolling solutions to their limits. Taking data to the edge in new and existing tolling solutions, for example with the ObjectBox data storage and synchronization solution, can make tolling more efficient and reliable.

Setting the stage: a typical car tolling situation

A national infrastructure company has deployed several hundred car tolling stations all over the country. These stations automatically recognize passing cars by detecting licence plates, using visual recognition or wirelessly, e.g. by receiving data from an RFID transponder in the car. In order to ensure that only eligible cars are passing through the tolling station and violators are fined, it is necessary for the tolling station software to look up the gathered vehicle information – among millions of entries – as fast as possible. If the data look-up is not  fast enough, or the data on the roadsides/tolling stations isn’t up to date and in sync with the central data, the tolling station loses money.

“The importance of mobile apps is increasing for Kapsch TrafficCom so that we see ObjectBox’ edge computing database solution as an interesting future base technology for all types of mobility apps.”

Peter Ummenhofer

Executive VP Solution Management, Kapsch TrafficCom

Why edge computing and fast lookup is key to today’s car tolling systems

In general, modern nationwide tolling infrastructure consists of three systems: tolling stations operated by the respective agencies, central open road, also called mobile tolling, and central transaction clearing houses. Within this infrastructure, all data related to violators and other operational information needs to be synchronized between these three systems in a consistent way, with as little delay as possible. If this is not the case, together with other problems, car tolling system operators are faced with high monetary losses every day.

Today’s car tolling systems are based on the fundamental idea that cars do not need to stop to be checked or charged. Thus, as the cars move quickly through the scanning area, the challenge of implementing a car tolling system directly relates to the amount of data that needs to be searched within a very short time frame.  To be successful, this process needs to happen in near real-time. From a development perspective, these problems are rooted in:

  • accessing data from a remote location (speed of communication, speed of network)
  • keeping data in synchronization with car tolling stations that are closer to the drivers and/or roadside units
  • database speed on remote servers
  • database speed on roadside units (car tolling edge devices)
  • limitations of existing hardware as some systems are quite old, and rolling out new hardware is expensive

Furthermore, it is possible that stations shut down from time to time, due to the weather, power outages, vandalism or simply technical failures. However, tolling providers generally need to provide strict uptime guarantees and thus service level agreements often include penalty fees in case of excessive downtime. Such events cost the providers substantial amounts of money – and data loss, i.e. undetected violators, even more so.

Adding to this, privacy and legal requirements differ from country to country and increase the complexity of the systems and timings. For example, in Austria the pictures and derived license plate information may only be used for checking, but in case no violation was detected, they need to be removed in an unrecoverable manner¹⁰. On the other hand, the data of potential violators may be stored for the sole purpose of toll collection or prosecution, but only for a maximum of three years.

How fast data storage and syncing can help in car tolling

To solve these problems, a data storage and data synchronization solution like ObjectBox can be deployed on every type of tolling station, i.e. open and static stations, as well as on the central server. From a technical point of view, this is not a problem, because the ObjectBox library supports virtually all platforms and operating systems. Financially, it is considerably cheaper to update software, than it is to upgrade hardware.

Having the library installed, with ObjectBox Sync, it is guaranteed that the vehicle data in the internal stations’ memory is always up-to-date with the central server, so the station will make a decision based on the most accurate data every time. Additionally, the other systems involved in the tolling infrastructure consistently receive the most recent information with no further effort required.

Deploying the synchronization solution also means, because ObjectBox is particularly reliable (ACID compliant) and well-tested, that station shutdowns or internet connection issues are not a problem anymore. The stations’ operating company will no longer lose violator’s information due to technical reasons.

Summary – Car tolling is moving to the edge

As this case study shows, the use of edge computing is a perfect fit for modern infrastructure. In the context of car tolling, speed, reliable data storage and synchronization are indispensable, resulting in ObjectBox being an effective solution for today’s and future technological advancements.

If you are interested in learning more, feel free to get in touch with us! We appreciate any kind of feedback.