This short video explains why companies use Hazelcast for business-critical applications based on ultra-fast in-memory and/or stream processing technologies.
Stream processing is a hot topic right now, especially for any organization looking to provide insights faster. But what does it mean for users of Java applications, microservices, and in-memory computing? In this webinar, we will cover the evolution of stream processing and in-memory related to big data technologies and why it is the logical next step for in-memory processing projects.
Now, deploying Hazelcast-powered applications in a cloud-native way becomes even easier with the introduction of Hazelcast Cloud Enterprise, a fully-managed service built on the Enterprise edition of Hazelcast IMDG. Can't attend the live times? You should still register! We'll be sending out the recording after the webinar to all registrants.
Neil is a solution architect for Hazelcast®, is the industry leading in-memory computing platform. In more than 30 years of work in IT, Neil has designed, developed and debugged a number of software systems for companies large and small.
No posts were found matching that criteria.
One of the features of Hazelcast Enterprise is the ability to share data between multiple Hazelcast clusters, whether geographically distant or adjacent. In this blog, we’ll look at the practicalities of keeping the data in multiple clusters synchronized. Business continuity wins There are two conflicting needs here. Data replication happens fastest the nearer the clusters […]
“Which serialization option is best?“. In this post we’ll explore some of the most common serialization options for Hazelcast, which includes standard coding, and the external libraries Avro, Kryo and Protobuf. Following our previous posts on how much memory you will need (here and here) which looked at object sizing in Java, we need to […]
“How much memory do I need for my data?“. — continued! In an earlier post, the space needed to store basic data, such as numbers, was examined. However, we deferred the discussion related to more complex data structures, like the example below: Person { String firstName; String lastName; int age; } At the time, we […]
In a previous blog post, Designing an Evergreen Cache with Change Data Capture, Nicolas describes “one-way” change data capture (CDC). It is a one-way process. In Nicolas’ post, the database copy can change and CDC pushes the change to Hazelcast to align the two copies of the data. Let’s take this a stage further, with “two-way” […]
“How much memory do I need for my data?” This is a pretty common question at the start of Hazelcast projects. Load it and measure it is one answer, which is accurate but not exactly popular. So, let’s take a quick look at why capacity planning isn’t as simple as it seems, by stepping through […]
It’s useful to understand how, why and where Hazelcast stores your data in the grid. What happens is what you really need, but it won’t necessarily be what you first think you want. We’ll explore this in this blog by putting some number keys in a map, a common starting point and source of confusion. […]
Today is PI DAY! Obviously, Pi has rather more than 2 decimal places. To have some fun, let’s use Jet to drive multiple Python workers to calculate Pi with increasing accuracy. A tiny bit of mathematics Pi is the ratio of a circle’s radius to its circumference. It’s 3.14. It’s 3.1416. It’s 3.14159266 or whatever. It […]
Let’s start off the New Year with a fun code example! This example shows how Jet is used to spot the dramatically-named Death Cross for the price of Bitcoin, which is an indication to sell, Sell, SELL!. The idea here is that we could automatically analyze stock market prices and use this information to guide […]
In June 2019, we announced the inclusion of Hazelcast Jet as a runner for Apache Beam. Now it’s time for an example showing how it’s done. As a bonus, it’s not “Word Count.” IoT Data The data we will use is a series of 2,000 GPS points and time offsets: # Latitude, Longitude, Time-Offset 45.417,8.179,1629 45.417,8.178,1630 […]
There are no more posts.
