此问题的灵感来自highscalability.com上的文章“Why are Facebook, Digg, and Twitter so hard to scale?”
那么哪些数据库系统（无论多么模糊）能够更好地处理这类数据呢？
答案 0 :(得分：7)
拥有一个数据库系统，其中数据模型是针对您尝试表示的数据结构而定制的，这通常是有利的。社交网络非常适合图形数据库，例如Allegro Graph，Neo4j等。
关于如何在图形数据库中表示社交网络有good article at the Neo4j blog，示例使用Neo4j。
图形数据库的好处是存储数据，以便遍历实体之间的连接是一个非常快速的操作，允许您快速遍历复杂的网络。在关系数据库的当前实现中，这些操作通常是（最多）昂贵的连接操作。与关系数据库一样，图形数据库在向外扩展到多个硬件节点时仍然存在轻微问题。然而，对于图形数据库而言，对于社交网络类型的数据的关系数据库，对多个硬件节点的需求应该少得多，单个机器上的几十亿个节点都没有问题。扩展到多个硬件节点是键值存储发光的地方，因为键值存储中的实体彼此完全隔离。这里的问题是社交网络中没有任何东西被隔离，这意味着要模拟连接需要对数据库进行多次查询，每个实体一次。这将是缓慢的，特别是对于朋友的朋友类型的查询，其中您只发现每个查询的一个级别的朋友。
免责声明：我是Neo4j团队的成员。
答案 1 :(得分：3)
检查NOSQL debrief，它在几个分布式非关系数据库上有很多有趣的资源：
演示幻灯片和视频
介绍会 - Todd Lipcon，Cloudera （幻灯片，视频1，视频2）
Voldemort - Jay Kreps，Linkedin（幻灯片pdf ppt， video1，video2）
Cassandra - 阿维纳什 Lakshman，Facebook（幻灯片pdf ppt， 视频）
Dynomite - 悬崖月亮， Powerset（幻灯片，视频）
HBase - Ryan Rawson，Stumbleupon（幻灯片， 视频）
Hypertable - 道格·贾德， Zvents（幻灯片pdf ppt，video1， VIDEO2）
CouchDB - 克里斯安德森， couch.io（幻灯片，视频1，视频2）VPork - Jon Travis，Springsource （幻灯片，视频）
MongoDb - 德怀特 Merriman，10gen（幻灯片，视频）
无限可扩展性 - Jonas S. Karlsson，Google（幻灯片，视频）Digg的约翰奎因的一些视频 来自Last.fm的Martin Dittus休息。 图片来自Last.fm的Russ Garrett。
有关幻灯片和视频的链接，请查看原始页面，其中有太多要粘贴。
您可能也想阅读NoSQL: If Only It Was That Easy（甚至维基百科上的Nosql条目）。
答案 2 :(得分：1)
当文章提到memcached时，文章间接地告诉了你答案。这是一个键值存储，可将所有数据保存在RAM中。显然，你必须有额外的数据存储来保存硬盘上的数据，但它们可能也是键值存储。其中有很多，例如Hadoop，CouchDB，Tokyo Cabinet和Redis。
您还可以使用MonetDB等列存储，只需要检索您感兴趣的字段，而不是整个表行。
答案 3 :(得分：0)
我建议您尝试使用图形数据库。由于涉及实体之间的大量关系时的性能，它可以说是社交媒体的最佳解决方案之一。
尝试阅读本文，看看图数据库是否适合您：https://www.guidearea.com/social-media-database-design-using-graph-database-neo4j/