将大数据对象缓存到 Hazelcast 的最佳方法是什么答案

【问题标题】：What is the best way to cache large data objects into Hazlecast将大数据对象缓存到 Hazelcast 的最佳方法是什么
【发布时间】：2020-10-19 20:33:48
【问题描述】：

我们有大约 20,000 个商家数据，大小约为 3mb 如果我们将这些大量数据缓存在一起，那么 hazlecast 的性能就不行了请注意，如果我们缓存所有 20k 个个体，那么为了让所有商家调用减慢速度，因为从缓存中读取每个商家会花费大量网络时间。我们应该如何划分这些数据什么是分区键每个分区的最大大小是多少

商家实体属性如下 Merchant Id , parent 商家 id, name , address , contacts, status, type

Merchant id 是唯一属性

请推荐

【问题讨论】：

标签： java api caching hazelcast output-caching

【解决方案1】：

除了 Mike 所说的之外，Hazelcast 地图包含数百万条目并不罕见，因此我不会关心条目的数量。

您应该构建您的地图以适应您的应用程序设计需求。在一张地图上执行“getAll”对我来说似乎效率低下。创建多个映射或使用复杂的键可能更有意义，这样您就可以更有选择性地返回条目。

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

【讨论】：

【解决方案2】：

我不会担心更改分区键，除非您有理由相信默认分区方案无法为您提供良好的键分布。

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

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

【讨论】：

此外，如果在某些用例中您不需要商家对象的全部内容，则使用仅返回特定用途所需字段的 Projection 可能会产生巨大的不同 - 例如，地址信息可能仅用于开票或发货，而不用于订购；也可能不需要每次都检索联系人。
是的，我们有一个更轻的版本来读取商家对象
我们希望缓存整个对象，因为这样可以节省昂贵的 dB 调用。那么我们应该如何缓存每个对象或对它们进行分组 - 这在这里会很有效

【解决方案3】：

我强烈建议您将对象从 3MB 分解为几十 KB，否则您将遇到与 Hazelcast 无关的问题。例如，胖数据包阻塞其他数据包导致读/写操作的严重延迟、严重的序列化/反序列化开销、阻塞网络等。您已经确定了高网络时间，如果不压平值对象，它就不会消失。如果您的用例是读取繁重的用例，那么我还建议研究 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。

【讨论】：