Hazelcast 简明教程

Hazelcast - Introduction

Distributed In-memory Data Grid

数据网格是分布式缓存的超集。分布式缓存通常仅用于存储和检索跨缓存服务器分布的键值对。然而,数据网格除了支持键值对存储之外,还支持其他功能,例如,

A data grid is a superset to distributed cache. Distributed cache is typically used only for storing and retrieving key-value pairs which are spread across caching servers. However, a data grid, apart from supporting storage of key-value pairs, also supports other features, for example,

  1. It supports other data structures like locks, semaphores, sets, list, and queues.

  2. It provides a way to query the stored data by rich querying languages, for example, SQL.

  3. It provides a distributed execution engine which helps to operate on the data in parallel.

Benefits of Hazelcast

  1. Support multiple data structures − Hazelcast supports the usage of multiple data structures along with Map. Some of the examples are Lock, Semaphore, Queue, List, etc.

  2. Fast R/W access − Given that all the data is in-memory, Hazelcast offers very high-speed data read/write access.

  3. High availability − Hazelcast supports the distribution of data across machines along with additional support for backup. This means that the data is not stored on a single machine. So, even if a machine goes down, which occurs frequently in a distributed environment, the data is not lost.

  4. High Performance − Hazelcast provides constructs which can be used to distribute the workload/computation/query among multiple worker machines. This means a computation/query uses resources from multiple machines which reduces the execution time drastically.

  5. Easy to use − Hazelcast implements and extends a lot of java.util.concurrent constructs which make it very easy to use and integrate with the code. Configuration to start using Hazelcast on a machine just involves adding the Hazelcast jar to our classpath.

Hazelcast vs Other Caches & Key-Value stores

将 Hazelcast 与其他缓存(如 Ehcache、Guava 和 Caffeine)进行比较可能不是很有用。这是因为与其他缓存不同,Hazelcast 是一个分布式缓存,也就是说,它将数据跨机器/JVM 分发。尽管 Hazelcast 也可以在单个 JVM 上很好地工作,但它在分布式环境中更有用。

Comparing Hazelcast with other caches like Ehcache, Guava, and Caffeine may not be very useful. It is because, unlike other caches, Hazelcast is a distributed cache, that is, it spreads the data across machines/JVM. Although Hazelcast can work very well on single JVM as well, however, it is more useful is a distributed environment.

同样,将其与 MongoDB 之类的数据库进行比较也没有多大用处。这是因为 Hazelcast 主要将数据存储在内存中(尽管它也支持写入磁盘)。因此,它提供了较高的 R/W 速度,但限制在于数据需要存储在内存中。

Similarly comparing it with Databases like MongoDB is also of not much use. This is because, Hazelcast mostly stores data in memory (although it also supports writing to disk). So, it offers high R/W speed with the limitation that data needs to be stored in memory.

与其他数据存储不同,Hazelcast 还支持缓存/存储复杂数据类型并提供了查询它们的接口。

Hazelcast also supports caching/storing complex data types and provides an interface to query them, unlike other data stores.

然而,可以与 Redis 进行比较,它也提供了类似的功能。

A comparison, however, can be made with Redis which also offers similar features.

Hazelcast vs Redis

在功能方面,Redis 和 Hazelcast 非常相似。然而,以下几点是 Hazelcast 优于 Redis 的地方−

In terms of features, both Redis and Hazelcast are very similar. However, following are the points where Hazelcast scores over Redis −

  1. Built for Distributed Environment from ground-up − Unlike Redis, which started as single machine cache, Hazelcast, from the very beginning, has been built for distributed environment.

  2. Simple cluster scale in/out − Maintaining a cluster where nodes are added or removed is very simple in case of Hazelcast, for example, adding a node is a matter of launching the node with the required configuration. Removing a node requires simple shutting down of the node. Hazelcast automatically handles partitioning of data, etc. Having the same setup for Redis and performing the above operation requires more precaution and manual efforts.

  3. Less resources needs to support failover − Redis follows master-slave approach. For failover, Redis requires additional resources to setup Redis Sentinel. These Sentinel nodes are responsible to elevate a slave to master if the original master node goes down. In Hazelcast, all nodes are treated equal, failure of a node is detected by other nodes. So, the case of a node going down is handled pretty transparently and that too without any additional set of monitoring servers.

  4. Simple Distributed Compute − Hazelcast, with its EntryProcessor, provides a simple interface to send the code to the data for parallel processing. This reduces data transfer over the wire. Redis also supports this, however, achieving this requires one to be aware of Lua scripting which adds additional learning curve.