为 solr 构建案例

发布于 2024-08-31 10:11:30 字数 326 浏览 7 评论 0原文

我们的产品由多个应用程序组成,全部使用Lucene。我参与的 2 个应用程序的 Lucene 索引约为 3 Gb 和 12 Gb。另一个团队正在构建一个应用程序,他们估计该应用程序的 LUCENE INDEX 大小接近 1 TB。大约每 15 天就会有新文档添加到索引中。我们当前的应用程序没有任何明显的性能问题。所以我的问题是:

我们现在应该使用 Solr 吗?

什么时候应该停止使用 Lucene 并升级到 Solr?

使用 Solr 有什么缺点/问题吗?

客户端应用程序是在 ASP.Net 中编写的,但我假设它们将能够使用 solrnet 来使用 Solr 服务器。

Our product consists of multiple applications, All using Lucene. 2 of the applications I am involved with have Lucene indexes of about 3 Gb and 12 Gb. Another team is building an application, for which they estimate the LUCENE INDEX size to be close to 1 Terabyte. New documents are added to the indexes every 15 days approx. We do not have any apparent performance issues with the current applications. So my question is:

Should we be using Solr now?

When should one stop using Lucene and graduate to Solr?

Any disadvantages/problems for using Solr?

The client applications are made in ASP.Net, but I assume they will be able to use a Solr server using solrnet.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

最舍不得你 2024-09-07 10:11:30

我不认为从 Lucene 迁移到 Solr 本身就是“毕业”。您应该只使用最适合您的特定应用程序的方法,同时考虑开发团队的专业知识。

迁移到 Solr 确实具有易于分发的优点,如果您需要的话。 OTOH 如果您可以在一台机器中容纳 1TB 索引而不会出现性能问题,那么您就不需要分发。我不建议分发,除非您不得不。分布式意味着您必须维护N台 Solr 服务器,而不是仅仅一台,因此运营维护费用会增加。以编程方式(在.Net应用程序中)应该没有太大区别。

Solr 是一种包含电池的独立 Lucene,实现诸如 faceting、< a href="http://wiki.apache.org/solr/SolrCaching" rel="nofollow noreferrer">缓存, 拼写检查...话又说回来,如果您不需要这些功能并且您的团队已经精通 Lucene(.net),那么就坚持使用 Lucene。

I don't think moving from Lucene to Solr is in itself a "graduation". You should just use whatever works best for your particular application, at the same time taking into account the expertise of the dev team.

Moving to Solr does have the advantage of being easily distributed, shall you need it. OTOH if you can fit the 1TB index in a single machine without performance issues, then you don't need to distribute. I don't recommend distributing unless you have to. Distribution means you'll have to maintain N Solr servers instead of just one, so the operational upkeep goes up. Programatically (in the .Net app) there shouldn't be much difference.

Solr is kind of a batteries-included, stand-alone Lucene, implementing features like faceting, caching, spell checking... then again, if you don't need these features and your team is already proficient with Lucene(.net) then stick to Lucene.

仅此而已 2024-09-07 10:11:30

Solr 使用类似 REST 的接口包装 Lucene 索引。您拥有使用 HTTP 方法添加、查询和管理索引所需的一切。因此,如果您需要在网络上访问 Lucene 索引,那么使用 Solr 是自然的选择。

也许我看到的一个缺点是 Lucene 索引通常完全嵌入到您的应用程序中,而 Solr 实例将在单独的进程上运行。如果您不需要 Solr 提供的功能,它可能会增加您的应用程序的复杂性。

Solr wraps your Lucene index with a REST-like interface. You have everything needed to add to, query and administer your index with HTTP methods. So if you need to access your Lucene index on the web, using Solr is the natural way to go.

Maybe a disadvantage I could see is that a Lucene index is usually completely embedded within your application, while a Solr instance will run on a separate process. It could add complexity to your app if you don't need what Solr has to offer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文