最近一直在思考搜索是什么？ 可以总结不同的场景搜索的策略不同

场景一： 数据不经常变化 关键词有规律  

可以考虑采用缓存进行处理（mc redis ...） 如果数据量大的话需要考虑分布式处理，可能采取的方式hash 

场景二：一次请求需要查询多张表

     这时候我们需要考虑跨表查询改成单表查询，还要增加上索引的优化，

     之前遇到的机票搜索就在应用层面做了优化，一次报价搜索来源不同的代理商报价数据，我们发现用户的搜索只是北京-上海-日期这种格式，所以只要保证数据在一张表就可以了，我们增加了搜索库，保证搜索和代理商后台管理是隔离的，之后采用路由的方式同步到搜索库，数据同步方式基于canal实现，同时需要考虑冷热数据，路由表维护了这个关系（通过统计数据进行确定）。

场景三：典型的电商搜索 关键词搜索

 如果是数据库必须使用like 用了like  索引无效那么索引的优势 数据库的查询的性能就不能发挥到极致 那么通过数据库搜索就行不通  

 之前接触过lucence（全文检索利器 基于倒排索引），可以很好的完成全文检索，但是当时仅限单机使用；

后来接触了elasticsearch，发现可以用于分布式环境下的全文检索，继续思考没有elasticsearch的时候，电商平台怎么做的搜索？或者说这背后需要什么支撑？

最近看到1号店的双11的技术分享，仔细阅读完，自己认为的核心点：索引的存储、shard(分片)、route（路由）  

先解释分片和路由：

      不可能把所有商品信息存储在一个索引文件，想到的处理方式就是分片（大问题转化为小问题），分片之后需要考虑的路由，为什么这么说？你查询关键词 “苹果”  可能会出现在手机分类下，也可能出现在水果分类下，怎么分的就怎么合并。这就是路由的目的，路由策略需要减少查询分片的数量，这样才能提高查询性能。如何才能减少查询的分片数目？如果用户在指定分类下进行搜索，对应的分片数目也就减少和确定了；用户可能更习惯简单在搜索框中输入关键词，分类减少分片数目这种方式不可取（你不确定用户需要手机还是水果），这种情况我们就必须查询所有的分片，如果这样查询性能就出现了瓶颈，或者不可用，如何解决？我们可以通过搜索结果和用户习惯进行分析，用户会翻阅10页之后的结果吗？答案是基本不会  那么我们可以基于返回的数据只取前5页的内容统计分片来源，之后将该关键词和分片进行绑定，并维护起来，下个用户再搜索的时候就直接走这个路由规则。关键词和分片的关系设计成缓存，商品信息变化，失效之后需要重新维护关键词和分片的关系。

解释一下索引的存储：

      存储需要考虑扩展性和稳定性，分布式存储系统比较合适（eg：Hadoop）

有新的想法到时候再补充