信息聚合系统的数据库后台（比如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底层物理存储更均衡，可能还要细化设计。。。