使用 ChronicleMap 作为键值数据库答案

【问题标题】：Using ChronicleMap as a key-value database使用 ChronicleMap 作为键值数据库
【发布时间】：2018-01-02 19:08:00
【问题描述】：

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

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

在给定的边界条件下使用 ChronicleMap 有什么缺点？

【问题讨论】：

标签： chronicle chronicle-map

【解决方案1】：

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

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

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

【讨论】：

感谢您的回答。 (1) map 只需要按键获取值。我不会对其进行迭代，也不需要对其进行排序。 (2) 我认为在具有 ext4 文件系统的 Linux 上，理论上您可以为内存映射文件提供不超过可用磁盘空间的任何大小。该文件最初会很小，随着数据的填充而增长。我计划用大量条目（500m）初始化地图并设置averageValueSize，以便计算出的最大文件大小不会超过磁盘空间。如果不是这样，请纠正我。
浪费来自内部碎片（在hash lookup area），而不是外部碎片，所以即使在Linux上和使用任何文件系统也是不可避免的。
根据您的值大小差异，我建议直接指定actualChunkSize，以及其他“低级”配置，即。 e. actualChunksPerSegmentTier、actualSegment 和 entriesPerSegment。
@xpages-noob 这取决于您所说的“更长”如果您的意思是 10 倍长，这应该是一个问题，如果您的意思是 1000 倍大，请使用另一个地图。
@xpages-noob number 64 来自于我们使用 bitset 进行空间分配的事实，它切换到慢一点的算法，因为 > 64 位不适合原始的 long 值，但不是很适合.如果您需要 100 或 1000 个块的条目，那么 Chronicle Map 实际上并没有什么大不了的，正确配置的每层块数/条目数应该可以处理它。如果您不需要任何高更新并发，我建议您指定更少的段（或仅 1 个）。