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.
It’s said a wise person learns from their mistakes, and a wiser person learns from the mistakes of others. In this blog, we’ll look at some common mistakes made when deploying Hazelcast, so you can avoid them and be that wiser person. In other words, what are the “anti-patterns” that don’t ensure failure, but do […]
Uniformity and balance are key principles for data grids. All grid members should hold the same amount of data, do the same amount of compute and have the same amount of resources (CPU, etc) available. At least approximately. It doesn’t have to be exactly even, but pretty close. A hot spot in the grid means […]
We can send an SQL query to Hazelcast and get results, a great feature. But did you know the data doesn’t have to be stored in Hazelcast to be queryable via Hazelcast? It could be somewhere like a Kafka topic or a CSV file, and you can still query it using Hazelcast’s SQL. This makes […]
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. […]
There are no more posts.
