Follow Datanami:
April 26, 2012

Financial Industry Against the In-Memory Wall

Datanami Staff

The financial services industry is doubtlessly data-laden due to everything from general trading volume for options, which grew to 4.55 billion contracts last year (up almost 17 percent from the year before) and over 10,000 credit card transactions each second.

For banks, it’s getting easier to stream in user data with an expected 66 million American households using online banking within the next two years, among a host of other changes that is making financial data even bigger.

Out of this need, new platforms and capabilities around in-memory computing models are emerging, but still don’t offer the magic bullet to such real-time data woes, some argue.

As Azul Systems’ Scott Sellers says, there is no end in sight to the data growth of the financial sector. Accordingly, the race is on to deliver the solutions capable of floating this new wave of big financial data.

There are already a number of compelling use cases for this industry finding ways to manage and leverage big data, including:

  • Banks and personal-finance websites collect and analyze customer data in order to deliver personalized products and services, leading to higher customer satisfaction and retention.
  • Analytics are now being used to improve the recovery of bad debt, taking into account specific customer circumstances, improve recovery rates and also reduce recovery costs.
  • Payment platforms and firms are using big data capabilities to better detect fraudulent activity, moving away from traditional sampling techniques to being able to process all transactions and thereby more accurately assessing risk.
  • Enterprises are using big data to see how their IT systems are performing and behaving, analyzing and indexing the data generated by all the IT infrastructure, allowing improved uptimes and overall operational efficiencies.

For many financial services firms, the grid computing model is still part of the IT backbone, which works for scale, but isn’t always the most effective model for real-time action on big data. The new key to performance is increasingly found in in-memory computing models—new ways of computing that Sellers says can make or break a financial services firm competitively.

He claims that while in-memory is finding a fast home in finance, there are some kinks to work out. As he wrote this week:

“The use of in-memory computing does have its share of challenges. In the financial world, many key applications, from trading platforms to financial services websites, are built using the Java language and therefore use a Java Virtual Machines (JVM) to run.  Traditional JVMs, however, were not designed to scale to the memory sizes required for real-time Big Data analytics.  Above a certain memory size, e.g. 5 GBytes, applications running on traditional JVMs will pause or have performance “hiccups” caused by Java’s garbage collection process. 

Garbage collection happens inside the JVM and is responsible for collecting memory from ‘dead’ objects that the program is no longer using.  It happens at unpredictable intervals and stops the Java program from executing until it is completes.  The “stop-the-world” garbage collection pauses are often considered the Achilles Heel of Java because of the poor response or query times that may result.  In-memory computing may be the right approach in order to perform real-time big data analysis, but only if this garbage collection problem can be solved.”

Sellers says that programmers can ease the performance blow of such pauses by keeping memory small, but really, if you’re leveraging in-memory models at all, this pretty much goes against everything you’re trying to do. However, commodity servers can now be purchased with a terabyte of local memory (and this amount continues to double every 18 months), and so he says that instead of limiting memory size, financial firms can simple choose to architect their big data systems to use a lot of memory and perform consistently.

On that note, he says, “Pauseless execution, in which the JVM collects garbage all the time, is the antidote for these nasty stop-the-world pauses. A pauseless-execution JVM enables elastic use of memory, scaling easily and performing flawlessly regardless of the amount of memory being used. A pauseless-execution JVM used with in-memory computing can utilize hundreds of gigabytes (and beyond) of the Java heap, without the threat of freezing, and therefore is a key enabler to realize the goal of real-time big data analysis.”

On that note, Azul Systems with its Zing platform, makes the argument that conventional Java Virtual Machines (JVMs) can’t meet the demands of today’s financial applications for performance, consistent response times and handling very large data sets. The company says will always be limited in the amount of heap memory they can use without intermittent and asynchronous garbage collection (GC) pauses – and can’t grow and shrink elastically to handle changing workloads. As a result, conventional JVMs can limit the scalability

Sellers argues that as grids fall by the wayside in favor of real-time capabilities, companies are poised for a new playing field, but only if their underlying system platforms are architected appropriately.

Related Stories

SAP Accounts for Sybase, HANA Futures

The Big Data Slice and Dice

Interview: SAP Solidifies Predictive Strategy

Datanami