Solr / Lucene的反向索引和查询支持RDBMS功能的子集，即过滤，排序，分组，分页。从这个意义上讲，它非常接近nosql数据库，因为它也不支持事务和连接。
使用类似Hibernate-Search的框架，甚至可以将复杂对象映射到索引并执行基本的CRUD操作，同时支持全文搜索。
考虑：
1）写入吞吐量 根据我过去的经验，Lucene索引的写入吞吐量远低于RDBMS
2）查询速度 由于反向索引，Lucene索引的查询速度应该具有可比性，如果不是更快的话。
3）可扩展性 可以使用replication或Solr-cloud解决。
4）处理大数据集的能力 我在一个JVM上使用了带有15M +文档的lucene索引而没有任何性能问题。
背景
我目前正在使用带有Solr的MongoDB，它运行良好。但是，它并不像我希望的那样“简单”：
从我到目前为止所进行的小规模测试来看，我还没有发现任何阻止我使用Solr / Lucene作为持久性的技术障碍。但是，我也不想在没有更多信息的情况下进行如此激烈的重构。我也意识到像Solandra这样的项目试图将NoSQl和Solr结合在一起，但它们似乎还不够成熟。
问题
因此，对于全文搜索是主要（但不是唯一）要求的应用程序，那么传统（RDBMS）和现代（NoSQL）数据存储是否可行？
精彩参考感谢raticulin
答案 0 :(得分：2)
Lucene - 全文检索/信息检索库。 Solr - 基于Lucene构建的企业级搜索服务器。
不应该使用Lucene / Solr来代替持久性，也不能替代RDBMS，将它们与RDBMS进行比较也不是一件好事，你要比较苹果和它们。桔子。
目前，与RDBMS相比，Lucene的索引吞吐速度无济于事。直接比较是不对的，可能有很多因素会影响Lucene的吞吐量，具体取决于您的搜索架构配置。
Lucene拥有众所周知的＆amp;信息检索的最佳数据结构，您获得的查询速度取决于配置，硬件等因素的数量。
显然，这是最佳选择。
在单个JVM上处理15M +非常棒，但如果不了解文档大小，使用的功能集，JVM内存，CPU核心等等，它就不会有太多...
现在，如果你的问题是RDBMS是真正的可扩展性瓶颈，你可以根据你的持久性需求选择一个NoSQL数据存储区，然后你可以通过集成Solr / Lucene来提供全文搜索功能。由于NoSQL正在快速发展并且相当新的你可能找不到相当稳定的适配器来集成Solr / Lucene和NoSQL。
修改
现在问题已经更新，这个问题已在NoSQL (MongoDB) vs Lucene (or Solr) as your database中得到充分讨论。拥有太多移动部件可能会很痛苦，Lucene / Solr可以很好地取代MongoDB，具体取决于应用程序。但是你必须考虑NoSQL数据存储是从头开始构建完全分布的，你不会丢失或由于扩展而具有有限的功能，而Solr不是考虑到分布式计算而构建的，因此存在限制Distributed Search limitations它是水平缩放。 SolrCloud也可能是答案..
答案 1 :(得分：2)
我想我记得看过Atlassian的一些演讲，他们解释说，对于Jira来说，现在只使用Lucene，他们放弃了以前的数据库（无论是什么）并使用Lucene作为存储。他们很高兴。
如果有人可以确认它会很酷。
编辑：
http://blogs.atlassian.com/rebelutionary/downloads/tssjs2007-lucene-generic-data-indexing.pdf