It allows, for instance, to use Ehcache in a clustered mode, and benefit of a distributed in-memory cache.

It is available as open source, and you may want to contribute to it, or even just build it yourself (You can also get binaries on the Terracotta web site).

If you want to contribute to the OSS Terracotta server, here are a few pointers to get you started.

To read the full post from Aurelien Broszniowski, please click here

Ehcache has a tier model where it uses different types of storage (heap, offheap, disk, clustered). Ehcache will smartly move copies of ‘hot’ data into the different tiers as needed to provide the best performance for the “hottest” data.

What is Ehcache Offheap?

Offheap is a term for Terracotta’s caching tier which stores Java objects in memory that is not managed by the Java garbage collector (GC). To understand why this is useful and important, we need to have a short discussion about Java and memory.

Managed Memory

Java is a managed memory language, like Python, Ruby, etc. Java keeps tabs on objects which are created and used in the course of program execution. Eventually, some objects become unreferenced and those objects can be destroyed, freeing up memory for other tasks. This is done automatically through the JVM, without the developer having to worry about it. Magic! But that magic does come at a price. The JVM spends considerable time keeping track of these objects and their usage, and that overhead can slow a program down, especially if you are dealing with large amounts of data. If the JVM falls too far behind, it will initiate a full GC, which can lead to a pause of the entire program for several seconds. This problem can start showing itself with relatively small heaps, around 1 gigabyte or so, and becomes exasperated with larger data sizes. So if you want to have many gigabytes of data in a cache, normal Java “on heap” memory will not work well.

Unmanaged Memory

Java also has provisions for allocating chunks of raw unmanaged memory, which many refer to as Offheap memory. Offheap memory must be allocated by the programer and freed by the garbage collector. The advantage of Offheap is that you allocate large chunks of such memory and use it piecemeal; the GC sees each Offheap buffer as one monolithic object, making it easier to manage.

If you can allocate a 20 gigabyte of Offheap buffer and fill it with several thousand smaller objects, you can relieve the GC from having to worry about them – allowing you to manipulate large amounts of data. Win-win!

Ehcache with Offheap storage is a caching tier implementation that stores Java objects in Offheap memory space. This allows for a single cache to store very large amounts of data indeed – think hundreds of gigabytes, even multiple terabytes in a single JVM.

No special coding needs be learned,

No new API needs to be mastered.

You enable it in your Ehcache config, specify a maximum size, and use your cache like always. Just faster and bigger.

Configuring It

Normal Ehcache heap configuration is done via the ehcache.xml configuration. There are two cache level directives that are relevant for configuring Offheap use, although most are only interested in maxBytesLocalOffheap.

From the docs in ehcache.xml:

maxBytesLocalOffheap:

Sets the amount of off-heap memory this cache can use, and will reserve.

This setting will set overflowToOffheap to true. This allows us to enable Offheap

Note that it is recommended to set maxEntriesLocalHeap to at least 100 elements when using an off-heap store, otherwise performance will be seriously degraded, and a warning will be logged.(This is the minimum advised size for heap to be used in conjunction with offheap)

The minimum amount of offheap that can be allocated is 128MB. There is no maximum.

In your <cache>... </cache> stanza in your ehcache.xml, add <maxBytesLocalOffheap=”4g”> to reserve and use 4 gigabytes of offheap memory.

The overflowToOffheap setting is set to true automatically when you set maxBytesLocalOffheap, so you can safely ignore this one.

A sample entry for a cache to use 4 gigabytes of offheap looks like this:

<cache name="offheapCache"
    maxEntriesLocalHeap="100000"
    eternal="false"
    timeToLiveSeconds="600"
    maxBytesLocalOffHeap="4g"/>

That’s almost it — there is one thing left to do. You have to tell the JVM that you need 4 gigabytes of offheap memory available. To do this you have to pass the JVM a special switch. This switch might vary if you are on non-standard Java implementations, but most people will use the standard JVMs, so the configuration is simple. Simply pass the -XX:MaxDirectMemorySize flag to the JVM on startup with a sufficient amount of memory. For our 4G cache above, we might pass in:

-XX:MaxDirectmemorySize=4200M

to allow a little breathing room.

That’s it — you now can use your cache to store hundreds of millions or even billions of entries, at in-memory speed, with no change to your code. You just use Ehcache exactly as is. Snap offheap in, scale Ehcache out.

What to Expect

Offheap memory access is generally very slightly slower than heap object access due to serialization, but it is orders of magnitude faster than disk or network accesses. Additionally, in the Ehcache architecture Offheap is one tier in the cache — you also configure a heap cache tier in front of the offheap to hold frequently accessed objects.

Remember, caching is what Ehcache does best, so this tiered model is as you might expect, super efficient.

When using a tiered Ehcache with offheap, you can expect extremely fast access to your data, even with hundreds of millions of entries in a cache. Furthermore, the access will be extremely predictable — no big spikes in access latency.

Battle Tested

Using the newly open-sourced Offheap for Ehcache has some big advantages beyond the technical ones we’ve discussed. For example, literally trillions of cache put() and get() operations have been run through the Ehcache Offheap implementation by commercial customers. Customers with money and time on the line who expect that Ehcache with offheap will deliver predictable, fast, low-overhead results.

With so many large commercial installations in active use, you can imagine that the Offheap code is very well tested for its intended purpose, and is highly optimized for use in Ehcache.

• Terracotta Server 4.3 OSS release for distributed caching, with offheap storage

• New Ehcache 3 milestone release, including offheap storage and JSR107 (as previously announced last week)

The new Terracotta Server 4.3 open source offering now includes offheap storage with existing Terracotta Server project for distributed In-Memory Data Management.  Among other features, it also enables fault-tolerant distributed caching capabilities to Ehcache.

You can access all open source projects at the usual place: http://terracotta.org/downloads/open-source/catalog

You can download the source code for Terracotta Server 4.x open source kit from SVN and learn how to build the kit or become a contributor: http://terracotta.org/community/source

Find other ways to engage our community (via forums and issue tracking) here:  http://terracotta.org/community

We hope you enjoy the addition of offheap capabilities within our open source offerings!  Look for us at upcoming tech events – our team will be happy to meet and hear from you.

Feel free to reach us and provide feedback at tc-oss@softwareag.com

Take a look at the Ehcache 3 project page and jump in to check out the getting started guide. We’ll be pleased to have you participate in and take advantage of our large & growing open source community.

We hope you enjoy the addition of off-heap capability to Ehcache3!

Feel free to reach us and provide feedback at tc-oss@softwareag.com

In December we released the first alpha of the new development line of Ehcache. The target of the alpha release was to provide a JSR-107, the javax.cache API for java, compliant implementation of using the new API and features as we plan to have them for v3 of Ehcache.

On-heap caching using the JSR-107 API

We’ve released a heap-only CachingProvider for JSR-107 and will start making the other topologies available with the beta releases early 2015… While the alpha comes with a new API into Ehcache, its main purpose is to enable people to make use of javax.cache APIs. These are obviously frozen, while the Ehcache v3 APIs are still somewhat in flux…

Presenting recently on the subject, someone asked:

Well and indeed, no, it’s not practical to define a cache without capacity constraint (it’s just a Map otherwise, right?), but yes, the JSR-107 specification provides no way of configuring a capacity constraint on a Cache (or CacheManager).

Where cache aliased “bar” extends cache-template “example”, so that it gets its capacity, value-type and key-type… but the key-type is explicitly overwritten.

How’s that useful to my JSR-107 application?

Well, we’ve added a small feature to our JSR-107 CachingProvider that let’s you define programmatically configured caches (at runtime) should use a cache-template. This is all explained in this other read me. But again, in a nutshell:

1. I have this application that creates a javax.cache.CacheManager programmatically, using either some specific URI to configure it, or the default’s URI (see your provider’s documentation);
2. At runtime, the app creates a cache named “users”, either using plain javax.cache APIs or some vendor specific configuration object. Either it doesn’t provide any capacity limit, or does it in a vendor specific way that Ehcache wouldn’t understand;
3. When using Ehcache’s XML configuration, I can define cache-template as mentioned above, but adding the 107 XML configuration extension, I can define that when Cache “users” gets created it gets “enhanced” by a given template.

That way my application can benefit of all Ehcache features without tying itself to any of its APIs. Again, especially useful for existing applications making use of the JSR-107 APIs (whether using other vendor specific APIs or not). Here’s a small example of the use-case above:

Where we also set a defaultTemplate for all other caches created on using that javax.cache.CacheManager.

Try it out!

We’re trying hard to make Ehcache 3 the best JSR-107 provider out there. We actually think we need to address some shortcomings of the specification while doing so… This feature actually came from an issue filed against the Ehcache v2 JSR-107 given some question on our mailing list… So please, try it all out and be vocal! Let us know what you think! In the meantime, we’ll be making progress on the beta release planned for early 2015.

Recently we pushed the first release of ehcache-jcache to maven central, an open-source implementation of the javax.cache API… You should try it out!

Mid-march this year, the JSR-107 expert group released the final javax.cache specification, thirteen years after the initial expert group formed, back in 2001! But we now have a standardized caching API for the Java platform and I believe that this is a good thing for developers.

Ehcache and its engineering team have obviously been supporters of the specification. Not only being involved in its making on paper, but we recently finalized our provider and pushed it to Maven central last week under org.ehcache:jcache. This 1.0.0 release addresses all issues we’ve found during the 2+ months in which we made snapshots available. Obviously, the implementation passes the TCK and supports the features marked as optional by the specification. We’re looking for any feedback you might have, and strongly encourage you to try it out for yourself! Should you have questions or comments, you can post these on IRC #ehcache-dev on freenode, our forums or file any bugs you may encounter directly on github.

It struck me that many tutorials out there (most if not all actually), use older unreleased versions of the specification. I fear this might lead to lots of frustration and confusion. As a result, I put a quick ‘Get Started’ tutorial on github, which you may want to have a quick look at too. It has both – code examples and I’ve added explanations in the wiki section of the project. I plan on adding content there as I can to cover more than the real basics that are currently there. But again, I encourage you to file requests, thoughts and bugs directly on github (and why not fork and contribute back!). Eventually, I’d like to see every aspect of the specification be covered there.

In parallel to these efforts, me and the team at Terracotta will keep on working on the Ehcache 3.0 efforts which, despite a couple of bumps in the road along the way, are still ongoing. I hope to give an update with more details on how we’re seeing these happen soon, including all the good and crazy ideas the team came up with, when we met in San Francisco earlier this month!

As for me, I’ll now try to wrap up the Hibernate second-level cache module using only the javax.cache API. I’ve made quite some progress and hope to finish this by the end of the month… Stay tuned for more details!

The average Western city-dweller is now exposed to more data in a day than 15th century people encountered in their entire lifetime. And that’s just observable data – i.e. the information we physically see and hear on Youtube, 24 hour TV, digital billboard advertising, and the myriad of other informational stimuli generated by modern society.

Below the surface however lurks the bulk of the data iceberg – the complex world of big data.

Big data is what makes everything from Netflix to next generation transport systems what they are to the end user – innovative, responsive and highly personalised. Or, more crucially, it’s the processing, collection, analysis and utilisation of data in an effective manner that’s driving technological innovation.

So as a species evolutionarily hell-bent on making things easier for itself, how will our desire for a more user-friendly future change the way we use big data?

Ignorance is Bliss

With the continuing advance of computational capabilities, the generation of bafflingly voluminous data sets increases as well. Take the Large Hadron Collider as an example. If you were to try and capture all of the collision data it generates, you’d be up against 500 quintillion (5×1020) bytes per day – almost 200 times more than all the other data combined in the world. That would, of course, be impossible. And that’s the point.

Making use of big data begins with knowing how much of it to make use of. In the case of the Large Hadron Collider, that means working with 0.001% of the 600 million collisions per second, which boils down to around 200 significant collisions. This amounts to 30 petabytes of data per year, for which CERN uses Hadoop to store only the metadata. Meanwhile, Terracotta’s in-memory solutions store only the data related to the monitoring of sensors and alarms.

As for the remaining collision data that’s captured? It’s stored on tapes.

So most of what’s happening in the Large Hadron Collider goes uncaptured or gets cataloged. And while the collider is undoubtedly an extreme case, it’s a scalable analogy that applies to the future of big data in just about every application; as big data gets bigger, it will become increasingly important to focus analytical efforts only on what data is practical and useful. People who can interpret data on a meta level and then make smart decisions based on what they see will therefore find their professional stock in increasingly high demand.

Adapt, Adopt, Improve

As technology platforms continue to proliferate, so too do the data sets generated by those platforms. And ever since the 1970s, the pace of data proliferation has perpetually outstripped our ability to capture and interpret data efficiently. This means that where big data’s role in the future of technological innovation is concerned, we must accept that our natural urge to automate and save labor is completely at odds with our innate desire to streamline and simplify. Or as Kurt Marko put it in his Forbes piece entitled ‘Big Data Glut Fuels New Analytic Tools, Services and Start-ups’: “superabundant data offers business benefits that are too compelling to sacrifice on the altar of IT simplicity.”

So the successful organisations of the future will be those who focus their resources and energy on adopting, adapting and improving available technology to manage data in as efficient a manner as possible.
Rather than some utopian one-size-fits-all holy grail, the future of big data will be built on taking the crucial components – be they, Quid, BitYota, Hadoop, Interana etc. – and, by any means necessary, lashing them together to produce the raw materials from which valuable combined insights can be gleaned.

More Speed, Less Haste

Along with the time demands involved in interpreting increasingly large data sets, the explosion in velocity of data also poses problems around latency. To put it more simply, there’s more data being generated more quickly – and because time is money, it needs to be processed and interpreted as quickly and efficiently as possible.

Making use of big data in the future will therefore not only hinge on minimising data latency in order to allow faster decisions to be made, it will also require the analysis and derivation of insight from big data in real time wherever possible.

And just as the past five years saw demand for data scientists skyrocket, the next five years could well see the rise of the “real-time” data scientist – the brightest of the bright who can make quick decisions based on trends they see in real time data streams.

So as Linda Burtch wrote in Wired, “tell your kids to be data scientists, not doctors.”

About the Author

Craig Panigiris is an experienced marketing professional with a 5+ years’ experience in the ICT industry and 10+ years’ experience in B2B marketing. At Professional Advantage, Craig leads a team of marketing professionals to deliver innovative marketing strategies including; cross-channel demand generation campaigns, brand & collateral development, and public relations and is responsible for the development and implementation of the overall strategies for Professional Advantage building repeatable predictable demand generation. He can be contacted at Craig.Panigiris@pa.com.au

- Be realistic about the latency needs from the platform
- Factor in data growth before architecting the platform
- Always plan for new data sources getting introduced as the platform scales
- Not ignore historical data while generating the insights from streaming data
- Think twice before not storing all the ‘noise’ in the raw data as today’s noise could potentially become relevant at a later date

Additionally, IoT has to be treated like any other initiative by identifying the business value before an investment is made. This requires reviewing all the IoT use cases that will increase the revenue and / or optimize the current environment by reducing costs. Some of these use cases, that cut across verticals, are: customer experience management for offering promotions based on real-time data analysis, predictive maintenance, supply chain optimization, loss prevention / fraud prevention, etc.

Though IoT is a promising area, the adoption is growing gradually mainly because of the complexity involved and the lack of standards. We have taken that into consideration while designing our offering to make it easy for an enterprise to go from an idea on paper to a live system in production within a short period of time. If you would like to learn more about this offering, please leave a comment below or email me.

They used BigMemory as part of their setup for improving the performance of their algorithm to identify duplicate reports. BigMemory was used to hold data from different neighborhoods in Chicago that had been partitioned into several equal sized time buckets. This helped optimize the framework to scale to large datasets. For a copy of the winning white paper, please click here.

BigMemory has been generating a lot of interest in several other use cases in the IoT world with its ability to hold high-velocity data that can grow to hundreds of terabytes in a short period of time. BigMemory is a key part of Software AG’s Streaming Analytics platform that was recently rated as the best streaming analytics offering in the market by Forrester. Some of these use cases are in the predictive maintenance space, location analytics, customer experience management, etc. If you would like to learn how BigMemory can be used in your environment, please leave a comment below or contact me.

Matthias kicked off the session by providing a brief overview of CERN and how the world’s largest machine – the Large Hadron Collider (LHC) is setup. Then he explained that even though they generate 30PB/year, they only use Hadoop to store the metadata. The rest of the data is stored on tape as the cost of storage is still a lot less compared to disks as tapes do not consume any electricity when the data is not being accessed. CERN uses Terracotta’s in-memory solution to store sensor data for real-time access to monitoring sensor and alarms.

Manish followed Matthias with a need for building a data layer like Terracotta’s In-Memory Data Fabric. He went on to describe how it can operationalize Hadoop and play a critical role in streaming analytics. He also reviewed the data management and analytics landscape including NoSQL, NewSQL, In-Memory data grid, Spark, and Hadoop. Next was a detailed overview of how CERN is using the Terracotta offering in their environment for high-performance monitoring and to support big data volumes without any scalability or availability challenges.  The details are available in the attached presentation here and demonstrate how critical it is to deploy an in-memory platform when dealing with high-volume and high-velocity data.

If you have any questions about the session or would like to share your thoughts, please leave a comment below.