資訊聚合系統的資料庫背景（比如RSS訂閱，feedly）應該如何設計？

我想起之前有研究所學生同學曾經參與一個實習項目，他們用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底層實體存儲更均衡，可能還要細化設計。。。