听起来很奇怪，图和图数据库通常实现为链表。正如这里提到的，即使是最流行/性能最好的图形数据库（neo4j），也在秘密地使用类似于双向链表的东西。

以这种方式表示图形有许多显着的好处，但也有一些缺点。首先，以这种方式表示图意味着您可以在近乎恒定的时间内进行基于边的插入。其次，这意味着如果我们只是想在链表中上移或下移，遍历图可以非常迅速地发生。

但是，最大的缺点来自有时称为贾斯汀比伯效应的东西，其中具有大量连接的节点往往评估速度非常慢。想象一下，每次有人链接到贾斯汀比伯时，都必须遍历一百万个半冗余链接。

我知道 Neo4j 的优秀人员正在研究第二个问题，但我不确定他们是如何解决的，或者他们取得了多大的成功。

在稍微处理过 Facebook 数据（从 Facebook 用户收集）后，我们将其存储为一对值：USER_ID、FRIEND_USER_ID。

但我想你的问题有点深？您可以根据您的研究问题以不同的方式存储它。例如，一个有趣的选项是三合会 - http://mypersonality.org/wiki/doku.php?id=list_of_variables_available#triads

当我处理社交网络数据时，我们将“友谊”关系存储在表中的数据库中，Friends(friend_a, friend_b, ...)并带有 B-Tree 索引(friend_a, friend_b)以及一些分区。

在我们的例子中，由于图表是定向的，所以它有点不同，所以它不是真正的“友谊”，而是“追随者/追随者”的关系。但是为了友谊，我只存储两个边缘：两者(friend_a, friend_b)和(friend_b, friend_a)

如果重要的话，我们使用 MySQL 来存储数据，但我想它不应该。