Hazelcast and C24 waste no time, emit Hypercast after conjoining

Hazelcast has birthed Hypercast, the combined solution that "resolves the compromise between balancing query speed or data capacity", after conjoining with C24 Technologies.

Hazelcast is an in-memory software supplier using a grid of servers, while C24 provides integration objects for financial services messages usimg SWIFT, ISO-20022, FIX and FpML (Financial products Markup Language).

The majority of the worlds' largest banks use C24's software.

According to the Hazelcast website, Hypercast incorporates C24’s PREON Java data binding technology and Hazelcast’s open source in-memory data grid "to deliver near real-time in-memory computing without compromising data access and query time".

Among C24* Technologies' products is PREON – PREON**, not Prion – data optimisation software. It's described as compacting data instead of compressing it. What's the difference?

Data (messages) are encoded, but remains accessible through existing APIs; being binary-optimised. Data that's been compressed into a zip file needs unzipping before access. The binary codes are universal and can be read without proprietary software and on, in theory, any platform. The compaction is said to be optimised for the underlying hardware, which as we're talking x86, doesn't mean much.

C24 said a typical FpML file could take up 7.5KB on disk. When it's bound to Java it increases to 25KB. A compressed version of the FpML file could be 1.4KB, but stick it through PREON and it shrinks to 442 bytes. The data reduction ratio for 25KB to 442 bytes is 56.6:1.

The pair's press release said "C24 PREON is capable of ingesting high-volume complex data messages and compacting them to byte arrays with a “virtual getter” interface that presents binary as POJO***-bound tree structures – but fits in orders of magnitude less memory per message.

For example, in user testing, 7KB messages were shown to be compacted to a mere 200 bytes."

That's data reduction ratio of 35:1, which is still huge by non-backup deduplication comparisons.

Data are ingested serially and then fed through the PREON mincer and turned into slimmed down PREON objects. We're told these appear just like plain old Java objects, but use vastly less memory per message as they reference byte arrays instead of the larger Java objects, and serialisation and deserialisation is almost instantaneous.

So the pitch is to stuff many more of these PREON-ised message objects into a Hazelcast Memory grid system, and then execute the queries "orders of magnitude faster than... competing serialisation technologies and memory stores". That's what Hypercast does.

In one test, the PREON data format stored almost twice as much data in the same memory footprint as the competing serialization technologies. You can check out this benchmark run here. (Registration required, so you'll probably get a mail from an inside sales rep if you download it. We did.)

Straying off the compaction message slightly in his canned quote, Hazelcast's CEO Greg Luck, said: “Hypercast’s novel binary storage approach achieves amazing levels of compression and speed of access."

He called it a game-changer, and no doubt hopes many of Hazelcast's existing 8,000-plus customers will give it a whirl.

It sounds wonderful, so if you are a financial services message-using organisation, check it out. ®

Bootnotes

* C24 was originally Century 24, based in London, UK.

** C24 says: "Preons are hypothetical particles that have been proposed as the building blocks of quarks, which are in turn the building blocks of protons and neutrons. A preon star – which is not really a star at all – would be a chunk of matter, made of these constituents of quarks and bound together by gravity."

*** POJO = Plain Old Java Object and not bound by any restriction.