如何存储稀疏邻接矩阵

Question

我读了几个主题，但我迷路了。我对此很陌生。我想存储巨大的稀疏矩阵并有几个想法，但可以在它们之间进行选择。这是我的需求：

1. 近似的邻接矩阵。 5000万个顶点。
2. 每个顶点的最大邻居数量 - 大约10 000。
3. 每个顶点的平均邻居数量 - 约。 200-300。
4. 快速行查询 - 矢量将乘以此矩阵。
5. O（1）添加边缘的复杂性。
6. 最有可能的是，边缘不会被删除。
7. 尽可能快地枚举与v相邻的顶点。
8. 便携性 - 必须有一种方法将基地从一台计算机转移到另一台计算机。

所以，这是我的想法：

1. 巨大的桌子对（行，col）。非常简单，但顶点的枚举将至少为O（log N），其中N - 表的大小。我觉得它很慢。此外，它必须编入索引。每个RDBMS都会有所帮助。
2. 大量的列表：每个顶点一个列表。枚举非常快，但是存储它不需要太多资源吗？另外，我不确定在这种情况下使用哪个DBMS：也许是一些NoSql？
3. 巨大的桌子（一排cols）。上面两个组合。我不确定是否有任何RDBMS支持任意集。你知道任何？也许NoSql在这里有用吗？
4. 邻接列表的集合。任何RDBMS都适用于此，并且复杂性方面的成本很高，但是对于一个顶点，它们可能会被多个DB请求所杀死。
5. HDF5 - 我认为由于I / O会很慢。
6. Neo4j - 据我所知，它将数据存储在双链表中，因此它实际上与№4相同，我是对的吗？

请帮助我选择或提供更好的决定。

如果我在某处估计错了，请纠正我。

Answer 1

混合neo4j / hbase方法可以很好地运行，其中neo4j优化了图形处理方面，而hbase实现了繁重的可扩展性 - 例如，用于存储大量额外属性。

neo4j包含节点和关系。它可能具有足够的可扩展性。我在网上对独立的非neo4j站点进行的调查在一台机器上声称多达数十亿个节点/关系，在遍历上比RDBMS提高了几个数量级。

但是..如果需要更多的可扩展性，你可以引入hbase big iron来存储非关系/节点标识符的额外属性。然后只需将hbase rowkey添加到neo4j节点信息中，以便在应用程序需要时进行查找。

Answer 2

最后，我实施了第一个解决方案。

我使用PostgreSQL有两个表：一个用于带有两列的边 - 开始/结束，另一个用于具有顶点数的唯一序列和顶点描述的一些列的顶点。

我已经基于pg_advisory_xact_lock实现了upsert。它有点慢，但对我来说已经足够了。

此外，从此配置中删除顶点也很痛苦。

为了加速乘法，我将边缘表导出到文件。它甚至可以放在x64机器上的RAM中。

公平地说，数据量低于我的预期。对于1个顶点而不是5000万个顶点和平均200-300个边缘，总共只有700万个顶点和1.6亿个边缘。