百度如何能實時檢索到15分鐘前新生成的網頁？
一、緣起
《深入淺出搜索架構(上篇)》詳細介紹了前三章：
(1)全網搜索引擎架構與流程
(2)站內搜索引擎架構與流程
(3)搜索原理與核心數據結構
《深入淺出搜索架構(中篇)》介紹了：
(4)流量數據量由小到大，常見搜索方案與架構變遷
(5)數據量、并發量、擴展性架構方案
本篇將討論：
(6)百度為何能實時檢索出15分鐘之前新出的新聞?58同城為何能實時檢索出1秒鐘之前發布的帖子?搜索引擎的實時性架構，是本文將要討論的問題。
二、實時搜索引擎架構
大數據量、高并發量情況下的搜索引擎為了保證實時性，架構設計上的兩個要點：
(1)索引分級
(2)dump&merge
索引分級
《深入淺出搜索架構(上篇)》介紹了搜索引擎的底層原理，在數據量非常大的情況下，為了保證倒排索引的高效檢索效率，任何對數據的更新，并不會實時修改索引，一旦產生碎片，會大大降低檢索效率。
既然索引數據不能實時修改，如何保證***的網頁能夠被索引到呢?
索引分為全量庫、日增量庫、小時增量庫。
如下圖所述：
(1)300億數據在全量索引庫中
(2)1000萬1天內修改過的數據在天庫中
(3)50萬1小時內修改過的數據在小時庫中
當有修改請求發生時，只會操作***級別的索引，例如小時庫。
當有查詢請求發生時，會同時查詢各個級別的索引，將結果合并，得到***的數據：
(1)全量庫是緊密存儲的索引，無碎片，速度快
(2)天庫是緊密存儲，速度快
(3)小時庫數據量小，速度也快
數據的寫入和讀取都是實時的，所以58同城能夠檢索到1秒鐘之前發布的帖子，即使全量庫有300億的數據。
新的問題來了：小時庫數據何時反映到天庫中，天庫中的數據何時反映到全量庫中呢?
dump&merge
這是由兩個異步的工具完成的：
dumper：將在線的數據導出
merger：將離線的數據合并到高一級別的索引中去
小時庫，一小時一次，合并到天庫中去;
天庫，一天一次，合并到全量庫中去;
這樣就保證了小時庫和天庫的數據量都不會特別大;
如果數據量和并發量更大，還能增加星期庫，月庫來緩沖。
三、總結
超大數據量，超高并發量，實時搜索引擎的兩個架構要點：
(1)索引分級
(2)dump&merge
如《深入淺出搜索架構(上篇)》中所述，全網搜索引擎分為Spider, Search&Index, Rank三個部分。本文描述的是Search&Index如何實時修改和檢索，Spider子系統如何能實時找到全網新生成的網頁，又是另外一個問題，未來撰文講述。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
