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