今天下午,使用新浪微博的查詢好友功能查詢好友時,突然想起這樣的一個功能,應該說這個問題我之前也考慮過,但是一直沒有很好的答案,這裡做一個描述.

其實問題說白了也很簡單,查詢好友的時候,可以根據使用者的一個或者多個屬性來定位資料.比如一個使用者有使用者名稱,性別,地址三個屬性,如何做到可以根據其中的一個或者多個屬性來定位使用者呢?

首先來看儲存端的設計,我個人認為這個功能雖然可能用的次數不多,但是不應該是直接去訪問查詢資料庫的,否則量如果大了起來響應會很慢.好了,如果不是直接查詢資料庫的話,那麼擋在資料庫前面應該有cache伺服器了.第二個問題來了,cache總是有限的,不能快取所有的資料,那麼在這裡查詢就可能會丟失一些資料,這個問題又怎麼解決呢?嗯,我個人的猜測是,這裡有一個平衡點的問題,即有一個準則,比如說經常登入的活躍使用者資訊才會留在cache中,不常訪問的使用者,找不到也不打緊了.

接下來,如果資料真的在cache中,即使如此,那麼要實現這裡提到的可以根據多個屬性來查詢資料也不是很容易實現的.

現在大部分的cache系統,比如memcached,還有我之前寫的ccache,本質上都是key-value形式的cache,也就是僅能針對一個key值進行搜尋查詢.

考慮如下的兩種實現:
1) 快取中資料key是使用者名稱,而value是使用者的其它資訊如性別,城市,主頁等,那麼這裡就存在一個key值不唯一的問題.好了,如果把所有相同key值的資料組織在一起,比如用一個連結串列串起來,如果找到這個使用者名稱,再遍歷這個連結串列根據其餘的引數來定位資料.但是,如果使用者不是根據使用者名稱也就是key值來查詢資料的,如何是好呢?難道說,要建立一個多key的資料結構用於查詢,就我現在對cache設計的瞭解,還沒有這種多key設計的cache,基本上都是單key的cache.

2) 快取中資料key不僅包括使用者名稱,還包括了其它可以定位到使用者的屬性,也就是,與前面的實現不同的是,這個實現把多個屬性都放在key裡面了.但是,如果這樣組織資料,又如何定位資料呢?假設key裡面有三個屬性,某次使用了其中的一個屬性來查詢,下一次使用其中的兩個屬性來查詢....這種設計實現起來還是很難的.

以上幾個問題,我今天考慮了一下,沒有太好的思路,這也越發激起我去研究資料庫實現的想法.疑問未除,做個紀念.


=========== 分割線 ==================
這個問題似乎我想的複雜了,問了一下朋友,說是應該直接搜尋資料庫,因為一般這樣的搜尋量不會很多.