在使用lucene索引的批量插入中，给定一大组节点和关系，使得节点和关系存储不能完全适合映射内存（因此需要lucene索引缓存），如何在MMIO和MMIO之间划分内存lucene索引缓存实现最佳性能？阅读完文档之后，我已经熟悉了如何在映射内存模式中划分内存。我对MMIO和lucene缓存之间的整体内存分配感兴趣。由于我正在研究硬件碰巧可用的原型，并且未来的资源和数据量尚未确定，我更希望答案是一般性的（我认为这也会使答案对其余部分更有用） Neo4j社区也是。）所以如果我能提出这样的问题会很好：
给出
写入的rwN节点和rwR关系，必须在批量插入中稍后读取， woN节点和woR关系，只写， G千兆字节的RAM（不包括操作系统所需的内容）
lucene索引缓存与MMIO之间G的最佳划分是什么？
如果需要更多细节，我可以根据我的具体情况提供。
答案 0 :(得分：0)
所有这些考虑事项仅与导入（多个）数十亿个节点和关系
相关通常，当您进行查找时，它取决于＆＃34;热数据集大小＆＃34;您的索引查找。
默认情况下，所有节点都是如此，但如果您更了解您的域，则可以设计一些分页，从而产生较小的所需缓存（例如，通过预先对输入数据进行排序，以便通过开始和结束节点创建关系） lookup-property）然后你在节点数据上有一个移动窗口，在此期间经常访问每个节点。
我通常甚至按分（开始，结束）排序。
通常，您尝试将大部分RAM用于rel-store和node store的mmio映射。物业商店只写入，但其他商店也必须更新。
索引缓存查找只是幕后的HashMap，所以非常浪费。我发现更好地工作是使用不同的方法，例如多次通过。