为什么像Lucene / Solr这样的文档存储不包括在NoSQL对话中？
最近，我们所有人都遇到了无SQL解决方案的炒作。MongoDB、CouchDB、BigTable、Cassandra和其他选项已被列为非SQL选项。下面是一个例子：
http://architects.dzone.com/articles/what-nosql-store-should-i-use
然而，三年前，我和一位同事使用Lucene.NET，因为它似乎符合no-SQL的描述。我们不仅将它用于用户输入的搜索查询；我们还使用它来提高一些重新索引的RDBMS表数据的性能。我们实现了自己的.NET等价排序服务来管理这些索引并使它们可调用。当我离开公司时，团队转到了Solr本身。(对于那些不了解情况的人，Solr是一个web服务，它用REST可调用的查询和索引转储包装Lucene。)
我不明白的是，为什么在非SQL解决方案的典型列表中不包括Solr？我是不是漏掉了什么？我假设有技术上的原因使得Solr不能与CouchDB等相比较，事实上我知道CouchDB使用Lucene作为它的数据存储(是吗？)，但是是什么使Solr失去资格呢？
我不是作为Solr的粉丝或其他什么人问这个问题，我只是不明白为什么Solr之类的东西不符合no-SQL的定义，如果Solr从技术上符合这个定义，那么它会让人们对它感到失望吗？我之所以问这个问题，是因为我很难决定我是应该继续使用基于Lucene的解决方案(比如Solr)来构建我构建的解决方案，还是应该真的用这些其他选项做更多的研究。
回答 2
Stack Overflow用户
发布于 2010-10-08 20:55:46
我认为solr/lucene最相关的特性从nosql列表中掉了下来，因为直到最近，让lucene作为一个实时系统工作是一件痛苦的事情。对于任何性能应用程序来说，通常的工作流程是批量索引增量更新，例如每5分钟更新一次索引。
Stack Overflow用户
发布于 2010-07-29 22:03:03
我觉得stimpy77 is partly right on the NoSQL being a branding thing. .。但同时，NoSQL意味着它是一个比基于SQL的解决方案更简单/更容易的数据存储平台。我认为，虽然Solr/Lucene在某些方面有共同之处(它们存储数据)，但认为Solr/Lucene可以用作任何有关系的东西的主数据存储，这真的是错误的。当然，很多文档都可以放进去，强大的搜索功能可以把它们拉回来。但是，只要您想要关系，那么像CouchDB和其他具有某种查询语法的其他程序就会做得更好。在这种情况下，搜索是一种创可贴解决方案。考虑一下用例“查找所有标记了单词‘car’的文档”。如果我的数据中有一些结构，那么我很容易获得标记汽车的文档，并将每个人都拉回来。而不是依赖于包括fq=tag:'car‘的搜索查询。关系越少，搜索的功能就越强大，但是关系越多，像CouchDB和兄弟这样的数据存储就越好。这就是为什么你仍然看到CouchDB和朋友与Solr配对，反之亦然！让每个人都做自己最擅长的事情。
当然，这并不是说您不能利用Solr存储源数据，Solr可以是一个强大的工具！
https://stackoverflow.com/questions/3339793
复制相似问题