您现在的位置：首页 --> 查看专题： 搜索
一直以来，为了优化本博客站内搜索效果和速度，我使用 bing 的 site: 站内搜索做为数据源，在服务端获取、解析、处理并缓存搜索结果，直接输出 HTML。这个方案唯一的问题是时效性难以保证，尽管我可以在发布和修改文章时主动告诉 bing，但它什么时候更新索引则完全不受我控制。
本着不折腾就浑身不自在的原则，我最终还是使用 Elasticsearch 搭建了自己的搜索服务。Elasticsearch 是一个基于 Lucene 构建的开源、分布式、RESTful 搜索引擎，很多大公司都在用，程序员的好伙伴 Github 的搜索也用的是它。本文记录我使用 Elasticsearch 搭建站内搜索的过程，目前支持中文分词、同义词、标题匹配优先、近期文章优先等常见策略。
笔者最早接触的是Condor/HTCondor，搞过网格计算的同学应该比较了解；Goolge的Borg应该算是一开始借鉴了很多Condor的东西，Omega则是在解决borg的单master调度的瓶颈问题；Tencent的Tborg/Torca则是和Borg系统有很深的渊源；Yarn和Mesos应该是被更多的人所熟知，都支持多种计算框架；对AutoPilot的认知更多来自于相关的论文；Baidu的系统其实蛮有意思，特别是IDLE（有个组件可以随意种植在任何机器上，当机器空闲的时候则调度一些低优先级并且可以随时K掉的计算任务上去执行，而且他们的PE人员身背机器利用率的KPI，大家都求着调度任务上去，这和咱们的现状完全是两样）；FUXI和T4是集团内的系统，大家想要了解可以在内网找到他们。
SKU，Stock Keeping Unit，库存单元，是商品库存的最小单位。通俗的讲，一种商品可能有各种规格的货，每一种货就是一个SKU。搜索引擎是以商品作为检索单位，没法提供更细粒度（SKU粒度）的检索功能。于是，为了提升用户的搜索体验，为了把搜索做得更好，搜索引擎需要支持SKU粒度的检索。
多年以来，主搜索的集群架构和排序算法相对比较单一，一定程度上制约了搜索业务的发展。本文主要介绍主搜索最新采用的索引分层技术。这种分层技术把主搜索集群架构从二维扩展到了三维。基于这种三维的新架构，主搜索可以根据不同的应用场景，选择不同的检索和排序算法，从而更好的提升主搜索的检索性能与检索效果。实践表明，这种分层技术能提升主搜索120%的检索性能和6%的搜索GMV。
我们非常高兴用 Elasticsearch 来保存我们的事件，也得到了试用新 API 和新控制面板中新日志页面的客户们非常积极的反馈。任意字段的可搜索对日志挖掘绝对是一种显著的改善，而 Elasticsearch 正提供了这种高效无痛的改进。当然，Logstash，Elasticsearch 和 Kibana 这整条工具链也非常适合内部应用日志处理。
本文将继续围绕Solr+Lucene使用Cartesian Tiers 笛卡尔层和GeoHash的构建索引和查询的细节进行介绍。
在Solr中其实支持很多默认距离函数，但是基于坐标构建索引和查询的主要会基于2种方案：
(1)GeoHash；
(2)Cartesian Tiers+GeoHash；
而这块的源码实现都在lucene-spatial.jar中可以找到。接下来我将根据这2种方案展开关于构建索引和查询细节进行阐述，都是代码分析，感兴趣的看官可以继续往下看。
在Solr中基于空间地址查询主要围绕2个概念实现： Cartesian 、Tiers 、笛卡尔层。 Cartesian Tiers是通过将一个平面地图的根据设定的层次数，将每层的分解成若干个网格。
排序中我们需要解决的是什么样的问题？怎么样把用户想要的，好的商品排到前面；怎样调节不同卖家的流量；给质量好，但价格不便宜的商品更多的流量，来引导市场更加规范。需要解决的问题很复杂，但是排序结果好坏难以评判。
一淘第一版的产品搜，有一个关键模块叫PS Server，它的位置就是今天AGG的位置。它有一个AGG今天没有的职能，就是访问产品搜自己的Forest，负责翻译产品搜的类目属性信息。为什么是自己的Forest？因为一淘产品库为了快速迭代，从淘宝SPU库中脱离出来，类目用的是淘宝的后台类目，但SPU的pid/vid是完全独立的一套数据，这么做有利有弊，因此欠下的债我们早晚也要还的。
为了提高检索系统查询处理能力,我们提出基于用户群体行为分析的搜索引擎自动评价方法.该方法利用搜索引擎用户查询、点击行为的宏观分析,自动挑选适用于搜索引擎评价的查询集合,并进一步自动定位对应这些查询的标准答案.由于挑选查询集合和标准答案的过程由计算机自动完成,因此可以及时、准确、客观地反映搜索引擎的真实性能.
当大家都在关注搜索的速度的时候，往往伴随业务的快速发展，数据服务质量成为了实时搜索或者垂直搜索中的新问题。实时搜索和垂直搜索是不一样的问题，下面的问题就是垂直场景下得实时搜索问题。也可以理解垂直搜索都不实时，其他的实时先排队吧。问题比较抽象，只谈总体上的现象，对于具体如何解绝问题的细节，不做说明。有些不具有通用性，有些和场景相关，很难有最佳方式，不代表没有解决方法。首先是有问题意识，然后自然有解决方法。 问题： (1)个性化排序 伴随业务发展需要，同时细分用户群体，为了最大程度优化服务质量、满足更大群体的具体业务场景，个性化的排序越来越引起高度重视。传统的文本相关性只是第一维的参考，针对业务多维度综合得分的二维排序最终影响排序。而一个平台上面临的服务群体、服务场景多种多样，有行业属性、地域属性、技术属性、运营属性等，很难完全统一，完全归一化到一个计算公式中去。
Spider位于搜索引擎数据流的最上游，负责将互联网上的资源采集到本地，提供给后续检索使用，是搜索引擎的最主要数据来源之一。spider系统的目标就是发现并抓取互联网中一切有价值的网页，为达到这个目标，首先就是发现有价值网页的链接，当前spider有多种链接发现机制来尽量快而全的发现资源链接，本文主要描述其中一种针对特定索引页的链接补全机制，并给出对这种特定类型的索引页面的建议处理规范用于优化收录效果。
跨语言信息检索，是信息检索领域中的一个研究课题。近10几年来，由于互联网的飞速发展，这方面的研究受到了学术界的广泛重视。将这项技术应用于搜索，可以帮助我们查找到更多的有用信息，例如外语相关页面、多语言页面以及语言无关的资源（如图片）等等。这些信息可以大大丰富搜索的结果，满足用户多样的需求。在跨语言信息检索的研究中，有一些研究成果已经趋于成熟，达到可以应用的状态。事实上，Yahoo和Google在5，6年前就已经开始提供多语言的搜索服务。毫无疑问，在这方面他们已经走在了世界的前列。目前，百度的各项国际化业务正在如火如荼的开展，对跨语言技术来说，正是用武之地。相信不久的将来，它将会在搜索国际化进程中扮演举足轻重的角色。来，就让我们一探究竟吧。
百度的搜索URL存在着一定的规律和逻辑，下面的链接是我使用百度搜索“标点符”后得到的链接，下面就来一起分析下百度搜索结果URL的秘密。
摘要：两篇文档是否相关往往不只决定于字面上的词语重复，还取决于文字背后的语义关联。对语义关联的挖掘，可以让我们的搜索更加智能化。本文着重介绍了一个语义挖掘的利器：主题模型。主题模型是对文字隐含主题进行建模的方法。它克服了传统信息检索中文档相似度计算方法的缺点，并且能够在海量互联网数据中自动寻找出文字间的语义主题。近些年来各大互联网公司都开始了这方面的探索和尝试。就让我们看一下究竟吧。
近3天十大热文
-
[56] IOS安全–浅谈关于IOS加固的几种方法 -
[55] Oracle MTS模式下 进程地址与会话信
-
[54] 图书馆的世界纪录
-
[54] android 开发入门
-
[52] 如何拿下简短的域名
-
[51] Go Reflect 性能
-
[50] 【社会化设计】自我（self）部分――欢迎区
-
[47] 读书笔记-壹百度:百度十年千倍的29条法则
-
[39] 程序员技术练级攻略
-
[34] 视觉调整－设计师 vs. 逻辑
赞助商广告
