400 萬用戶、800 萬代碼、每分鐘 300 次搜尋！GitHub 是如何優化搜尋效能？

GitHub 大家一定有聽過，在 GitHub 當中我們可以隨時搜尋不同的開源方案原始碼，另外亦可以於上方建立新的計劃以及更便於開發者進行共同協作。現時 GitHub 擁有 400 萬用戶、800 萬代碼庫以及總數達 20 億的文件量，面對如此龐大的檔案，GitHub 又是如何通過不同的方案進行優化工作？

今天我們採訪了一家名為 elastic 的公司，她們原來正正為 GitHub 提供其搜尋引擎及分析工作。elastic 是一套提供索引功能的開源方案，通過方案用戶可以更容易將結構化及非結構化的數據進行分析及索引，最終優化搜尋體驗；當然 elastic 亦同時提供針對客戶需求而度身訂做及部署的收費方案。

首先談談 GitHub 的搜尋功能。現時大家可以通過 GitHub 的搜尋功能直接搜尋到計劃的名稱、用戶、程式代碼以及通過指令模式進行搜尋及作出 pull request 等等。GitHub 工程師 Tim Pease 指出，他們最終目標就是將 GitHub 之中的任何一種數據都變成可搜尋的索引。

面對此種期望，傳統通過開發站內的搜尋功能，明顯未能盡如人意；當然願意花上時間不停改良及研發是絕對能開發到一個萬能的站內搜尋功能，問題是「值得花上一年時間不停開發、改良自家的搜尋引擎嗎？」

開發者就是拼砌專家？

當然在時間、成本效益等方面作計算的話，自家從零開發是不可取的。就好像大家開發網頁時，會直接採用開源 CMS 系統、會員註冊功能表會直接採用開源的預製組件、按鈕等亦是採用第三方製作的預製組件；同樣地搜尋功能當然亦直接整合第三方開源方案，這才是皇道，所以開發者的身份角色，已從開發者變成一名拼砌專家。

採用 Elasticsearch 作多重查詢

Tim 繼指：「回想當年，GitHub 其實是採用 NoSQL Databases 進行索引的，而現時通過採用 Elasticsearch，GitHub 之中的高度結構化及高度非結構化的數據均可同時儲存及直接進行搜尋，同時傳統標準的 SQL 數據庫不支援的多重查詢，透過 Elasticsearch 亦可實現得到。」

GitHub 通過搜尋索引揪出安全漏洞

GitHub 除了透過開源的 Elasticsearch 針對數據進行索引之外，更通過結合 Elasticsearch 的分析工具協助日常工作。舉個例子，GitHub 通過收集索引查詢，從而取得審計所需的 Log；而 Elastic Shield 分析 Log 以後，便可以輕易的發現安全問題；例如通過分析用戶在 GitHub 上的每一個動作，管理員便可輕易的得知那些帳戶是有機會被盜、被綁架又或者揪出從事攻擊行為的用戶。

GitHub 放棄 Solr

Tim 指出，在最初 GitHub 是採用了 Solr 的，不過當使用人數愈來愈多時，便發現單一 Solr cluster 及 Solr instance 很快出現空間不足情況，而且亦很難進行管理。

而 Elasticsearch 卻提供了 shard rebalancing 功能，此功能可提升整體效率，同時更可有效處理故障轉移情況。而每一個 shards 亦將會自動複製並分發到一個位於 cluster 的新節點上，萬一固有節點出現問題時，被複製到 cluster 上的shards 將會自動進行故障轉移。

如何應對每分鐘 300 次搜尋？

在 GitHub 之中，搜尋的速度是最重要的，而根據官方資料指出，現時 GitHub 平均每分鐘會有多達 300 次的搜尋，因此 GitHub 的一大任務就是需要在最短時間之內，將用戶上傳每分鐘數以百計的全新代碼、文件等迅速完成索引並容許用戶以近乎即時的速度完美地完成搜尋工作，為此 GitHub 便採用了 sharding extensively。

Tim 舉例指出，在 GitHub 的主要 Elasticsearch cluster 之中，本身擁有 128 個 shards，而每個 shards 儲存 120 gigabytes 數據；為了能將搜尋精準度做到只搜尋單一代碼，GitHub 採用基於庫存 ID 的 Elasticsearch 路由參數，因此能做到讓用戶於單一 shards 之中搜尋單一代碼；而假如在單一項目頁面之中進行搜尋的話，速度上比起於 GitHub 主頁作搜尋快三倍以上。

GitHub 就是通過採用 Elasticsearch 優化搜尋功能而為一眾開發者帶來更快更強的搜尋體驗，可見搜尋功能對於一個網站的重要性；大家是否已為自己公司網站部署了最佳的優搜引擎？