我们可以定制Solr中嵌入的Lucene吗？
我们可以像在原始 Lucene 中一样定制嵌入到 Solr 中的 Lucene 吗？这样我们就可以在 Solr 中拥有 Lucene 中拥有的“一切”？
我问这个问题是因为我们陷入了决定 Solr 与 Lucene 的困境，如下思考：
参数 1：
“如果 我们选择Solr，Lucene更好 因此选择...所以我们不妨 开始编写 HTTP 包装器，差不多了 Solr 的一半位于我们之上 Lucene 更安全。 ”
论点 2：
“Solr 已经具备我们所具备的所有功能 想用，为什么不直接用呢？ 由于致力于 Lucene 的人是 还负责承诺 Solr、Lucene的所有功能都是 Solr 也可用...”
我浏览了许多博客和帖子，内容如下：
对于您有非常定制的要求的情况 对 Lucene API 类的低级访问，Solr 更适合 阻碍多于帮助，因为它是额外的间接层。
-http://www.lucenetutorial.com/lucene-vs-solr.html
捍卫论点 2 的一种方法是确认我们可以在 Solr 中自定义底层 Lucene，就像我们只有 Lucene 时所做的那样。
有人可以提供更好的方法来结束这个争论吗？ :)
ps ：我们需要通过索引和分片 TB 数据进行快速搜索......
Can we customize Lucene which is embedded in Solr just as we can in raw Lucene ? So that we can have "everything" that we have in Lucene in Solr ?
I am asking this because we are stuck at a point of deciding Solr vs Lucene, thinking like so :
Argument 1 :
"We might hit a dead zone in future if
we choose Solr, and Lucene is a better
choice hence... So we might as well
start writing HTTP wrappers and almost
half of Solr ourselves on top of
Lucene to be on safer side. "
Argument 2 :
"Solr already has all the features we
want to use, so why not just use it ?
Since people who commit to Lucene are
also responsible for committing to
Solr, all features of Lucene are
available to Solr too..."
I went through many blogs and posts that say something like :
For situations where you have very customized requirements requiring
low-level access to the Lucene API classes, Solr would be more a
hindrance than a help, since it is an extra layer of indirection.
-http://www.lucenetutorial.com/lucene-vs-solr.html
One way of defending Argument 2 is by confirming that we can customize the underlying Lucene in Solr just like we would do if we had only Lucene.
Can someone provide a better way of closing this argument ? :)
ps : We need a fast search with indexing and sharding terabytes of data...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，可以。但请记住这一点：
Lucene 和 Solr 提交者是全文搜索领域最重要的专家之一。他们在该领域拥有多年的经验。如果您认为您可以比他们做得更好，那么请继续根据您的需求更改 Solr（它是 Apache 许可的，因此没有任何商业限制），如果您这样做，请尝试这样做，以便您以后可以贡献它回到项目，让每个人都能受益，项目不断向前发展。
但对于绝大多数 Solr 用户来说，库存产品已经绰绰有余，可以满足所有需求。
换句话说，在开始更改代码之前，请在邮件列表（stackoverflow 或 solr-user）上询问，很有可能您实际上并不需要更改任何代码。
“通过索引和分片 TB 级数据进行快速搜索”正是 Solr 的构建目的。不使用 Not-Invented-Here 或任何其他类似的解决方案（例如 ElasticSearch、Sphinx、Xapian 等）将是一个糟糕的情况。如果您认为需要在任何环境中自定义或扩展搜索服务器，方式，考虑每一个的许可证和底层代码。 Solr 和 ElasticSearch 都是 Apache 许可的，因此它们没有商业限制，并且构建在著名的库 Lucene 之上。
Yes, you can. But keep this in mind:
Lucene and Solr committers are some of the foremost experts in the field of full-text search. They have several years of experience in this field. If you think you can do better than them, then go ahead and change Solr to your needs (it's Apache-licensed so there aren't any commercial restrictions), and if you do so try to do it so that you can later contribute it back to the project so everyone can benefit and the project moves forward.
For the vast majority of Solr users though, the stock product is more than enough and satisfies all needs.
In other words, before jumping in to change the code, ask on a mailing list (stackoverflow or solr-user), there's a good chance that you don't really need to change any code.
"Fast search with indexing and sharding terabytes of data" is precisely what Solr was built for. It would be a bad case of Not-Invented-Here not to use it or any of the other similar solutions, such as ElasticSearch, Sphinx, Xapian, etc. If you think you'll need to customize or extend the search server in any way, consider the license and underlying code of each one. Solr and ElasticSearch are both Apache-licensed so they don't have commercial restrictions and are built on top of Lucene, a well-known library.