我想起之前有研究生同學曾經參與一個實習項目，他們用SQL數據庫來實現一個RSS訂閱聚合系統，結果遇到了擴展性問題：當RSS源達到上千的時候，併發查詢性能就已經下降到不可接受。
之後我遇到的實用的信息聚合系統：Google閱讀器、以及Feedly。Feedly的官方博客裏說它的後臺是用HBase來存的。我不禁好奇其數據架構設計到底是怎麼做的。
首先，容易想到的是，爲每篇博客文章關聯RSS源id（博客訂閱的rss url地址），及文章id（直接使用url，或者數據庫生成列），每篇博客文章需要全局順序的編號，則每個用戶的聚合訂閱相對於文章id的一個列表。這樣用戶拉取新文章相對於對前面全局文章列表的一個selective sorted io copy。
不過既然所有的博客文章都是全局序存儲的（按更新或RSS爬蟲的爬取時間），其物理存儲怎麼做水平切分呢？
能想到的最簡單的，就是對RSS源id做DHT。然後每次拉取用戶訂閱的聚合源的更新時，需要做一個並行的Fork（Scatter）-Join（Merge）查詢。這樣大概能夠解決問題了。但是僅僅對RSS源id做DHT的話，還不能解決每個不同的RSS源文章數量不同、數據量不均勻，爲使得DHT底層物理存儲更均衡，可能還要細化設計。。。
