Taking Analytics to the Edge: Moving Processing to the Data Rather than Data to the Processing

August 22, 2019 | 5 minute read
Text Size 100%:

By Marc Staimer

Ground-breaking changes are happening on the edge of computing. We’re long past the days when all analytics can be centralized in datacenters or even in the cloud. It’s an increasingly decentralized world where analytics has to take place in real time right where individual sensors are, or in the fog when there’s a need to collect information from multiple devices for fast insights.

We recently sat down to talk with renowned technology consultant Marc Staimer about computing in the edge, the fog, and the core. In part two of our conversation, we’re going to take a more in-depth look at matching the analytics requirements to the location of the analysis, especially when those analytics need to take place on the edge or in the fog.

Aggregating Data for Deeper Insights

As we noted in part one, edge computing came about as a response to applications moving into the public cloud where the centralized processing can lead to unacceptable latency.

If dealing with a single device and need minimal analytics, edge computing can handle it. Sensors on consumer appliances are an example where edge computing makes sense. When actionable data from multiple data devices is needed, it can take place closer to the edge with much lower latencies than going back to the core or cloud. This is fog computing. Fog computing devices are distributed near the edge and aggregate, analyze, sub-filter, and make decisions for multiple edge devices that have policy engines or AI/machine learning. Edge and fog computing can solve the intransigent distance latency, but they cannot resolve the performance of the analytics engines themselves.

When that actionable information is needed fast, Oracle Exadata and the Oracle Database Appliance (ODA) are ideally suited to handle this fog computing, according to Staimer. With built-in AI/machine learning, they can be placed close to the edge.

Staimer cites an example of a highly automated robotic automobile factory. It’s operating 7/24/365 and can’t bring its servers down for any reason. It has clustered servers so that it can update, patch, or upgrade each of the clustered servers on a rolling basis without disrupting the workflow. And typically there are different car models or variations in that same factory, as well as other highly automated robotic automobile factories making other cars or lines.

“What if all those factories and robots were able to learn from each other utilizing AI machine learning? What if data from each factory floor was being collected, aggregated, and analyzed in real time? What problems could be avoided? What efficiencies could be gained? What quality could be improved? In reality, quite a bit,” says Staimer.

This smart factory is a perfect play for edge, fog, and core because the factories already have edge computing going on. Now they can aggregate data from all their factories to optimize production across all factories.

ODA and Oracle Exadata Address the Continuum of Analytics Requirements

Why are Exadata and ODA well suited to help deal with the analytics problem? Explains Staimer, both are co-engineered with the database: “That co-engineering delivers the lowest possible OLTP latencies, and the fastest performance for every transaction versus any other database system.”

The second, and potentially more important, aspect is that these systems are multiple databases in one, tied to a single database engine and copy of the data. If the data needs to be analyzed by different types of databases, such as OLTP, Data Warehouse mining, time series, key value (JSON), XML, graphical, object, etc., it can be. Each database is a pluggable database (PDB) that rides on Oracle’s unique multi-tenant Container Database (CDB). The data is organized virtually by each unique database without impacting or affecting the others. That's huge because it enables multiple database consolidation, eliminates excessive database licensing, duplicate database hardware infrastructure, complicated data protection and DR, duplicate data, storage islands, and, best of all, the data doesn’t have to be moved via ETLs between databases.

The Rise of Edge Computing Around Microservices Requires a Better Solution

This aggregation of multiple databases tied to a single engine and single copy of data solves a difficult problem for edge computing around microservices.

Microservices are small applications with their own database that are pushed out to the edge or fog. The problem is that each microservice is self-contained with no access to the data or database on another device. If the microservice needs a data element from another microservice, that requires a reworking of the microservice and likely an extract transfer and load from one database to the other. All of this is a labor-intensive manual process and takes time, meaning the data becomes stale. It definitely does not occur in any sort of real time. Or, the data must be duplicated to all of the microservices that might require it. Whenever data has to be copied and moved, there is an increased risk of data corruption and loss. No one enjoys moving data. Besides taking time, it leads to rapidly escalating and out-of-control storage, networking, and even compute infrastructure costs. It might be manageable for a handful of microservices but not when there are hundreds to thousands of them as is typical with microservice sprawl with IoT.

Oracle’s pluggable databases (PDBs) eliminate that problem. As many as 4,000 microservices can be consolidated into PDBs with a single copy of the data. “That’s a very big thing,” emphasizes Staimer. You’re not only saving time, you’re also eliminating manual processes that increase the risk of errors entering in.

The combination of Oracle’s engineered systems that can live on-premises, in the cloud, in the fog, or on the edge, along with PDBs that streamline the processing make for solutions ideally suited to this new world of computing anywhere and everywhere.

To learn more about Oracle Database Appliance and Oracle Exadata Machine, visit us online.

About Dragon Slayer Consulting: Marc Staimer, as President and CDS of the 21-year-old Dragon Slayer Consulting in Beaverton, OR, is well known for his in-depth and keen understanding of user problems, especially with storage, networking, applications, cloud services, data protection, and virtualization. Marc has published thousands of technology articles and tips from the user perspective for internationally renowned online trades including many of TechTarget’s Searchxxx.com websites and Network Computing and GigaOM.  Marc has additionally delivered hundreds of white papers, webinars, and seminars to many well-known industry giants such as: Brocade, Cisco, DELL, EMC, Emulex (Avago), HDS, HPE, LSI (Avago), Mellanox, NEC, NetApp, Oracle, QLogic, SanDisk, and Western Digital.  He has additionally provided similar services to smaller, less well-known vendors/startups including: Asigra, Cloudtenna, Clustrix, Condusiv, DH2i, Diablo, FalconStor, Gridstore, ioFABRIC, Nexenta, Neuxpower, NetEx, NoviFlow, Pavilion Data, Permabit, Qumulo, SBDS, StorONE, Tegile, and many more.  His speaking engagements are always well attended, often standing room only, because of the pragmatic, immediately useful information provided. Marc can be reached at marcstaimer@me.com, (503)-312-2167, in Beaverton OR, 97007.

 

 

 

 

Guest Author


Previous Post

Computing in the Cloud, in the Fog, and on the Edge

Guest Author | 5 min read

Next Post


Latest Tech Trends, Their Problems, And How to Solve Them

Steve Zivanic | 8 min read
Oracle Chatbot
Disconnected