这之前：

1、想写这篇文章好久，但一直纠结在搜索引擎具体的手艺原理细节中，看得愈多，不懂的处所也愈多，迟迟不敢脱手，这是不法度猿出世的痛苦。

2、所有人都知道搜索是个复杂的玩意，本文试着主要从非手艺角度思考并搭建一个适用于b2c网站的站内搜索系统，不涉及到太多的手艺细节。至于具体的实现代价这里未做斟酌(是通过简单的sql+缓存弄定、用lucene或Sphinx等全文检索引擎做二次开辟、甚至找谷歌 百度买代码做二次开辟，听你们法度猿的吧，你做不了主)。

3、本文多次提到站内搜索，而非站内搜索引擎，这二者间有巨年夜不同(我不是很确定最终设计出来的是否会是一个真正意义上的站内搜索引擎)。

4、本文参考了较多资料，例举如下，供参考学习

《web信息架构-设计年夜型网站》这本经典书籍(不建议新手采办)

美女西乔的几篇文章http://blog.xiqiao/2009/06/02/343

yeeach 的几篇文章

以及部分关于全文检索的论文

在这之后，我们进入正文

1、在起头斟酌计齐截个b2c站内搜索前，需要斟酌清楚以下2个问题

站内搜索要解决的问题和意义

下面描述2类常见的搜索场景

某用户小李，对网站A已较熟悉，要买电脑，此时知道网站A有电脑销售。直接输入关头词：Thinkpad X系列进行较精准的查询。

某用户小白，听说了b2c网站A，第一次登岸，看见满目琳琅的商品。恰好之前阅读过相似网站，或对目前商品的类目有较全面的认识。想迅速定位脑海中已有的某几种商品。于是输入较宽泛的关头词进行模糊搜索：如输入羊毛外套、全棉T恤等较模糊的关头词。

(1)站内搜索恰好满足这两类用户的需求。

(2)通过阐发用户关头词搜索频次，体会用户的潜在需求。(针对这点，我一直有个想法，若发现年夜量搜索关头词为A的某类商品，而恰巧网站没有。网站为下降风险，是否可以采取预定的体例，先上架与目标关头词A吻合的商品X?)

(3)对网站运营人员，通过阐发用户的关头词搜索日志，能修正商品命名体例，编辑出加倍适适用户认知的命名体例(这里顺便提下一个免费强年夜统计用户站内搜索的东西—谷歌 analytics)

阐发你的网站是否需要站内搜索

实际上现在站内搜索在b2c网站根基是标配，但这里仍然絮聒一下网站是否需要站内搜索，或仅仅是搜索而不引擎?

(1)斟酌网站商品的属性：以标准品、常见商品为内容的站点搜索使用率会高;而较偏门的商品，如绣刺、礼品这类B2C网站，用户对要搜索的关头词认知不敷，年夜部分用户成立不起较清晰的心智模型，搜索使用率会偏低。

(2)斟酌网站可能使用站内搜索用户的绝对数，10万级别UV/日的网站，站内搜索使用用户的数量已经比较可不雅了，需要斟酌他们的需求。

(3)斟酌商品类目数量、品牌数、sku数量，按照一点小小的经验，单品牌sku小于500的服装类网站站内搜索使用率远小于5%。

(4)斟酌客户重购率、采办周期(其实素质是斟酌新客老客的组成)，新客为主的用户，根基是试探性搜索，搜索使用率也偏低。

总结一下：商品偏门、流量不高、sku少、新客为主的站点，站内搜索根基是安排，即便要上站内搜索，亦可简单应付。

这里要提到一点：很多客服常常自己需要用商品款号搜索商品，认为很是需要站内搜索，这不是用户需求，只能说明后端系统没做好。

通过这么几个标准去判断，你会发现某些网站参考淘宝把站内搜索醒目的摆放在网站最中央显眼处是多么愚蠢!

2、斟酌清楚这两个问题后，你决定要上站内搜索了，那么先简单体会搜索引擎的工作机制

以下是搜索引擎的工作机制

爬虫抓取内容——成立(包含新增和删减)索引—贮存索引—查询(用户查询)—–查询阐发—查询成果排序—显现成果

(1)要提到的是，电子商务的信息通过手工录入或其它体例已经导入到了系统，不需要用到爬虫法度。

(2)所谓索引，是指搜索系统对信息进行加工，把信息转换成搜索系统能快速理解并便利查询的过程。要多哪些内容成立索引、对哪些内容的组件进行索引，是下文要探讨的标的目的。

(2)查询阐发，这是最有手艺含量的部分、涉及到搜索引擎的核心算法，对中文全文检索，这里又涉及到所谓的分词手艺。