正在初始化群集分区表排列。。。在Hazelcast中，3.9.1花费的时间太长

Question

我试图创建一个Hazelcast服务项目，其中我将订阅一个RDBMS（Oracle DB 12c）数据存储，使用反射动态创建一个POJO/JavaBean，然后解析JavaBean对象以映射JDBC ResultSet作为结果行值放入JavaBean对象，并将这些映射对象加载到分布式映射中。

我检查了两个表的数据量，我试图从这两个表加载在Hazelcast IMap中，它低至0.0625和0.0316 MB。因此，这是一个更简单的Hazelcast实现，只需在localhost上初始化两个并行实例/节点。

我在Java Main方法中计时从创建Java POJO类到在Hazelcast IMAP中创建和加载每个相应对象的那一刻起的总运行时间。

据我所知，从系统的角度来看，这花费的时间太长，因为我们甚至在测试和生产箱中看到类似的行为，系统规格比下面给出的要好3到4倍。请帮助提供建议，说明有什么问题，或者这是第一次在hazelcast IMDG中使用集群中的2个节点进行分区时的常见情况。

系统规格如下：

Macbook Pro 2014处理器：2.6 GHz Intel Core i5内存：8 GB 1600 MHz DDR3

请查找日志。。。

2018年2月26日上午10:30:39。黑泽尔卡斯特。内部的隔断impl。PartitionStateManager信息：[xx.xxx.xx.xxx]：5702[dev][3.9.1]正在初始化群集分区表排列。。。userMaster映射中的条目数：883

用户主地图中的条目数：7499

持续时间约为： 92520毫秒Feb26, 2018 10:32:10AMcom.hazelcast.core.生命周期服务信息：[xx.xxx.xx.xxx]： 5701[dev][3.9.1][xx.xxx.xx.xxx]： 5701SHUTTING_DOWN

Answer 1

虽然我无法修复MapLoader问题，但ResultSetsetFetchSize（）的主要问题仍然存在。这被设置为10，这导致网络i/o过高。一旦我增加到1000或更多，它就会变得更快。

日志：

使用常规FetchSize（）：preparedStatement。getFetchSize（）：2018年2月28日10:24:51 PM com。黑泽尔卡斯特。内部的隔断impl。PartitionStateManager信息：[xx.xxx.xx.xx]：5702[dev][3.9.1]正在初始化群集分区表排列。。。

userMaster映射中的条目数：26464

持续时间约为：276178毫秒

使用更大的FetchSize（）：

tatement.getFetchsize（）： 1000 Feb28, 2018 7:31:06PMcom.hazelcast.internal.partition.impl.分区StateManager INFO：[xx.xxx.xx.xx]： 5702[dev][3.9.1]初始化集群分区表安排...在用户主地图： 26464

持续时间约为：11279毫秒

我肯定会发布服务器和客户端版本的代码，以帮助使用MapLoader，这听起来是最好的方法。

作为进一步的帮助，您是否可以提供一些信息，说明扩展的Mapload/Mapstore技术是否可以为运行时创建的对象/类编写，因为我单独尝试的较小示例是使用固定JavaBean的。

我记得留档提到了MapStoreFactory（）选项。这会有帮助吗？