电子商务系统的搜索引擎优化(2019独角兽企业重金招聘Python工程师标准(gt;gt))

　　电子商务系统的搜索引擎优化(2019独角兽企业重金招聘Python工程师标准(gt;gt))

　　2019独角兽企业招聘Python工程师标准>>>

　　

　　基于 Lucene 的搜索方案

　　一、Lucene 简介

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

　　C#版本的lucene是从java的lucene翻译过来的，也被apache列为开源项目。

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

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

　　

　　具体流程如下：

　　

　　数据流图如下：

　　

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

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

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

　　大致划分，目前与数据挖掘和推荐引擎相关的开源项目主要包括以下几类：

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

　　文本挖掘相关：主要包括OpenNLP、LingPipe、FreeLing、GATE、Carrot2等。详情请参考LingPipe的比赛

　　推荐引擎相关：主要包括Apache Mahout、Duine框架、奇异值分解（SVD），其他包可以参考Open Source Collaborative Filtering Written in Java

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

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

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

　　以上大部分包或算法，除了 Lucene/Sor 都比较成熟，大部分还在学术研究中使用，不能直接应用于互联网规模的数据挖掘和推荐引擎。

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

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

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

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

　　1），Lucene进入门槛低，网站站点搜索大多使用Lucene

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

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

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

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

　　Lucene擅长Text Mining，在contrib包中提供了MoreLikeThis功能，可以更容易实现Content-Based推荐，但是对于涉及用户协同过滤行为的结果（即所谓的Relevance Feedback），Lucene目前还没有一个很好的解决方案。. 需要在Lucene的内容相似度算法中加入用户协同过滤行为对因子，将用户协同过滤行为结果转化为Lucene支持的模型。

　　推荐引擎的数据源

　　电子商务网站与推荐引擎相关的典型行为：

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

　　浏览此商品的顾客也曾浏览了

　　浏览更多同类产品

　　喜欢此商品的人也喜欢

　　此项目的平均用户评分

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

　　1），内容相似度

　　例如：项目标题、作者/译者/制造商、项目类别、简介、评论、用户标签、系统标签

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

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

　　5、实施计划

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

　　5.2、用户协同行为的处理

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

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

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

　　3），评分、采集、点击等协作行为用产品特征值（标签、标题、摘要信息）来表示。

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

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

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

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

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

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

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

　　,

　　三、移动之家的搜索解决方案（供参考）

　　目前Mobile Home的Lucene应用采用Lucene2.4.1+JDK1.6(64位)的组合，运行在8个CPU和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的Cache。根据我们的经验（Ginkgo Search），我们还可以在应用程序中提供 Cache for Document ，这将大大提高性能。Lucene 自己似乎也注意到了这个问题，在 2.4 版本中提供了 Cache，并提供了 LRU Cache 的实现。但是根据我们的测试，在极端情况下，这个Cache可能会突破大小限制，一路扩展，最后吃光内存，甚至网上找到的很多LRU Cache实现在极端情况下都可能出现这样的问题，最后自己写我自己创建了一个LRU Cache，修改了很多次。

　　在编写Java服务程序时，记得设置退出钩子函数（RunTime.getRunTime.addShutdownHook）是一个非常好的习惯。很多Java程序员没有这个意识，或者只是写了一个finalize函数。因此，当程序异常退出时，可能会导致一些外部资源的状态不稳定。以 Lucene 为例，之前的 IndexWriter 默认使用 autoCommit，这样每次添加一条记录，就提交一次。好处是如果中断了，之前添加的记录都可以使用。缺点是分度速度很低。新版本中，autoCommit默认为False，速度明显提升（我们测试的结果快了8倍左右），但如果中途异常退出，那就浪费了。

　　目前的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步骤2关键词统计：

　　搜索关键词的集合和搜索结合处理，实现一个简单的搜索推荐功能。主要是对前台的搜索关键词进行统计分析，并将其与搜索顺序相关联。经过关键词的处理以及与主表关联的索引方案等前期处理，完成一个完整的解决方案。

　　

　　4.3 第三步优化完善：

　　实现基于消息的索引文件增量自动更新、权重计算、推荐商品计算研究、实时搜索研究。权重计算需要重新开发自己的向量算法引擎并考虑。

　　目前正在研究实时搜索。

　　4.3.1重量计算

　　重量计算方法将前端用户的统计数据与产品库关联起来，为天天网产品开发一套重量排序计算方法。下面的算法流程图只是一个想法。

　　

　　重量计算设计

　　4.3.2自动索引更新

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

　　

　　基于消息队列的索引*敏*感*词*