我们有大约 20k 商家数据，大小约为 3mb 如果我们将这些大量数据缓存在一起，那么 hazlecast 性能不佳请注意，如果我们缓存所有 20k 个人，那么为了让所有商家调用速度变慢，因为从缓存中读取每个商家会花费大量网络时间。我们应该如何对这些数据进行分区 什么是分区键 每个分区的最大大小是多少
商家实体属性如下 Merchant Id、父商家 ID、名称、地址、联系人、状态、类型
商家 id 是唯一属性
请建议
问问题
310 次
3 回答
1
加上迈克所说的，看到有数百万条目的 Hazelcast 地图并不罕见，所以我不会关心条目的数量。
您应该构建您的地图以适应您的应用程序设计需求。在一张地图上执行“getAll”对我来说似乎效率低下。创建多个映射或使用允许您对返回的条目更具选择性的复杂键可能更有意义。
此外，您可能想查看索引。您可以索引真正有助于提高性能的键和/或值。您为选择构造的谓词将自动使用任何已定义的索引。
于 2020-06-30T19:55:51.140 回答
0
我不会担心更改分区键，除非您有理由相信默认分区方案没有为您提供良好的键分布。
拥有 20K 商家和每个商家 3MB 的数据，您的总数据约为 60GB。您将多少个节点用于缓存，每个节点的内存大小是多少？将缓存分布在大量节点上应该可以为您提供更有效的带宽。
确保您使用的是高效的序列化机制，默认的 Java 序列化效率非常低（在对象大小和序列化和反序列化速度方面）；使用 IdentifiedDataSerializable（如果是 Java）或 Portable（如果使用非 Java 客户端）之类的东西会有很大帮助。
于 2020-06-29T16:52:56.463 回答
0
我强烈建议你将你的对象从 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。
于 2020-07-01T00:24:31.870 回答