对于CosmosDB和Graph Databases，我可以拥有连接到单个顶点的O(1000s)个顶点和O(1000s)个顶点的属性吗？

Question

我有一个图，图案如下。

- Workflow:

-- Step #1
--- Step execution #1
--- Step execution #2
    [...]
--- Step execution #n

-- Step #2
--- Step execution #1
--- Step execution #2
    [...]
--- Step execution #n

[...]

-- Step #m
--- Step execution #1
--- Step execution #2
    [...]
--- Step execution #n

我有几个设计问题

1. 在不影响性能的情况下，一个顶点上能挂多少个执行文件？例如，每个 "步骤 "可以有数百个 "执行"。我使用两条边来连接它们--'has_runs'（从步骤→执行）和'execute_step'（从执行→步骤）。

   图数据库（CosmoDB或任何图数据库）是否被设计成处理成千上万的顶点和与单个顶点相关联的边？

2. 每个'执行'都有（理论上）无限的属性与之关联，但可能是10&lt。 x < 100个属性。这样可以吗？图数据库是为了支持一个顶点外的这么多属性而做的吗？我见过的所有demo好像都有< 10个总属性。

Answer 1

一个顶点上挂着这么多执行文件合适吗？例如，每个 "步骤 "可以有100多个 "执行"。

从一个顶点上有100s条边并不是非典型的，听起来也很合理。在实践中，你可以很容易地发现自己的模型有数百万条边，并把自己挖到超节点的问题上，这时你需要根据你的预期查询模式做出一些设计选择来处理这种事情。

每个 "执行 "都有（理论上）无限的属性与之相关联，但可能是10 < x < 100个属性。这样可以吗？图数据库是为了支持很多很多属性脱离一个顶点而做的吗？

在设计模式时，我认为图模型制作者往往会从图元素（即顶点edges）的角度来考虑，认为它具有容纳无限属性的能力，但实际上他们必须考虑图系统的能力，而不是假设它们都是一样的。有些图，如TinkerGraph将只受可用内存的限制。其他的图，比如JanusGraph会受到底层数据存储（比如Cassandra、Hbase等）的限制。

我不知道有哪个图系统会在存储100个属性时出现问题。当然，所有这样的通用性都有注意事项--举几个例子。

1. 100个独立的整数和布尔运算的简单原始属性 与100个字节数组每个数组存储100兆数据是不同的。
2. 在大多数系统中存储100个属性是没有问题的，但是你打算把这100个属性都编入索引吗？在一些系统上，这可能是一个问题。由于你用 "CosmosDB "标记了你的问题，我将提供，我不认为他们太担心，因为他们自动索引一切。
3. 如果这100个属性中有任何一个是 多属性 你可以把自己的位置放在创建一个不同的超节点--一个胖顶点（一个有数百万属性的顶点）。

说了这么多，总的来说，你的模式对于任何图系统来说都是合理的。