2

我想使用ChronicleMap作为内存映射键值数据库（Stringto byte[]）。它应该能够容纳多达 1 亿个条目。读取/获取将比写入/放置更频繁地发生，预期写入速率低于 10 个条目/秒。虽然键的长度相似，但值的长度可能会有很大差异：它可以是从几个字节到几十 Mbs 的任何内容。然而，大多数值的长度在 500 到 1000 字节之间。

阅读了一些关于 ChronicleMap 的内容后，我对它的功能感到惊讶，并且想知道为什么我找不到描述它被用作通用键值数据库的文章。对我来说，将 ChronicleMap 用于此目的似乎有很多优势。我在这里想念什么？

对于给定的边界条件，使用 ChronicleMap 有什么缺点？

4

1 回答 1

3

我投票赞成结束这个问题，因为任何“缺点”都是相对的。

作为一种数据结构，Chronicle Map 是没有排序的，所以当你需要按 key 的排序顺序迭代键值对时，它并不适合。

当前实现的限制是您需要提前指定要存储在地图中的元素数量，如果实际数量不接近指定数量，您将过度使用内存和磁盘（虽然在 Linux 系统上不是很严重），但是如果实际条目数超过指定数量大约 20% 或更多，则操作性能开始下降，并且性能损失随着条目数的进一步增长而线性增长。见https://github.com/OpenHFT/Chronicle-Map/issues/105

于 2018-01-02T11:08:00.990 回答