使用Lucene目录作为主文件存储有什么缺点？

Question

我想使用Lucene MMapDirectory作为主文件存储。每个文件将作为StoredField中的字节数组存储在单独的文档中。应该可搜索的所有文件属性（如文件名，大小等）将存储在同一文档的可索引字段中。

我的问题是：

1. 使用Lucene目录存储文件有什么缺点，特别是在索引和搜索性能以及内存（RAM）消耗方面？
2. 如果这不是“禁止”，那么在目录中存储文件的方式是否比字节数组更好/更快？

Answer 1

Short Answer

我真的很喜欢Luсene并认为它是最好的开源库，但我担心将它用作主要文件源并不是一个好的决定，因为：

• 高CPU /内存开销
• 慢速索引/查询性能
• 硬盘利用率高，索引大小翻倍
• 恢复能力薄弱

Long Answer

在引擎盖下，lucene使用以下文件将所有存储的字段保存在一个段中：

• 字段索引文件（.fdx），
• 字段数据文件（.fdt）。

您可以在Lucene50StoredFieldsFormat’s文档中详细了解它的工作原理。

1. 这意味着在出现任何I / O问题时，几乎不可能恢复任何文件。
2. 为了返回一个文件 - lucene必须以逐块的方式从盘中读取和解压缩二进制数据。这意味着解压缩的CPU开销很高，并且内存占用空间很大，以便将整个文件保存在Java堆空间中。与文件和网络存储相比，没有流媒体也是avaialbe。
3. 最大文档大小受编解码器实现的限制 - 每个文档2 GB
4. Lucene有一个独特的一次写入分段架构：最近索引的文档被写入一个新的自包含段，只能附加，一次写入：一旦编写，这些段文件将永远不会再次改变。当使用太多RAM来保存最近索引的文档时，或者当您要求Lucene刷新搜索器以便您可以搜索所有最近编入索引的文档时，就会发生这种情况。随着时间的推移，较小的段被合并为更大的段，并且索引在任何时候都具有活动段文件的对数“阶梯”结构。这种架构成为文件存储的一个大问题： 你无法删除文件 - 仅标记为不可用 合并操作需要2倍的磁盘空间并消耗大量资源和磁盘吞吐量 - 它创建新的.fdt文件并通过java代码和java堆内存复制其他.fdt文件的内容

Answer 2

所以你不会使用MMapDirectory而是使用实际的lucene索引。

我使用lucene作为某些项目的主要数据存储已经取得了很好的经验。

请确保还包含生成的/自然的唯一ID，因为文档ID不是常量或可靠的。

还要确保使用适合您的用例的Directory实现。我已经在低负载情况下切换到正常的RandomAccess实现，因为它使用更少的内存并且几乎一样快。