如果你想要的只是一个非庞大的数据集的快速,持久的键值存储,Lucene可能不是最好的解决方案 - Berkeley DB将是显而易见的选择.也就是说,Grant Ingersoll在今年的Lucene Revolution会议上发表了关于这一点的演讲.他故意以支持Lucene的方式提出这个问题,并与几位观众进行了一次反复讨论当前文档数据库(如CouchDB)提供的Lucene没有提供的内容.对于可能最终需要二级索引的任何非大型数据集,我认为这是一个很好的解决方案.Lucene的键/值查找性能不会像Berkeley DB,CouchDB,Tokyo Tyrant等那么快,但它仍然非常快,对于许多应用来说已经足够了.我认为他在最近的笔记本电脑上测量键值/值约为50毫秒.如果稍后您需要添加二级索引(因为您可能会对Web爬网的结果感兴趣),那么使用Lucene比使用这些产品更容易.
其他工具,比如BDB,比Lucene更容易编码.但是,如果这是一个问题,只需使用Solr,这样可以轻松添加文档并通过简单的HTTP调用进行搜索(您需要修改schema.xml配置文件中的字段,但除此之外,Solr应该准备好了 - 开箱即用).
现在,如果您的数据集太大而无法合理地放在一台计算机上,那么分布式键值存储(如Project Voldemort或Riak)可能更容易设置和管理.但是Lucene会让你在一台机器上相当远,特别是如果你没有索引很多领域 - 至少是TB,我猜.
如果你确实使用Lucene,我会认真考虑除了你想要搜索的关键字之外是否真的没有任何属性 - 也可以在第一次存储它们,因为Lucene让它变得简单.
| 归档时间： |
|
| 查看次数： |
3163 次 |
| 最近记录： |