Instagram的優勢在于：雖然公司規模小，卻擁有相對大得多的基礎設施架構，在恰當的時候還能利用資源以借助Facebook十年來積累的經驗。Facebook的“Unicorn”搜索架構是一款以社交圖譜為基礎的搜索引擎，可擴展至包含上萬億個文檔的索引。2015年初，Instagram將所有的搜索架構從Elasticsearch轉到Unicorn。同一時期，Instagram的搜索流量增加了65%，這不僅是用戶群數量增加的結果，也是忠實用戶數（每次使用搜索引擎時都會使用Instagram）增長了12%的結果。
　　這樣的成果部分得益于Unicorn通過社交功能及二階連接執行查詢排序的能力。在7.0升級后，通過對圖譜的各個部分編制索引，Instagram的搜索能力更強，可以更迅速、更便捷地搜索任何想要查找的信息，包括人、地點、標簽與媒體。
　　什么是搜索？
　　Instagram的搜索架構包含了所有興趣實體，如：標簽、位置、用戶及媒體，這些內容以非規范化的形式儲存，通常被稱為文檔——它們被分組歸類到集合中，可通過高效的集合運算（如AND、OR與NOT）來查詢，在實際操作中Instagram對運算結果高效地排序篩選，只留下與指定查詢最相關的文檔。當用戶查詢時，服務器后端會將查詢轉換成編碼，進行集合運算后篩出最佳匹配結合的有序集合。
　　數據錄入
　　Instagram每秒可處理數百萬個搜索請求，其中很多如注冊、點贊和上傳在內的請求需要修改現有記錄，并向主PostSQL數據庫增加新行。為了確保可搜索文件的集合正確，我們需要將這些變更告知搜索架構。此外，在PostgreSQL數據庫中，搜索時一般需要不只一行的信息，例如在照片上傳后，該用戶帳號的歷史信息也會用在搜索中。
　　為了解決非規范化的問題，Instagram引入了Slipstream系統，該系統會對Instagram上的event進行編碼，再錄入包含更多信息的Thrift架構中。這些event以二進制序列化格式存儲，通過異步發送-訂閱頻道（Firehose）來發送。譬如“搜索”功能之類的消費者訂閱到Firehose，過濾掉不相干的event，再對其余event作出反應。Firehose在Facebook的Scribe頂端實現，讓消息傳輸可以異步實現。
　　下圖展示了該架構：
　　
　　自系統化之后，Thrift中跨請求對象再次復用；同時無需自定義反序列化，消費者便可直接消費所傳遞的信息。Slipstream架構中與照片對應的子集如下所示：
　　struct User { 1： required i64 id; 2： string username; 3： string fullname; 4： bool is_private; 。..} struct Media { 1： required i64 id; 2： required i64 owner_id; 3： required MediaContentType content_type; 。..} struct LikeEvent { 1： required i64 liker_id; 2： required i64 media_id; 3： required i64 media_owner_id; 4： Media media; 5： User liker; 6： User media_owner; 。..8： bool is_following_media_owner; } union InstagramEvent { 。..2： LikeEvent like; 。..} struct FirehoseEvent { 1： required i64 server_time_millis; 2： required InstagramEvent event; }
　　Firehose頻道的信息作為best-effort delivery，在消息傳遞中預計只有很小比例的數據丟失。在搜索時，我們通過數據核對進程或base build建立起最終一致性：每天晚上都會對Instagram連接到Hive的所有PostgreSQL數據庫進行截圖存檔，并定期在這些Hive表格與結構中查詢每個垂直搜索的所有文檔；將base build與從Slipstream中獲取的數據相合并，以確保在數據丟失的情況下，系統也保持最終一致性。
　　數據輸出
　　處理查詢
　　如果數據正確接收，則搜索架構可在一定的約束下高效提取相關的文檔，我們稱之為“約束查詢（constraint a query）”，一般是根據用戶提供的文字（例如：用戶輸入“Justin”，實際想搜索Justin Bieber）所衍生。在Unicorn中，查詢被重寫為明確表達目的的S-Expressions，比如：
　　（anduser:maxime（applyfollowed_by： followed_by:me））
　　以上代碼翻譯過來就是：查找我關注、名叫maxime的人所關注的人。在搜索架構中，這個過程分兩步處理：
　　生成候選集：找出一組與給定查詢匹配的文檔，Instagram的服務器后端使用反向索引（reverse index）結構，即通過關鍵詞索引找到多組文檔。舉例來說，輸入關鍵詞“name:justin”就會出現包含“justin”的用戶名集合。
　　排序：從所有候選集中選出最佳文檔。獲取候選文檔后，從文檔的元數據編碼中找出特征，例如：用戶Justin Bieber的特征之一是關注者多達3.23千萬。系統會將這些特征用于計算“擬合度值（goodness）”，以便對候選子集進行排序。擬合度可通過機器學習或手動調整而生成——在機器學習案例中，針對特定候選者，我們可以設計點擊或關注有所差異的特征。
　　通過這兩個步驟，最終得出指定查詢的最佳文檔有序列表。
　　社交圖譜搜索
　　在優化搜索功能時，為了提供更具個性化的搜索結果，Instagram現在會將用戶關注的人以及他們所關注的人都納入搜索范圍。這樣一來，基于用戶所關注的人再來查找某人會更容易。
　　使用Unicorn后，我們能夠對Instagram上的所有帳號、媒體、標簽和地址，還有其間各類關系生成索引。舉例來說，通過對某個用戶的關注者編輯索引，Unicorn可以回答這類問題：
　　“用戶X與用戶Y同時關注的賬號有哪些？”
　　同樣的，通過對媒體中的位置進行索引，Unicorn能得出如下信息：
　　“我關注的帳號所發布的媒體是在紐約拍攝的”。
　　優化帳號搜索功能
　　單獨使用Instagram的圖譜的話體驗不佳，不足以找到想要查找的帳號，必須結合Unicorn的搜索排序架構使用才能奏效。
　　完成這一目標的方法之一是在Instagram上為現有連接建立模型。在Facebook上，賬號間的基本關系是非定向的（通常會互加好友），而在Instagram上卻不一定要回粉。我們的團隊必須對搜索排序算法進行修改，以存儲并檢索Instagram關注圖譜中的帳號信息。對Instagram來說，要使用Unicorn按照混合的方式來檢索帳號：“你關注的人所關注的人”和“關注你的人所關注的其他人”。
　　此外，Instagram的用戶關注彼此的原因各種各樣，某位用戶無需與他所關注的用戶保持完全一致的興趣點。我們的團隊構建了一個模型，針對每個用戶所關注的帳號進行排序，因此在搜索時，與搜索者關系更為密切的用戶所關注的對象會優先顯示。

普通下載普通下載

相關電子資料下載