关于sap:SAP-Commerce-Cloud-里的-Solr-架构简介

1次阅读

共计 1368 个字符,预计需要花费 4 分钟才能阅读完成。

大多数电子商务网站都在其网站上提供搜寻性能,尤其是用于搜寻产品详细信息。

产品是任何电子商务网站中的次要搜寻数据。

因为 Hybris 用于开发电子商务网站,因而 Hybris 中的 Solr 用于更快地搜寻网站中的产品。

请看下图,理解如何在 Hybris 中应用 Solr:

Hybris 中的 Solr 概述

每当用户拜访店面中的任何数据时,它能够来自 hybris DB 或 Solr,具体取决于该数据是否已编入索引。

如果数据被索引,它将独自存储在 Solr 中,并且能够从那里拜访。

如果数据未编入索引,则无论如何它都能够在 Hybris DB 中应用并且能够从那里拜访。

Solr 和 Hybris DB 之间的通信是一种形式,因为 Solr 只从 Hybris DB 获取数据,但不会将任何内容写回 Hybris DB。

Hybris 调用 Cron 作业进行索引,而后 Solr 从 Hybris DB 获取源数据,而后进行索引并将索引数据保留在其中。

请记住:因为 Solr 中的索引数据,
从 Hybris DB 拜访数据将比从 Solr 拜访数据破费更多的工夫,因而 Solr 在搜寻中比 Hybris DB 更受欢迎。

hybris 中的 Solr 反对 3 种索引策略

1) 全索引

2)更新索引

3) 删除索引

1) 全索引:

在此策略中,将首先删除所有现有索引文档,而后从头开始创立新索引。
这须要相当长的工夫,所以不倡议常常这样做。

残缺索引反对 2 种提交模式

a) 间接模式
在此模式下,如果索引失败,则先前提交的文档将可用。

b) 两阶段模式
在这种模式下,如果索引失败,所有都会回滚到初始状态。

在这种模式下,Solr 创立一个额定的外围作为长期外围,仅用于索引,一旦索引胜利,它将与原始外围替换。
因而,如果索引失败,原始外围将是平安的。

之所以称为两阶段模式,次要是因为它在索引时波及 2 个 Solr 内核。

初始外围作为备份保留,另一个外围作为正本创立,
将在此正本上执行索引,如果索引胜利,稍后将与原始外围替换。

2)更新索引:
在这个策略中,只有那些在给定工夫内被批改的文档才会被索引,其余被索引的文档放弃原样。如果须要,能够常常执行此操作,因为与残缺索引策略相比,它耗费的工夫更少

3)删除索引:

此策略用于齐全删除索引文档。
应该定期执行此操作以放弃索引数据的一致性,因为咱们可能在 Solr 中长期存在不须要的索引数据。

家喻户晓,通过 impex 执行是最好的办法,因为它能够在所有环境(DEV、TEST、PROD)中继续很长时间并且可重用,
咱们只须要相应地在 impex 文件中定义 Solr 配置即可。

产品我的项目类型的索引已由 Hybris 开箱即用。
因而,如果咱们向 Product 我的项目类型增加任何新属性,并且咱们心愿对这些新属性进行索引,那么咱们须要在 solr impex 文件中增加这些新属性。

咱们能够在 solr impex 文件中定义查问以从 hybris DB 获取数据以进行索引,咱们还须要在 Solr impex 文件中定义字段形容。

Hybris 的长处在于,它曾经提供了用于执行残缺索引、更新索引和删除索引的 cron 作业。

咱们在 SAP Hybris Backoffice 里查看每个 site 对应的 index:

每种索引能够调配 catalog,货币和语言:

索引类型:

其中 update cronjob 被调度成每隔 1 分钟执行一次,以确保 index 和 DB 数据始终保持统一。

更多 Jerry 的原创文章,尽在:” 汪子熙 ”:

正文完
 0