@JunQiu
2018-09-18T21:16:18.000000Z
字数 1777
阅读 1600
summary_2018/08 algorithm arch
### Dapper设计中的一个例子：比如一个前段服务可能对上百台查询服务器发起了一个Web查询，每一个查询都有自己的Index。这个查询可能会被发送到多个的子系统，这些子系统分别用来处理广告、进行拼写检查或是查找一些像图片、视频或新闻这样的特殊结果。根据每个子系统的查询结果进行筛选，得到最终结果，最后汇总到页面上。我们把这种搜索模型称为“全局搜索”（universal search）。总的来说，这一次全局搜索有可能调用上千台服务器，涉及各种服务。而且，用户对搜索的耗时是很敏感的，而任何一个子系统的低效都导致导致最终的搜索耗时。如果一个工程师只能知道这个查询耗时不正常，但是他无从知晓这个问题到底是由哪个服务调用造成的，或者为什么这个调用性能差强人意。首先，这个工程师可能无法准确的定位到这次全局搜索是调用了哪些服务，因为新的服务、乃至服务上的某个片段，都有可能在任何时间上过线或修改过，有可能是面向用户功能，也有可能是一些例如针对性能或安全认证方面的功能改进。其次，你不能苛求这个工程师对所有参与这次全局搜索的服务都了如指掌，每一个服务都有可能是由不同的团队开发或维护的。再次，这些暴露出来的服务或服务器有可能同时还被其他客户端使用着，所以这次全局搜索的性能问题甚至有可能是由其他应用造成的。举个例子，一个后台服务可能要应付各种各样的请求类型，而一个使用效率很高的存储系统，比如Bigtable，有可能正被反复读写着，因为上面跑着各种各样的应用。上面这个案例中我们可以看到，对Dapper我们只有两点要求：无所不在的部署，持续的监控。无所不在的重要性不言而喻，因为在使用跟踪系统的进行监控时，即便只有一小部分没被监控到，那么人们对这个系统是不是值得信任都会产生巨大的质疑。另外，监控应该是7x24小时的，毕竟，系统异常或是那些重要的系统行为有可能出现过一次，就很难甚至不太可能重现。我们可以得到一些需求，或者设计理念。
### 正排索引对与搜索引擎而言，每个网页对应一堆关键字：网页A=关键词1+关键词2+关键词3+关键词4+关键词5+关键词6+关键词7+.......网页B=关键词2+关键词5+关键词+关键词12+关键词56+关键词36+关键词99+.....网页C=关键词1+关键词3+关键词6+关键词9+关键词55+关键词65+关键词98+.....当网页被排成上述情况时，就是我们所说的正排索引，如果进行搜索，需要遍历每个网页。### 倒排索引实际上，我们会进行倒排索引然后进行搜索：关键词1=网页A+网页B+网页C+网页O+....关键词2=网页B+网页P+网页Z+......关键词3=网页D+网页T+网页Y+网页Z+.....对关键字进行索引，搜索出结果，然后根据评分排序。