Lucene是键/值HashMap的好选择吗？

Question

我正面临着一个问题。我正在做一个迷你网络爬虫。现在拥有一个高效的HashMap是很重要的。我只想要只有插入和查找的键/值数据结构。

我知道Lucene可以做到这一点，只要有两个字段: key和value；但是它效率高吗？有没有其他更简单的解决方案？

Ps:它可以是PHP或Java，但我更喜欢PHP。

注意:我需要持久化它。它会被打开和关闭几次。

Answer 1

如果您想要的只是一个用于非巨型数据集的快速、持久的键值存储，Lucene可能不是最好的解决方案- Berkeley DB将是显而易见的选择。这就是说，Grant Ingersoll在今年的Lucene革命会议上发表了关于这一点的演讲。他故意带着支持Lucene的偏见来回答这个问题，并与几位听众就当代文档数据库(如CouchDB)提供了什么而Lucene没有提供的问题进行了反驳，对于任何最终可能需要二级索引的非巨型数据集，我认为这是一个很好的解决方案。Lucene的键/值查找性能不会像Berkeley DB、CouchDB、东京暴君或类似的那样快，但它仍然相当快，对许多应用程序来说绰绰有余。我认为他在最近的笔记本电脑上对键/值的查找测量了大约50毫秒。如果以后你需要添加二级索引(就像你可能根据网络爬行的结果)，那么使用Lucene要比使用这些产品容易得多。

其他工具，如BDB，将比Lucene更容易编码。但是如果这是一个问题，就使用Solr，它使得添加文档和通过简单的HTTP调用进行搜索变得很容易(您需要修改schema.xml配置文件中的字段，否则，Solr应该是开箱即用的)。

现在，如果您的数据集太大，无法在一台计算机上合理地容纳，则分布式键值存储，如Project Voldemort或Riak，可能更易于设置和管理。但是Lucene会让你在一台机器上走得很远，特别是如果你索引的字段不是很多--我猜至少是1TB。

如果你真的使用Lucene，我会认真思考，除了你想要搜索的键之外，是否真的没有任何其他属性--最好在第一次就把它们存储起来，因为Lucene让它变得很容易。

Answer 2

我曾经几次使用solr作为键值存储，记录了数千万条记录。此外，我们在生产环境中有一个索引，其中包括json格式的索引数据的完整副本，并且我们运行返回此值的查询，这样我们就可以避免冗余且速度慢得多的数据库查找。

因此，根据您的需要，这是一个相当不错的解决方案，但您需要意识到其局限性。

专业人士。

1)如果您已经在使用solr或lucene，那么不必使用其他技术是很方便的。

2) Lucene在单行查找方面做得很好，并且应该可以很好地扩展到这个目的。

3)有了几个额外的列，您也可以获得查询能力。

缺点1) Lucene不是设计为事务性存储的。通常，您可以添加多个行，然后提交它们。因此，在ACID意义上，写入不是原子。如果你在存储重要的数据，这通常是件坏事。(近乎)现在，实时索引是可能的，但它仍然需要大量的修改才能正确。

2)因为在您添加和提交之间存在延迟，这意味着读取您自己的写入可能会有问题。

3)如果您需要大量的写吞吐量，最好是批量索引。如果您需要一个接一个地编写单个密钥，您的吞吐量将受到影响。

4)虽然lucene擅长查询，但大的结果集是有问题的。例如，在具有数千万行的solr索引上，生成值的所有键的查询可能会非常昂贵。

Answer 3

你可能想看看Solr，它是Lucene的一个最佳实践实现。它是一个基于REST的接口，非常容易设置，并且有一个你可以使用的PHP client。