Coherence Part IV: Merging Data And Processing

Most people who have been in contact with Oracle Coherence have had that fantastic penny-dropping moment where the see the potential of merging data and processing.  They see to possibilities arising from a distributed computing framework that doesn’t need to ship around large data fragments like a compute grid would.  The data is already there. Now this concept may not seem that new. What are stored procedures after all? Well the difference is that whilst traditional databases are limited to a single physical machine Shared Nothing Architectures like Coherence can have hundreds of processes facilitating communication and data storage.

There are a couple of points worthy of note before we go on:

• The process of Merging Data and Processing is not seamless. The details of this are covered in another post (ref). This article is meant solely as an introduction.
• There are in fact databases with exactly the same benefits, with respect to merging data and processing. They are the ones like Terradata, Greenplumb and Vertica that also use a Shared Nothing Architecture.

Data Affinity: Ensuring Collocation of Disparate Data Sets

Data affinity allows associations to be set up between data in different caches so that the associated data objects in the two different caches are collocated on the same machine. In the example here trade data and market data are linked via the ticker meaning that all trades for ticker ATT will be stored on the same machine as the ATT market data.

Using Coherence to Run Processing in the Grid

Thus when an Entry Processor or Aggregator executes, say to run a trade pricing routine, it can access the trade and its market data without having to make a wire call as the market data for that particular trade will be held on the same machine (whenever possible).

This presents the possibility of folding the classic service-centric approach in two[1]. Suddenly compute architectures can be merged into one layer that has responsibility for compute and data.  The fundamental advantage being that far less data needs to be transmitted across the wire.

Increased Wire Efficiency

In a standard architecture (the upper example) data is retrieved from a data source and sent to the application tier for processing. However in the Coherence Application-Centric approach (the lower example) the code is sent to the machine that holds the data for execution. This is one of the real penny-dropping concepts that can revolutionise a systems performance.

But it is important to note that Coherence is not a direct substitute for a compute grid such as DataSynapse. Application-Centric Coherence involves leveraging in the inherent distribution Coherence provides as well as its inherent collocation of processing and data.

Thus looking at the anatomy of a simple Application-Centric deployment we see:

• A feed server enters a trade into the Trade cache using an Entry Processor to execute some pre-processing.
• This in turn fires a CacheStore which reliably executes some domain processing for that trade on the same machine.
• The domain processing results in the trade being updated in the cache.

One of the key benefits of this architecture is the inherent distribution of processing. As various feeds come in for various trades, the domain processing for each one is executed on the machine on which that trade data is held. This means that not only is the execution collocated with the data but the executions are implicitly load balanced across the Coherence cluster.

So Coherence has evolved from being a data repository to an application container which provides:

• Free distribution of processing across multiple machines
• Free fault tolerance
• Free scalability to potentially thousands of machines
• The ability to collocate data and processing.

This is an enticing proposition for any new application!!!

[1] Service-Centric and Application-Centric are terms coined by Lewis Foti to describe the two broad architectural styles used to build Coherence based systems. Service-Centric architectures use Coherence simply as a data repository. Application-Centric users use Coherence as a framework for building event based distributed systems. Such systems leverage the inherent distribution and fault tolerance that comes with the product with operations being generally collocated with the data they require. This merges the Application and Data layers of the system.