填充内存数据网格 Hazelcast 的最快方法答案

【问题标题】：The fastest way to populate a In Memory Data Grid Hazelcast填充内存数据网格 Hazelcast 的最快方法
【发布时间】：2016-03-28 21:10:51
【问题描述】：

填充 Hazelcast 数据网格的最快方法是什么。通读文档，我可以看到几个变体：

我的性能基准显示 IMap.putAll 比 IMap.Set 快。但在 Hazelcasty 文档中指出 IMap.putAll 并不能保证所有内容都将被原子插入。

有人可以澄清一下用数据填充数据网格的最快方法是什么？

3号变种好吗？

【问题讨论】：

【解决方案1】：

我会看到相同的三个选项。无论如何，正如您所提到的，选项二并不能保证所有内容都以原子方式放入地图中，但如果您只是加载数据并等待所有线程使用 IMap::putAll 完成加载数据，您应该没问题。

除此之外，IMap::set 将是替代方案。在任何情况下，您都希望多线程加载过程。我会尝试使用不同的线程数，通常建议从客户端加载数据以保持节点空闲以进行存储操作。

我个人从未对您的第三个选项进行基准测试，无论如何这也是可能的。只是不确定是否值得额外的工作。

您想加载多少数据而您担心它可能会很慢？你知道加载速度很慢吗？您是否使用 Java 序列化（这是一个巨大的性能杀手）？您是否使用索引（必须在放置数据时生成）？

通常有很多优化可用于加快数据加载和正常操作的速度。

【讨论】：

嘿，谢谢你的回答。我或多或少想知道是否有蚂蚁点测试选项opinion 3。如果有第四个选项。至于您的问题，外包团队声称他们的表现比商店到 DB 更差。到目前为止，我已经看到他们使用 IMAP::put 而不是 IMAP::putAll。序列化看起来不错。他们正在使用 Spring Batch 以并行方式弹出网格。我今天会检查更多。
你好，我刚看到源代码。它正在使用事务映射，而事务映射的实现中缺少 putAll 方法。这是如何改变事情的？我们如何将批量放入这个事务性 Map 中？
您好，使用 TransactionalMap 时观察到一个有趣的副作用。性能高度依赖于 MAP 中插入的对象数量。当插入的块大小为 1000 时，速度明显低于块大小 250。为什么会这样？有什么改善的方法吗？
我怀疑因为同步事务的额外开销，无论如何这不是一个真正的想法。为什么你还要费心使用事务地图？如果您想要快速加载，我无法相信您在 IMap::set / IMap::put / IMap::putAsync 循环上使用 TransactionalMap::putAll 更快。
我没有检查 putAsynch 但我会仔细检查 putAll 与 put/set 的结果。在一个线程中，我的印象是 putAll 更快。