随便写写

简单讲讲垂搜网站的检索系统，检索系统需要满足从海量的数据中去获取最符合用户需求的数据返回给网民，这就是检索系统，所以一般的检索系统基本上会涉及到数据的组织，数据的查询规则，数据的实时排序等等因素，结合之前的项目，说说我自己是怎么做的；

之前做的一个精确检索采用的是空间换时间，考虑到团购会影响的因素主要包括：已购词、品类、地域、品牌、商家等因素，所以在处理这个问题的时候，精确匹配实际上是采取了自己圈定一批词，这批词能够确定之前这些选项，如“便宜的耐克鞋”事先会对这个词进行标注，“运动”、“耐克”会体现解析出来，地域信息也会根据ip来进行获取，然后会根据这些信息，直接去查kv表，而kv表，就是一开始客户在上传物料的时候，直接生成对应的链，这样精确检索实际上就是一个分类问题，把物料全都精确的分到具体的类别进去，精确检索就是把客户的需求精确的定位到某一个分类，模糊查询就是把客户的需求定位到某几个分类，然后这些分类进行合并或者取交；

这个系统的好用与否取决于两部分，一部分是物料精确的分到某个分类中，另外一部分是query精确的分到某个分类中，因为检索行为实际上是根据分类来定义的，但是而根据行业词表之前的经验来看，这种做法完全取决于分类的精细程度；微购做了个更复杂的分类系统，以及设计了一个语法来表示分类之间的并和交的问题，但是所有的精确性都取决于分类是否能够精确；为啥这么做，因为业务简单，数据量少，分类也比较明确，所以可以用这种方法来做，如果维度多几个，这样做就很难去做了；

而以我的经验来看，加快性能的几种方法，一种是空间换时间，这是最简单的方法，也就是加机器，一种是在线换离线，把业务相关的全部放在线下做，把在线全部算成kv表，实在不行需要放在线上的，比如实时个性化推荐，这种要根据之前一个session的内容出推荐结果，线上也只能做最简单的合并求交操作，还有一种就是写代码的水平，在大部分的业务中，写代码的水平不是核心问题，但是一旦要考虑到性能这种case,写代码就成为最核心的问题了，所有的问题最后都归咎为写代码，再好的架构，如果写代码的比较挫，也不行；回想这么多年来自己的写代码水平，哎，也就勉强算个一般般，能钻个细节，但是复杂的acm就搞不定了。。。或者5页的：

另外一种，精确检索可以衍生为“特征”对应的倒排链，多条倒排链先进行合并，再进行条件过滤后，最后进行排序（个性化和自然各给一部分权重），返回结果，这样得到的实际上就是最重要的结果，如果性能不够，一方面可以直接裁剪（最重要的往往就是前面几页），另外，就用高级一点的数据结构，但是维度越高，在拆库和合并的时候就越复杂，还可以用一张大一点的kv表，一张不够就用两层，一层kv再查一层kv,总是能解决问题的；