BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Oracle Coherence 3.7's Elastic Data Offers Transparent Overflow from Memory to Solid State Storage

Oracle Coherence 3.7's Elastic Data Offers Transparent Overflow from Memory to Solid State Storage

This item in japanese

Bookmarks

Oracle has today released version 3.7 of Coherence, its distributed in-memory data grid. The new product introduces a feature called Elastic Data. According to Cameron Purdy, Vice President of Development for the Coherence product, this allows near memory speed access to data, regardless of storage medium.

There's basically no performance delta between in memory and flash for us, thanks to some R&D we did around flash devices and Java's NIO capabilities. So we're able to drive solid state storage devices at a very, very high rate. What this allows us to do, both from the Garbage Collection (GC) optimisations that we've done in 3.7, as well as the ability to transparently overflow to flash, is to run significantly larger heap sizes without significant GC penalties. At the same time whatever doesn't fit on the heap is automatically stored on flash. So it is a pretty dramatic increase in terms of the amount of information that we can manage.

Configuration is also straightforward; you simply tell the JVM how much memory you want to allocate for elastic data, and which solid-state disk to use, and everything else is done automatically.

That theme of simplification of the product can be seen elsewhere. Configuration is now XSD based, which enables tools such as Oracle's own Eclipse-based tooling for Coherence to support auto-complete for configuring clusters and caches.

Another area of the product receiving considerable attention is the Coherence*Extend client/server protocol. Extend allows a variety of applications, such as Excel spreadsheets, C# applications, or C++ code, to connect into the cluster. These are commonly used in trading and banking systems, where security and low-latency are strong requirements. Given that, 3.7 improves the load-balancing capabilities, simplifies configuration, and also provides support for hardware-based SSL acceleration. Purdy told us

We've added WKA (Well Known Address) support. That allows the clients to have a very, very simple configuration. They attach in through one of the Well Known Addresses, and then they load balance from there. And that allows them to quickly discover all the potential servers that they could be load balanced across. The load balancing can be done either on the client side or the server-side.

Aside from software-based load balancing, the Oracle Coherence team have added integration with the F5 BIG-IP Local Traffic Manager (LTM) product, a hardware load balancer. This integration supports hardware SSL acceleration, so Coherence can now do SSL acceleration on the server, taking advantage of some of the advanced instructions available through the Intel CPUs, for example, or it can overload the CPU-intensive SSL encryption to the hardware load balancer.

Finally, the Coherence team have also been working on GlassFish integration. The 3.7 release introduces native integration of Coherence*Web, an HTTP session management module dedicated to managing session state in clustered environments, via an SPI for GlassFish. This allows "no code change" installation and configuration of Coherence*Web on GlassFish application servers. This puts GlassFish on a par with WebLogic in terms of support.

The original Coherence product was developed by Tangosol, acquired by Oracle in April 2007, when Coherence had about 120 direct customers. Since the acquisition, the Coherence product's install base has grown considerably, and is now in the thousands, Purdy told us. Whilst traditionally Coherence has been used by financial services organisations, Oracle has started to see it getting deployment in other verticals, such as large eCommerce, telecoms and logistics companies, as well as gaming companies such as Riot Games (QCon presentation) and LucasArts.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • congrats

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    sounds like lots of neat features and enhancements.

  • Sounds like Cassandra's and HBase's log structured system

    by Ashwin Jayaprakash,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Sounds like a simpler version of what Cassandra and other disk based NoSql projects are doing.

    Finally, a validation of NoSQL by Oracle?

    Nice work though!

    Ashwin (www.ashwinjayaprakash.com)

  • Re: Sounds like Cassandra's and HBase's log structured system

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Ashwin -

    Funny, I always thought Cassandra was a validation of what Coherence was doing .. ;-)

    Peace,

    Cameron Purdy | Oracle Coherence
    coherence.oracle.com/

  • Re: Sounds like Cassandra's and HBase's log structured system

    by Ashwin Jayaprakash,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well..Cassandra and Voldemort took an async/eventually consistent approach. And Hbase and Cassandra are heavily disk based....

    But I'm a big fan of Coherence - I love the features and the elegant APIs!

    Cheers!

  • Re: Sounds like Cassandra's and HBase's log structured system

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Just because Cassandra uses key/value to store data, they are quite different at many levels. My bias opinion, you couldn't swap out one and replace it with the other. They both show the power of key/value approach, but I fail to see how that validates or invalidates NoSql. If anything, key/value store in-memory or on-disk compliment relational databases.

  • about larger heap sizes and flash role

    by Dominique De Vito,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Enabling significantly larger heap sizes without significant GC penalties is sweet.
    In the past, I had read 1Go by JVM was the initial target for Coherence in order not to have such GC penalties.
    How much memory can we get today with 3.7 improvements ?

    Is flash memory used for overflow purposes *only*, or is flash used also like non-flash memory for main data storage ?

    Thanks for answers.

  • Re: about larger heap sizes and flash role

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    > How much memory can we get today with 3.7 improvements ?

    We were testing 3.7 with up to 31GB heaps (using G1) with good results. The object count reduction helps, no doubt.

    > Is flash memory used for overflow purposes *only*, or is flash used also like non-flash memory for main data storage ?

    The priority is to use the amount of RAM that's been provided to the Elastic Data feature, but once that's used up all storage goes to flash.

    Peace,

    Cameron Purdy | Oracle Coherence
    coherence.oracle.com/d

  • Re: about larger heap sizes and flash role

    by Dominique De Vito,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    While Coherence is able to leverage off-heap memory like Flash, what about leveraging another off-heap memory, that is off-heap RAM (through direct buffer for example) ? It would decrease GC impact too.

    Is off-heap RAM leveraged by Coherence too ?
    If yes, have you done experiments with it too ?

    Thanks.

  • Re: about larger heap sizes and flash role

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We've supported off-loading to NIO RAM for about 8 years now, but our implementation has some limitations, primarily related to how Java manages NIO buffers (GC-related issues). This is called "BinaryMap" in Coherence, and it uses ByteBufferManager to handle the NIO allocations. (Unfortunately, we didn't provide a centralized "resource manager", so global buffer pooling wasn't possible. That's one of the things we corrected when we designed Elastic Data, which provides for global pooling.)

    The new Elastic Data implementation also supports NIO buffers (via an advanced configuration option), but we found that there was a performance impact of using NIO buffers that wasn't made up for by GC gains, since our Elastic Data RAM usage is in very large blocks (whether on or off heap).

    I think there is still a use case for NIO buffers, but not with the Elastic Data implementation that we have today.

    Peace,

    Cameron Purdy | Oracle Coherence
    coherence.oracle.com/

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT