微信朋友圈技术实现探讨

请教大家一个问题，微博关注好友动态主页，和微信朋友圈动态列表，后端架构设计都是如何实现的？
自己想到的是：
方案一：
1：首选是取我的好友列表，这个有自己的好友列表cache维护，不能直接查询db，考虑到数据量很大情况下的伸缩性必须满足。
2：再根据我的好友ids再去取他们发表的微博或者动态，按照时间排序，这个无疑是拿着user_ids in 动态数据表，这点感觉性能很致命。

方案二：
对比方案一，关系性数据库在面临大数据的时候系能会显得比较疲惫，考虑采用NOSQL，如：Mongodb，HBase ，Redis等产品。
综合对比，倾向选用HBase。Mongodb莫名丢数据时而常有的事情；Redis Master-Slave结构面临单机内存垂直增长受限，Redis 3.0目前支持Cluster，配合Sentinel，貌似能保证sharding nothing又能保证高可用，但是Redis Cluster生产环境没有实用经验。

大家有什么好的建议呢？

方案二还得补充一点就是代码上线前，需要处理已有好友关系的动态数据存储，从mysql考虑用job一次性跑到nosql中，这样保证我关注的人，先前发的动态我也能看到。

可以考虑Cassandra和Neo4j

Neo4j属于图数据库，的确是适合存储好友关系这种关系节点的类型数据，无论是查看我关注的和相互关注的好友，根据relatioship能很快查询出来，不过Neo4j有收费企业版和免费版，@banq选择免费版的就可以吗？

Cassandra和HBase对比，@banq为啥推荐使用Cassandra？

逛了一圈知乎，貌似大家在HBase和Cassandra的选择上，更加倾向于前者，原因有如下几点：
1：遭受很多国外大型互联网公司的弃用，而且文档和社区落伍不太活跃，同时运维成本也比HBase高出一筹。
2：在CAP特性上，HBase选择了CP，Cassandra更倾向于AP，而在一致性上有所减弱。
3：Cassandra数据压缩时，读写性能急剧低下。
4：不支持直接接入hadoop，不能实现MapReduce。
5：也有说频繁GC，导致读写性能低下的情况（这种情况，我多半怀疑是配置或者jvm调优没有做好）