数据库系统是否更适合社交网络？

Question

此问题的灵感来自highscalability.com上的文章“Why are Facebook, Digg, and Twitter so hard to scale?”

那么哪些数据库系统（无论多么模糊）能够更好地处理这类数据呢？

Answer 1

拥有一个数据库系统，其中数据模型是针对您尝试表示的数据结构而定制的，这通常是有利的。社交网络非常适合图形数据库，例如Allegro Graph，Neo4j等。

关于如何在图形数据库中表示社交网络有good article at the Neo4j blog，示例使用Neo4j。

图形数据库的好处是存储数据，以便遍历实体之间的连接是一个非常快速的操作，允许您快速遍历复杂的网络。在关系数据库的当前实现中，这些操作通常是（最多）昂贵的连接操作。与关系数据库一样，图形数据库在向外扩展到多个硬件节点时仍然存在轻微问题。然而，对于图形数据库而言，对于社交网络类型的数据的关系数据库，对多个硬件节点的需求应该少得多，单个机器上的几十亿个节点都没有问题。扩展到多个硬件节点是键值存储发光的地方，因为键值存储中的实体彼此完全隔离。这里的问题是社交网络中没有任何东西被隔离，这意味着要模拟连接需要对数据库进行多次查询，每个实体一次。这将是缓慢的，特别是对于朋友的朋友类型的查询，其中您只发现每个查询的一个级别的朋友。

免责声明：我是Neo4j团队的成员。

Answer 2

检查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条目）。

Answer 3

当文章提到memcached时，文章间接地告诉了你答案。这是一个键值存储，可将所有数据保存在RAM中。显然，你必须有额外的数据存储来保存硬盘上的数据，但它们可能也是键值存储。其中有很多，例如Hadoop，CouchDB，Tokyo Cabinet和Redis。

您还可以使用MonetDB等列存储，只需要检索您感兴趣的字段，而不是整个表行。

Answer 4

我建议您尝试使用图形数据库。由于涉及实体之间的大量关系时的性能，它可以说是社交媒体的最佳解决方案之一。

尝试阅读本文，看看图数据库是否适合您：https://www.guidearea.com/social-media-database-design-using-graph-database-neo4j/