CM开发日志 - 搜索引擎（三）

最新推荐文章于 2024-09-27 11:12:40 发布

Jeff~

最新推荐文章于 2024-09-27 11:12:40 发布

阅读量1.4k

点赞数 2

分类专栏： Cloud Marketplace开发日志文章标签：电子商务 solr 搜索引擎索引 websphere

本文链接：https://blog.csdn.net/alli0968/article/details/42342353

版权

Cloud Marketplace开发日志专栏收录该内容

8 篇文章 1 订阅

订阅专栏

到了这篇博文，对于solr的整个生命周期，希望各位要有个初步的认识（以便能抓住整个系列文章的脉络）。

我用自己的话总结为以下： solr 多核创建 -> 索引的预处理 -> 索引的创建和持久化 -> 索引的调用（Search API与索引文件的交互）

不对的地方希望大家指正。另外，最近在查一些关于Solr里面比较深入具体的资料的时候，发现网上的很多资料要么是简单的相互拷贝，要么就是英文资料。总是感觉不那么得心应手之余，有些东西自己还是得去看solr wiki或者查看源代码。也希望自己的一点小小的研究，能给学习应用solr，lucene或者WCS的朋友们一点小小的参考。另外，对互联网和电子商务比较感兴趣的朋友也能对电子商务网站的开发过程有个大致的了解。

回到正文，上篇博文介绍了基于WCS的Solr 多核的创建。创建solr多核的Utility执行全过程不用太过关注，毕竟是框架封装的一套逻辑，透过现象看本质才是重中之重！我觉得solr 多核的重点还是概念的理解：即根据你的网站系统后台数据的类型和特点，来创建出合适的solr核。

例如在WCS的网站系统里，后台有各种各样繁杂的数据，但是我们能够根据数据的应用场景来划分他们：

- 是属于商品、用户、订单、库存等本身的数据，我们叫实体数据，这个大类又可以分为两个小类

- 属于实体本身的，比如咖啡机有名称，生产厂商，性能，价格等，这些叫structured数据

- 属于实体附加的，还是拿咖啡机举例，咖啡机附加的有产品使用手册，保单信息等，这些叫unstructured数据

- 用于分类目的的我们叫分类数据

综上，我们把WCS后台繁杂的数据大体上分为了3类，即structured 实体数据，unstructured实体数据 以及分类数据。

以上是再次对solr多核的总结，下面进入下一环：索引预处理

索引预处理

首先，对于原生态的solr，他支持将数据通过xml，csv，json等形式写进solr 内存。这些数据可以有100条，如果你的内存够大，可以是1000条甚至更多。但是，更多的应用场景是通过配置文件直接读取数据库建立索引。读取数据库并创建临时表的过程，这就是索引的预处理。

我们首先理解一下什么是索引，然后就自然明白什么是索引的预处理了。

索引，我的理解就是：

1. 首先他是文件（一个或多个）

2. 这些文件相当于数据库表，只是索引的字段叫域（field），根据数据库表字段映射相应的域（field）。

3. 对应好了之后，索引文件就像一个数据库表一样：他只有一个主键，有很多字段。我们能够只通过这个主键来查找到我们想要的信息，于是免去了左外连接一个个查数据库表的过程。

举个例子，我们的网站商品有品牌信息，品牌信息表又跟商品主表有外键的关联。

那么为了创建关于品牌的索引，我们首先要有一张临时表TI_BRANDS，里面定义了我们需要索引的信息，比如商品ID，名称，名称首字母等。

其次，我们得把自己需要索引的数据库字段整理出来（通过left join 主表的方式），这样我们就拥有了我们需要的字段信息，并且将其全部存于临时表TI_BRANDS里面。

在WCS里面，创建TI临时表的过程就叫做索引预处理。

另附WCS索引预处理配置文件wc-dataimport-preprocess-brands.xml

<?xml version="1.0" encoding="UTF-8"?>

<_config:DIHPreProcessConfig xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/config ../../xsd/wc-dataimport-preprocess.xsd ">         
  <!-- get catalog ids for catentry -->
  <_config:data-processing-config processor="com.ibm.commerce.foundation.dataimport.preprocess.BootsStaticBrandsDataPreProcessor" batchSize="500">	
	<_config:table definition="CREATE TABLE TI_BRANDS(
		BDC_BRAND_ID NUMBER,
		BDC_BRAND_NAME VARCHAR2(255 BYTE),
		BRAND_NAME_FIRST_CHAR VARCHAR2(255 BYTE),
		PREMIUM_BRAND_FLAG VARCHAR2(255 BYTE),
		BRAND_TREATMENT_FLAG VARCHAR2(255 BYTE),
		DISPLAY_FLAG VARCHAR2(255 BYTE),
		BRAND_ROOM_URL VARCHAR2(255 BYTE),
		BRAND_TREATMENT_URL VARCHAR2(255 BYTE),
		PRIMARY KEY (BDC_BRAND_ID)
	)" name="TI_BRANDS"/>
		
	<_config:query sql="
	select t.brandId AS brandId, t.brandName AS brandName,	
	tib.BRAND_NAME_FIRST_CHAR AS brandNameFirstChar,
	tib.PREMIUM_BRAND_FLAG AS premiumBrandFlag,
	tib.BRAND_TREATMENT_FLAG AS brandTreatmentFlag,
	tib.DISPLAY_FLAG AS displayFlag,
	tib.BRAND_ROOM_URL AS brandRoomUrl,
	tib.BRAND_TREATMENT_URL AS brandTreatmentUrl from 
	(select br.brand_id AS brandId, br.brand_name AS brandName from BDCBRAND br) t 
	left join TI_BRANDS tib on (t.brandId = tib.BDC_BRAND_ID)
	"/>
		
    <_config:mapping>
      <_config:key queryColumn="brandId" tableColumn="BDC_BRAND_ID"/>
      <_config:column-mapping>
        <_config:column-column-mapping>
			<_config:column-column queryColumn="brandName" tableColumn="BDC_BRAND_NAME" />			
			<_config:column-column queryColumn="brandNameFirstChar" tableColumn="BRAND_NAME_FIRST_CHAR" />			
			<_config:column-column queryColumn="premiumBrandFlag" tableColumn="PREMIUM_BRAND_FLAG" />
			<_config:column-column queryColumn="brandTreatmentFlag" tableColumn="BRAND_TREATMENT_FLAG" />
			<_config:column-column queryColumn="displayFlag" tableColumn="DISPLAY_FLAG" />			
			<_config:column-column queryColumn="brandRoomUrl" tableColumn="BRAND_ROOM_URL" />			
			<_config:column-column queryColumn="brandTreatmentUrl" tableColumn="BRAND_TREATMENT_URL" />
        </_config:column-column-mapping>
        </_config:column-mapping>
    </_config:mapping>
  </_config:data-processing-config>
</_config:DIHPreProcessConfig>