搜索引擎优化：每天一小时(如何保证倒排索引数据不能实时索引到呢？(图))

　　搜索引擎优化：每天一小时(如何保证倒排索引数据不能实时索引到呢？(图))

　　一、起源

　　《》详细介绍了前三章：

　　(1）全网搜索引擎结构及流程

　　(2）网站搜索引擎结构和流程

　　(3）搜索原理和核心数据结构

　　《》介绍：

　　（4）流量数据量从小到大，常见的搜索方案和架构变化

　　（5）数据量、并发、可扩展架构方案

　　本文将讨论：

　　（6）为什么百度可以实时检索15分钟前的新消息？为什么可以实时检索1秒前发布的帖子？搜索引擎的实时架构是问题将在本文中讨论。

　　二、实时搜索引擎架构

　　为了保证数据量大、并发度高的搜索引擎的实时性，架构设计有两个关键点：

　　(1）指数评级

　　(2）转储&合并

　　指数评级

　　《》介绍了搜索引擎的基本原理。在数据量非常大的情况下，为了保证倒排索引的高效检索效率，任何数据更新都不会实时修改索引。一旦发生碎片化，检索将大大减少。高效的。

　　既然不能实时修改索引数据，那么如何保证最新的网页可以被索引呢？

　　索引分为全量库、日增量库、小时增量库。

　　如下图所述：

　　（1）全索引数据库300亿数据

　　(2）1000万 1天内修改的数据在库中

　　（3）1小时内修改的5000万条数据在小时数据库

　　当发生修改请求时，只会操作最底层的索引，例如小时数据库。

　　当一个查询请求发生时，会同时查询每一层的索引，合并结果，得到最新的数据：

　　（1）全库是一个紧密存储的索引，无碎片，快速

　　（2）天库存储紧密，速度快

　　(3）小时数据库数据量小，速度快

　　数据的写入和读取都是实时的，所以58同城可以检索1秒前发布的帖子，即使整个数据库有300亿条数据。

　　一个新的问题来了：每小时的数据库数据什么时候会反映到天空数据库中，天空数据库中的数据什么时候会反映到完整数据库中？

　　转储和合并

　　这是由两个异步工具完成的：

　　dumper：导出在线数据

　　合并：将离线数据合并到更高级别的索引中

　　小时图书馆，每小时一次，合并到天空图书馆；

　　天库，每天一次，合并到全库；

　　这样可以保证小时数据库和天空数据库的数据量不会特别大；

　　如果数据量和并发量较大，可以将周数据库和月数据库加入缓冲区。

　　三、总结

　　超大数据量，超高并发，实时搜索引擎的两个架构点：

　　(1）指数评级

　　(2）转储&合并

　　正如“”中提到的，整个网络搜索引擎分为三部分：Spider、Search&Index、Rank。本文介绍了如何实时修改和检索Search&Index，以及Spider子系统如何实时查找全网新生成的网页。这是另一个将在未来描述的问题。

　　希望大家有所收获和帮助。

　　==【完结】==

　　相关文章：

　　本文来自微信公众号-建筑师之路（road5858）.