Java 将大型数据对象缓存到Hazlecast中的最佳方法是什么

我们拥有约20000个商户数据，大小约为3mb 如果我们将这些大量数据缓存在一起，那么hazlecast性能就不好 请注意，如果我们缓存所有20k个人，那么对于get all merchants，由于从缓存读取每个商户会花费很高的网络时间，因此呼叫速度会减慢。 我们应该如何划分这些数据 分区密钥是什么 每个分区的最大大小是多少

商户实体归属如下 商户Id、上级商户Id、姓名、地址、联系人、状态、类型

商户id是唯一的属性

---

请建议

除非您有理由相信默认的分区方案不能很好地分配密钥，否则我不会担心更改分区密钥

有20000个商户和每个商户3MB的数据，您的总数据约为60GB。缓存使用了多少个节点，每个节点的内存大小是多少？将缓存分布在更多的节点上，应该可以提供更有效的带宽

---

确保您使用的是高效的序列化机制，默认的Java序列化效率非常低（在对象大小和序列化和反序列化速度方面）；使用诸如IdentifiedDataSerializable（如果是Java）或Portable（如果使用非Java客户端）之类的工具可能会有很大帮助。

再加上Mike所说的，看到Hazelcast地图有数百万条条目并不罕见，因此我不关心条目的数量

您应该根据应用程序的设计需要构建地图。对我来说，在一张地图上进行“getAll”似乎效率低下。创建多个映射或使用一个复杂的键（允许您对返回的条目进行更多选择）可能更有意义

---

此外，您可能需要查看索引。您可以为真正有助于提高性能的键和/或值编制索引。为选择构造的谓词将自动使用任何已定义的索引。

我强烈建议您将对象从3MB分解为几10 kb，否则您将遇到与Hazelcast无关的问题。例如，fat数据包阻塞了其他数据包，导致读/写操作延迟大、序列化/反序列化开销大、网络阻塞等。您已经确定网络时间很长，如果不平坦化值对象，它就不会消失。如果您的是高读用例，那么我还建议您查看NearCache以获得超低延迟的读操作

至于分区大小，请控制在100MB以下，我认为每个分区的大小在50-100MB之间。简单的数学可以帮助你：

3mb/object x 20k objects = 60GB
Default partition count = 271
Each partition size = 60,000 MB / 271 = 221MB. 
So increasing the partition count to, lets say, 751 will mean:
60,000 MB / 751 = 80MB.

因此，您可以将分区计数设置为751。为了应付未来可能增加的流量，我将分区计数设置为更高的数字-881

注意：始终使用质数作为分区计数

---

仅供参考-在未来的一个版本中，默认分区计数将从271更改为1999。

此外，如果存在不需要商户对象全部内容的用例，使用仅返回特定用途所需字段的投影可能会产生巨大的不同，例如，地址信息可能仅用于计费或发货，而不用于订购；联系人也可能不需要每次都检索。是的，我们有一个用于读取商户对象的较轻版本。我们希望缓存整个对象，因为这将节省昂贵的dB调用。因此，我们应该如何缓存每个对象或将其分组？这在这里是有效的