亚洲乱码中文字,亚洲午夜一区二区三区,在线视频欧美

為什么社交網絡中數據翻頁技術復雜

轉帖|使用教程|編輯：龔雪|2014-12-16 10:26:18.000|閱讀 203 次

概述：為什么社交網絡中數據翻頁技術復雜?作者在此為您詳細解讀。

慧都年終巨獻，Aspose系列產品黃金版+白金版享<8折>優惠！截止日期2014/12/31

最近討論的一個傳統的問題，問題本身比較簡單，針對key-list類型的數據，如何優化方案做到性能與成本的tradeoff。Key-list在社交產品及面向用戶的產品中非常普遍，如一個用戶的好友關系 {“uid”:{1,2,3,4,5}}，表示某個uid有1,2,3,4,5好友；一條微博下面的評論id列表結構是 {“weibo_id”: {comment_id1, comment_id2……}}，一個用戶發表的微博id列表等。

在list長度較小時，我們可以直接使用數據庫的翻頁功能，如

SELECT * FROM LIST_TABLE LIMIT offset, row_count;

根據經驗，在大部分場景下，單個業務的list數據長度99%的情況在1000條以下，在數據規模較小時，上面的方法非常適合。但剩下的1%情況下，數據可能多達100萬條，在數據規模較大的時候，當訪問offset較大的數據集，上述方法非常低效。但在考慮方案的時候不能忽視這些超大數據集的問題，因此要實現一個適合各種變長list場景的翻頁方案，業界并沒有簡單高效的方案。這也反映出常說的80%的時間在優化20%的功能。

List數據訪問模型常見的有兩種方式

1. 扶梯方式

扶梯方式在導航上通常只提供上一頁/下一頁這兩種模式，部分產品甚至不提供上一頁功能，只提供一種“更多/more”的方式，也有下拉自動加載更多的方式，在技術上都可以歸納成扶梯方式。

（圖：blogspot的導航條）

（圖：很多瀑布流式的產品只提供一個more的導航條）

扶梯方式在技術實現上比較簡單及高效，根據當前頁最后一條的偏移往后獲取一頁即可，在MySQL可使用以下方法實現。

SELECT * FROM LIST_TABLE WHERE id > offset_id LIMIT n;

由于where條件中指定了位置，根據B-TREE實現原理，算法復雜度是O(log n)

2. 電梯方式

另外一種數據獲取方式在產品上體現成精確的翻頁方式，如1,2,3……n，同時在導航上也可以由用戶輸入直達n頁。國內大部分產品經理對電梯方式有特殊的喜好，如圖

（圖：timyang.net 網站的導航條）

但電梯方式在技術實現上相對成本較高，當使用以下SQL時

SELECT * FROM LIST_TABLE LIMIT offset, row_count;

我們可以使用MySQL explain來分析，從下文可以看到，當offset=10000時候，實際上MySQL也掃描了10000行記錄。

為什么會這樣？在MySQL中，索引通常是b-tree方式（但存儲引擎如InnoDB實際是b+tree），如圖

從圖中可以看到，使用電梯方式時候，當用戶指定翻到第n頁時候，并沒有直接方法尋址到該位置，而是需要從第一樓逐個count，scan到count*page時候，獲取數據才真正開始，所以導致效率不高。對應的算法復雜度是O(n)，n指offset，也就是page*count。

另外Offset并不能有效的緩存以便轉化成前一種訪問模式，這是由于

1、在數據存在新增及刪除的情況下，只要有一條變化，原先的樓層可能會全部發生變化。在一個用戶并發訪問的場景，頻繁變化的場景比較常見。

2、電梯使用比較離散，可能一個20萬條的list，用戶使用了一次電梯直達100樓之后就走了，這樣即使緩存100樓之下全部數據也不能得到有效利用。

以上描述的場景屬于單機版本，在數據規模較大時候，互聯網系統通常使用分庫的方式來保存，實現方法更為復雜。在面向用戶的產品中，數據分片通常會將同一用戶的數據存在相同的分區，以便更有效率的獲取當前用戶的數據。如下圖所示

圖中的不同年份的數據的格子是邏輯概念，實際上同一用戶的數據是保存在一張表中。因此方案在常見的使用場景中存在很大不足，大部分產品用戶只訪問最近產生的數據，歷史的數據只有極小的概率被訪問到，因此同一個區域內部的數據訪問是非常不均勻，如圖中2014年生成的屬于熱數據，2012年以前的屬于冷數據，只有極低的概率被訪問到。但為了承擔紅色部分的訪問，數據庫通常需要高速昂貴的設備如SSD，因此上面方案所有的數據都需要存在SSD設備中，即使這些數據已經不被訪問。

簡單的解決方案是按時間遠近將數據進行進一步分區，如圖。