我想将ChronicleMap用作内存映射键值数据库（String到byte[]）。它应该能够容纳1亿条目的订单。读取/获取将比写入/放置更频繁地发生，预期写入速率小于10个条目/秒。虽然密钥的长度相似，但值的长度可能会有很大的变化：它可能是从几个字节到几十个Mbs的任何东西。然而，大多数值的长度在500到1000字节之间。
阅读了一些关于ChronicleMap的内容后，我惊讶于它的功能，我想知道为什么我找不到描述它被用作一般键值数据库的文章。对我来说，使用ChronicleMap为此目的似乎有很多好处。我在这里缺少什么？
在给定的边界条件下使用ChronicleMap有什么缺点？
答案 0 :(得分：2)
我投票支持关闭这个问题，因为任何“缺点”都是相对的。
作为一种数据结构，Chronicle Map没有排序，因此当您需要按键排序时按键排序键值对时它不适合。
当前实现的限制是您需要预先指定将要存储在地图中的元素数量，如果实际数字不接近指定的数字，您将过度使用内存和磁盘（在Linux系统上并不是非常严重），但如果实际条目数超过指定数量大约20％或更多，则操作性能开始下降，性能影响随着条目数量的增加呈线性增长。见https://github.com/OpenHFT/Chronicle-Map/issues/105