lucene - 为什么像 Lucene/Solr 这样的文档存储不包含在 NoSQL 对话中？

Question

我们所有人最近都遇到了最近大肆宣传的非 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 本身。 (对于那些不了解的人来说，Solr 是一个 Web 服务，它使用 REST 可调用查询和索引转储包装 Lucene。)

我不明白的是，为什么 Solr 没有被计入典型的非 SQL 解决方案选项列表中？我在这里错过了什么吗？我认为有技术原因导致 Solr 无法与 CouchDB 等相媲美，事实上我知道 CouchDB 使用 Lucene 作为其数据存储(是吗？)，但是是什么让 Solr 失去资格呢？

我并不是以某种 Solr 粉丝的身份来提问，我只是不明白为什么 Solr 之类的东西不符合 no-SQL 的定义，如果 Solr 在技术上确实符合定义，那么又如何呢？这可能会让人们嗤之以鼻吗？我这么问是因为我很难确定是否应该继续使用基于 Lucene 的解决方案(例如 Solr)来构建我构建的解决方案，或者是否应该对这些其他选项进行更多研究。

Answer 1

我曾经听过作家 Ursula K. LeGuin 关于小说写作的采访。采访者向她询问了从事不同写作类型的作家。是什么让一位作家成为浪漫小说作家，另一位作家成为推理小说作家，还有一位作家成为科幻小说作家？勒古恩回应解释道:

Genre is about marketing, not about content.

这是一个令人大开眼界的声明。

我认为这同样适用于技术解决方案。 NoSQL运动之所以引人注目，是因为它现在充满了营销能量。 Hadoop、CouchDB、MongoDB 等 NoSQL 数据存储有商业企业的支持，插入他们的解决方案新颖、创新且令人兴奋，以便他们能够发展业务。 “NoSQL”一词是一个营销品牌，可以帮助他们解释其值(value)。

你说得对，Lucene/Solr 在技术上与 NoSQL 文档存储非常相似:它是一个非规范化的文档包(他们的术语)，其中的字段在整个文档集合中不一定一致。它以复杂的方式建立索引，允许您跨所有字段或按特定字段进行搜索。

但这并不是 Lucene 用来解释其值(value)的类型。他们没有同样的使命来发展市场和业务，因为他们由 Apache 基金会管理。他们很高兴专注于全文搜索的用例，尽管该技术可以用于其他方式。他们遵循软件成功的原则:做一件事，并把它做好。