大型網站架構之三 多對多關係的優化設計

上篇以使用者6184.html">資料表為例介紹了基本的資料分割方案以及基本的配置方案。 但是在2.0時代，這種簡單的清單索引已經遠遠實現起來是問題的，多對多關 系將是最常見的關係。 現在我們針對web2.0資料中廣泛存在的多對多關係進行闡述和具體行為判斷，比如一個很簡單的例子，在2.0時代，好友功能是最常 被用到的，每個使用者會有很多的好友，同時也會是很多人的好友，那麼這個資料量將會是使用者數的平方的級別。 同樣，對於文章標籤，每個文章可以有多個標籤，而 每個標籤又可以有多個文章，這又是一個幾何乘積，資料量又會是個天文數位。

傳統的處理方案有兩種，一種是通過SEARCH的方法來實現，一種是通過另建一個索引表，存貯對應的ID以進行存貯。 對於第一種方案，因為要涉 及大量的LIKE查詢，性能不敢恭維，第二種的情況下，資料庫的行的數量也是驚人海量級別的，並且要跨表跨區查詢，還要維護資料的唯一性，HTTP://www.aliyun.com/zixun/ aggregation/14345.html">資料處理過程相 當的複雜性能也就不言而喻了。

文入正題，下面對資料多對多關係舉出來具體的解決方案，我們這裡以標籤和文章之間的多對多關係為例來講解，大家可以舉一反三的思考群組和使用者之間，相冊和被圈使用者之間等等複雜的多對多關係。

首先濾清一下流程，我們以傳統方案的第二種為例，在傳統的資料庫設計中我們是如下走的：當一篇博文發佈的時候並插入標籤的時候一般是三步走(也 可以理解為四步，以為還要判斷標籤是否存在的問題)，第一步插入文章資料庫並獲取文章的ID ，第二步插入標籤資料庫同時查詢標籤是否存在，如果存在就取出 標籤的ID，否則的話插入新標籤並取出ID，第三部，將文章的ID和標籤的ID插入索引表來建立關聯。 如果這個時候在索引表上建立了索引的話就是災難性 的，特別是在資料量大的情況下，儘管它可以有效的提高查詢速度，但是發佈的速度可能就會讓人無法忍受了。

我們處理的方法也是三部曲，對多對多關係進行進一步的處理。

用標籤的時候，我們用的最多的就是查詢標籤下的文章和顯示文章的標籤，所以我們實現這例就成了。

第一步，拋棄索引表。

對文章做冗余欄位，加一個TAG列，我們可以講TAG的標籤如下寫[TagID,TagName]| [TagID,TagName]| [TagID,TagName] 同樣 對於TAG表，我們做如下冗余加個Article欄位，如下內容[ArticleID,Title]| [ArticleID, Title]| [ArticleID, Title],在需要增加的時候我們只要APPEND一下就可以了，至於ARTICLE的結構和TAG的結構可以參考我上一篇文章的介紹。 其實根據需要還 可以存貯更多。

有人會問，為什麼要存貯TagName和ArticleTitle呢，其實是為了避免跨表查詢和INNERJOIN查詢來做的，In查詢和跨表查詢會造成全表遍歷，所以我們在執行的時候In查詢是必須要找到一個有效的替代方法的。

第二部：非同步載入。

在設計模式下我們常思考的是單件模式，我們採用另類的單件模式來處理，也就是把文章和標籤之間的索引作為專門的進程來做，非同步實現。

為了避免文章在發佈的時候以為要檢查TAG表而造成的執行緒擁堵，我們需要採取延遲載入的方案來做。 伺服器應該維護一個進程專業的對標籤和文章地段的查詢和索引，我們在發佈文章的時候應該把標籤同步這一塊託管給另外的一個程式進行處理，並進行索引。