电子商务系统的搜索引擎优化(基于lucene的电子商务搜索架构方案，你准备好了吗？)

　　电子商务系统的搜索引擎优化(基于lucene的电子商务搜索架构方案，你准备好了吗？)

　　说是电商搜索架构方案，其实是一个应用。公司寺院不大，人也很少，所以一般都会去看看。之前做过几个例子，所以被拉起来写一个架构方案。我是一个懒惰的人，我在互联网上疯狂地采集搜索架构的东西。我暂时没有写代码来做架构。我每天都看别人的博客。结果，花了两周时间才得到一个粗略的草图。不清楚。以后会有详细的计划，现在只能分享我的草图。我希望每个人都会等你。在家里乱搞会很郁闷，效率太低。

　　基于Lucene的搜索解决方案

　　一、Lucene 简介

　　Lucene 是 Apache 的一个顶级开源项目。它是一个由java实现的全文搜索引擎。它可以索引和搜索各种文档格式的全文，包括word和pdf，不包括图形。

　　它是从java的lucene翻译过来的C#版本的lucene，也被apache列为开源项目。功能与java基本相同。但由于缺乏良好的技术支持和社区活动，被apache放入孵化器。

　　Lucene写入：分析器对源文件进行处理，包括分词、权重处理、生成文档记录、写入存储（硬盘或内存）。

　　Lucene读出：对搜索关键词进行分析器处理，包括分词、权重、范围匹配处理。源码*敏*感*词*如下：

　　

　　具体流程如下：

　　

　　数据流图如下：

　　

　　二、常用推荐引擎算法问题

　　使用基于数据挖掘的算法实现推荐引擎是各大电商网站和SNS社区最常用的方法。推荐引擎通常使用基于内容的推荐算法和协同过滤算法（Item-Based、User-based）。但从实际应用来看，对于大多数中小企业来说，在电子商务系统中完全采用上述算法还是非常困难的。

　　1），比较成熟，完整，现成的开源方案很少

　　粗略地说，目前数据挖掘和推荐引擎相关的开源项目主要分为以下几类：

　　数据挖掘相关：主要包括Weka、R-Project、Knime、RapidMiner、Orange等。

　　文本挖掘相关：主要包括OpenNLP、LingPipe、FreeLing、GATE、Carrot2等，详见LingPipe竞赛

　　推荐引擎相关：主要包括Apache Mahout、Duine框架、奇异值分解（SVD），其他包可以参考Java开源协同过滤

　　搜索引擎相关：Lucene、Solr、Sphinx、Hibernate Search等。

　　2），常用的推荐引擎算法比较复杂，入门门槛高

　　3），常用推荐引擎算法性能低，不适合海量数据挖掘

　　除相对成熟的Lucene/Sor外，以上大部分包或算法仍处于学术研究阶段，不能直接应用于互联网规模的数据挖掘和推荐引擎引擎的使用。

　　（以上都是基于java的，需要自己学习实现，难度很大）

　　注意：除了分类搜索和主动搜索，推荐系统也是用户浏览产品的重要方式。它可以帮助用户找到相似和感兴趣的产品，增加产品的访问量，将访问者转化为购买者，引导用户购买。最终价值在于提升用户的购物体验和用户粘性，增加订单量。例如，亚马逊 30% 的订单来自推荐系统。

　　使用Lucene实现推荐引擎的优势

　　对于很多中小网站来说，由于开发能力有限，如果有搜索推荐一体化的解决方案，这样的解决方案肯定会大受欢迎。使用Lucene实现推荐引擎有以下优点：

　　1），Lucene入门门槛低，网站网站搜索大部分使用Lucene

　　2），Lucene相比协同过滤算法有更高的性能

　　3），Lucene对于Text Mining、相似度计算等相关算法有很多现成的解决方案

　　在开源项目中，Mahout或者Duine Framework是比较完善的推荐引擎解决方案，尤其是Mahout核心使用了Lucene，所以其架构值得学习。只是Mahout目前的功能还不是很完善，直接用它实现电子商务的推荐引擎网站还不是很成熟。只是从Mahout的实现可以看出，使用Lucene来实现推荐引擎是一个可行的方案。

　　3、使用Lucene实现推荐引擎需要解决的核心问题

　　Lucene 擅长文本挖掘。它在 contrib 包中提供了 MoreLikeThis 函数，这使得实现基于内容的推荐变得更加容易。但是对于涉及用户协同过滤行为的结果（所谓的Relevance Feedback），Lucene目前还没有很好的解决方案。. 需要在Lucene中的内容相似度算法中加入用户协同过滤行为对因子，将用户协同过滤行为结果转化为Lucene支持的模型。

　　推荐引擎数据来源

　　电商网站推荐引擎相关典型行为：

　　购买该产品的顾客还购买了

　　查看此产品的客户还查看了

　　浏览更多同类产品

　　喜欢该产品的人也喜欢

　　用户对该产品的平均评价

　　所以基于Lucene的推荐引擎的实现主要处理以下两类数据

　　1），内容相似度

　　例如：产品名称、作者/译者/制造商、产品类别、介绍、评论、用户标签、系统标签

　　2），用户协同行为相似度

　　例如：标记、购买产品、点击流、搜索、推荐、采集、评分、撰写评论、问答、页面停留时间、群组等。

　　5、实现计划

　　5.1、 基于Lucene MoreLikeThis可以实现内容相似度。

　　5.2、 用户协作行为的处理

　　1），用户使用lucene对每一个协作行为进行索引，每一个行为都有一个记录

　　2），索引记录收录以下重要信息：

　　产品名称、产品id、产品类别、产品介绍、标签等重要特征值、其他产品特征元素的用户相关行为、产品缩略图地址、协同行为类型（购买、点击、采集、评分等）、Boost value ( setBoost 中每个合作行为的权重值)

　　3）。评分、采集、点击等合作行为以产品特征值（标签、标题、摘要信息）为特征

　　4），不同类型的协同行为（如购买、评分、点击）设置不同的值setBoost

　　5）, Lucene MoreLike 这个算法在搜索时使用，将用户协作转化为内容相似度

　　以上方案只是基于Lucene实现推荐引擎的最简单的实现方案。方案的准确性和详细方案将在后面详细讨论。

　　更精细的实现可以参考Mahout的算法实现进行优化。

　　其他搜索引擎开源工具推荐：Sphinx，目前基于*敏*感*词*开源全文搜索引擎软件Sphinx，单个索引最多可收录1亿条记录，1000万条记录情况下的查询速度0.x 秒（毫秒级）。Sphinx创建索引的速度是：创建一个100万条记录的索引只需要3到4分钟，50分钟就可以创建一个1000万条记录的索引，增量索引只收录最新的10万条记录重建一次。只需要几十秒。

　　Sphinx 是根据 GPL 2 协议发布的免费开源全文搜索引擎。它专为更好地集成脚本语言和 SQL 数据库而设计。当前内置的数据源支持直接访问连接到它的 MySQL 或 PostgreSQL 的数据。或者可以使用XML管道机制（XML管道机制，一种基于Sphinx识别的特殊xml格式的索引通道）

　　基于LAMP架构的应用非常广泛，目前已知的商业应用是康盛的Discuz企业版。

　　,

　　三、手机首页搜索计划（供参考）

　　目前手机之家的Lucene应用采用Lucene2.4.1+JDK1.6（64位）的组合，运行在一台8CPU、32G内存的机器上，数据体积超过3300万，原创数据文件超过14G，每天需要支持超过35万次查询，高峰期QPS超过20。单看这些数据可能不是什么大亮点，但它的重构和更新都是自动完成的，两个任务可以同时运行。另一方面，在不影响服务可靠性的情况下，尽可能快地更新数据。（如果两者有冲突，优先保证可用性，延迟更新），工作量还是很大的。

　　PPT连接

　　在*敏*感*词*应用中，Lucene 更适合狭义的“搜索”，不应该负责数据存储。如果我们查看Lucene的源码，也可以知道Document和Field的存储效率不够好。移动之家团队也发现了这一点。他们的方法是使用Lucene存储索引，使用Memcache + Berkeley DB（Java版）进行存储。这有两个优点。一是减少Lucene的数据量，提高程序效率；另一方面，该系统还可以提供一些类似SQL的查询功能。其实Lucene本身似乎也注意到了这个问题，在Store中增加了一个db选项，其实就是Berkeley DB。

　　在大型应用中，Cache 非常重要。PPT中还提到，在程序提供服务之前，可以进行多次“预热”搜索来填充Searcher's Cache。根据我们（Ginkgo Search）的经验，我们还可以在应用中提供Document-specific Cache，这将大大提高性能。Lucene 似乎已经注意到了这个问题。2.版本4中提供了Cache，并提供了LRU Cache的实现。但是根据我们的测试，在极端情况下，这个Cache可能会突破大小限制，一路膨胀，最后吃光内存，甚至网上找到的很多LRU Cache实现在极端情况下都可能出现这样的问题，而且最后自己写。一个LRU Cache经过多次修改修改，

　　在编写Java服务程序时，记得设置退出钩子函数（RunTime.getRunTime.addShutdownHook）是一个非常好的习惯。很多Java程序员没有这种意识，或者有，只是写了一个finalize函数。因此，当程序异常退出时，一些外部资源的状态可能会变得不稳定。以Lucene为例。前面的IndexWriter默认是autoCommit，所以每增加一条记录，就提交一次。优点是如果中断，之前添加的记录可用。缺点是索引速度非常低。新版本中autoCommit默认为False，速度有明显提升（我们测试的结果是提升了8倍左右），但是如果中途异常退出，之前的所有努力都将付诸东流。如果我们添加一个退出钩子函数，在捕获到退出信号时自动调用writer.close()方法，就可以避免这个问题。

　　目前的Lucene兼容JDK1.4，其二进制版本也是JDK1.4编译的。如果对性能有较高要求，可以自行下载Lucene Source Code，用较新版本的JDK编译。.jar 文件，根据我的测试，速度提升了 30% 左右。

　　四、XX网络搜索解决方案4.1 初步解决方案：

　　实现分词搜索、推荐关键词和站内商品的简单排序，定时自动更新，索引读写分离。

　　基于服务器的搜索压力大，用户搜索体验不够好。初步解决目标是解决服务器的搜索压力，实现初步的分词搜索，以及索引的自动定期维护。

　　4.1.1数据库产品表分析：

　　l 大类基表

　　l 产品分类扩展基表

　　l 品牌基台、品牌系列台基台

　　l 产品基表（主表）

　　l 色基表

　　产品基表数据量约8万条，占用空间约40m，单表数据量较小。

　　4.1.2 Lucene索引程序：

　　通过lucene索引程序将库中的数据读入流中，然后写入lucene自定义索引文件中。该索引文件不进行搜索操作，完成后需要替换为搜索索引。分词过程是在索引过程中进行的。分词组件采用eaglet开发的盘古分词组件（基于apache开源协议开源，更*敏*感*词*需要自行开发）。

　　4.1.3 Lucene 索引库：

　　基表的索引文件约100m。它分为写作库和搜索库。写入完成后，将其合并到搜索库中。考虑到在新索引被覆盖的瞬间可能发生的索引程序错误，或者索引文件被破坏，在覆盖的同时，搜索程序可以通过程序控制对索引中的文件进行读写。

　　l 搜索处理服务：基于产品库进行搜索，如品牌、品类、价格区间等。搜索程序依赖界面，数据库搜索和文件搜索需要随时切换。搜索时需要使用分词组件进行分词处理来搜索分词后的结果，数据库搜索暂时不进行分词处理。

　　l 查询处理：使用mvc查询前台程序，实现产品分词、分类查询、品牌分类、价格区间查询的高亮显示。

　　

　　4.2第二步关键词统计：

　　搜索关键词的集合和搜索的联合处理，实现简单的搜索推荐功能。主要目的是对前台的搜索关键词进行统计分析，并与搜索排序相关联。在关键词的处理以及与主表关联的索引方案的初步处理完成后，就可以做出完整的解决方案了。

　　

　　4.3 第三步优化完善：

　　实现索引文件的信息化增量自动更新、权重计算、推荐产品计算研究、实时搜索研究。权重计算需要重新开发自己的矢量算法引擎，正在考虑中。

　　实时搜索目前正在学习中。

　　4.3.1 权重计算

　　权重计算方法将前端用户的统计数据与产品库关联起来，开发了天天网产品的权重排名计算方法。下面的算法流程图只是一个概念。

　　

　　重量计算设计

　　4.3.2 索引自动更新

　　建立基于消息机制的索引更新维护机制。

　　

　　基于消息队列的索引生成程序

　　转载于：