[关闭]
@JunQiu 2018-09-18T13:16:18.000000Z 字数 1777 阅读 740

正排/倒排索引、分布式服务系统的跟踪(日志、错误等)

summary_2018/08 algorithm arch


1、日常

1.1、分布式服务系统的跟踪:日志、错误

1.2、正排索引和倒排索引

2、技术

2.1、分布式服务系统的跟踪:日志、错误

2.1.1、简介
  1. ### Dapper设计中的一个例子:
  2. 比如一个前段服务可能对上百台查询服务器发起了一个Web查询,每一个查询都有自己的Index。这个查询可能会被发送到多个的子系统,这些子系统分别用来处理广告、进行拼写检查或是查找一些像图片、视频或新闻这样的特殊结果。根据每个子系统的查询结果进行筛选,得到最终结果,最后汇总到页面上。我们把这种搜索模型称为“全局搜索”(universal search)。总的来说,这一次全局搜索有可能调用上千台服务器,涉及各种服务。而且,用户对搜索的耗时是很敏感的,而任何一个子系统的低效都导致导致最终的搜索耗时。如果一个工程师只能知道这个查询耗时不正常,但是他无从知晓这个问题到底是由哪个服务调用造成的,或者为什么这个调用性能差强人意。首先,这个工程师可能无法准确的定位到这次全局搜索是调用了哪些服务,因为新的服务、乃至服务上的某个片段,都有可能在任何时间上过线或修改过,有可能是面向用户功能,也有可能是一些例如针对性能或安全认证方面的功能改进。其次,你不能苛求这个工程师对所有参与这次全局搜索的服务都了如指掌,每一个服务都有可能是由不同的团队开发或维护的。再次,这些暴露出来的服务或服务器有可能同时还被其他客户端使用着,所以这次全局搜索的性能问题甚至有可能是由其他应用造成的。举个例子,一个后台服务可能要应付各种各样的请求类型,而一个使用效率很高的存储系统,比如Bigtable,有可能正被反复读写着,因为上面跑着各种各样的应用。
  3. 上面这个案例中我们可以看到,对Dapper我们只有两点要求:无所不在的部署,持续的监控。无所不在的重要性不言而喻,因为在使用跟踪系统的进行监控时,即便只有一小部分没被监控到,那么人们对这个系统是不是值得信任都会产生巨大的质疑。另外,监控应该是7x24小时的,毕竟,系统异常或是那些重要的系统行为有可能出现过一次,就很难甚至不太可能重现。我们可以得到一些需求,或者设计理念。
2.1.2、设计思想
2.1.3、一些分布式追踪系统
2.1.4、参考文献

2.2、正排索引和倒排索引

  1. ### 正排索引
  2. 对与搜索引擎而言,每个网页对应一堆关键字:
  3. 网页A=关键词1+关键词2+关键词3+关键词4+关键词5+关键词6+关键词7+.......
  4. 网页B=关键词2+关键词5+关键词+关键词12+关键词56+关键词36+关键词99+.....
  5. 网页C=关键词1+关键词3+关键词6+关键词9+关键词55+关键词65+关键词98+.....
  6. 当网页被排成上述情况时,就是我们所说的正排索引,如果进行搜索,需要遍历每个网页。
  7. ### 倒排索引
  8. 实际上,我们会进行倒排索引然后进行搜索:
  9. 关键词1=网页A+网页B+网页C+网页O+....
  10. 关键词2=网页B+网页P+网页Z+......
  11. 关键词3=网页D+网页T+网页Y+网页Z+.....
  12. 对关键字进行索引,搜索出结果,然后根据评分排序。
添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注