问题标签 [chronicle-map]

我有以下课程：

我基本上想将编年史地图存储在包装函数中。在这里，Kand与传递的and值V相同。所以我希望 ChronicleMap 映射具有与 and 相同的键和值类型。keyTypevalueTypeKV

但是，当我创建它时，我收到以下错误：

在这一行：

我想知道这个错误是否是因为我对泛型做错了什么。

我在 Windows 10 中使用 ChronicleMap 3.19.4 和 JNA 5.5.0。

这是您可以轻松运行的单个测试：

我已将编年史地图实现为：

Map 有大约 350 万条记录。我正在使用此映射到服务器作为搜索操作的缓存。很多时候要搜索条目列表，我们必须遍历整个地图。350 万条记录占用 8.7 GB 的 RAM，我的 java 堆分配内存为 36 GB。服务器中的总 RAM 为 49 GB。当我使用以下代码迭代地图时：

它总是给我记忆错误。VM.array 大小小于可用内存。在这里迭代这个大地图的任何提示。感谢帮助。

我正在尝试了解 Chronicle Enterprise 附带的市场数据分发器 (MDD) 的概念。

在我看来，Map 和 MDD 都始终拥有键的最新值，并且由于 Chronicle Map 是 Concurrent Hashmap 的实现，因此您当然没有任何并发​​因素。

使用 MDD 与 Chronicle Map 相比有什么优势。我所理解的是，它为竞争密钥提供了更好的延迟。还有什么可以成为使用 MDD over Map 的主要因素吗？

We are evaluating ChronicleMap and our application runs cluster mode with nodes ranging from 5 to 45. The plan is to have the ChronicleMap persisted in shared NFS folder so that all the nodes can read/write.

There are more likely chance that individual nodes could go down for various reasons in the middle of a read/write operation with this said. I have some questions

1. If node-1 goes down during a write operation, can another healthy node-2 in the cluster still continue to read/write to the files?
2. Lets say we implement some logic to detect a server crash and call the .recoverPersistedTo() on restart. Will this cause any issues while other healthy nodes in the cluster are reading/writing to the files? The reason I ask this question is that the document says

“You must ensure that no other process is accessing the Chronicle Map store when calling .recoverPersistedTo()”</p>

3. I have read that using .recoverPersistedTo() in place is createPersistedTo() is not a good practice, but what are the downsides?

While creating a ChronicleMap using the build, it is trying to access(read/write) the following OS(Mac) folders.

1. Read on "/usr/lib" & "/lib"
2. Read & Write on "/Users/userx/Library/Caches/JNA/temp"

I am trying to understand the reason on why these folder access are happening so that I can justify to our security team

我试图了解如何计算持久地图文件的大小。

通过以下方式在磁盘上创建持久映射时：

我想预分配的“foo.dat”文件的大小是键/值大小、条目数和 maxBloatFactor 以及操作系统架构和其他因素的函数。

所以我的问题是：给定一组配置值，是否可以确定地知道“foo.dat”文件的大小最终会是多少？

使用 ChronicleMap 测试堆外缓存。这段代码会创建一个堆外内存映射吗？

根据这个答案ChronicleMap 的 entrySet().iterator() 将转储内存中的所有对象。

我不想加载内存中的所有对象并过滤内存中的整个地图 - 这违背了 Chroniclemap 的目的。

所以现在，给定一个编年史地图类型 <LongValue, Pojo>，以及 0-1000 范围内的键，我将如何 -

1. 获取范围 >= 500 的键
2. 删除范围 <500 的键

我是 JVM 中堆外存储的新手，而 ChronicleMap 看起来很适合堆外存储。但我主要关心的是性能。

我确实使用配置运行了简单的测试

并发现以下结果

与并发 HashMap 相比，读取性能相当低。

我已经尝试使用 1024/2048 段，默认膨胀因子，默认 Marshaller。但还是一样的结果。

我只是想利用堆外特性来减少 GC 暂停，并且无意使用持久性事物或复制或使用 JVM 之外的映射。

所以问题是我应该使用 ChronicleMap 还是坚持使用 ConcurrentHashMap？或者在 ChronicleMap 的情况下，我可以使用任何其他配置来提高性能？

提前致谢。

** 使用https://github.com/OpenHFT/Chronicle-Map/blob/master/src/test/java/net/openhft/chronicle/map/perf/MapJLBHTest.java进行基准测试：**

Chronicle 地图的每个示例都需要在构建器中指定一个“条目”大小，但我不明白这个值对持久化地图的影响：

1. 当我在此地图中插入超过 999 个条目时会发生什么？
2. 这个数字是否定义了 Chronicle 或内存映射的 find 应该为我保存在内存中的条目数？