1

我有一个具有以下模式的图表：

- 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”（来自步骤→执行）和“execution_step”（来自执行→步骤）。

    图数据库（Cosmos DB 或任何图数据库）是否旨在处理与单个顶点关联的数千个顶点和边？

  2. 每个“执行”都有（理论上）与之相关的无限属性，但它可能是 10 <  x  < 100 个属性。那样可以么？图形数据库是否支持顶点外的大量属性？

    我见过的所有演示似乎都有 < 10 个属性。

4

1 回答 1

2

将这么多执行文件挂在一个顶点上是否合适？例如，每个“步骤”可能有 100 次“执行”。

单个顶点有 100 条边不是非典型的，听起来很合理。在实践中，您可以轻松地找到拥有数百万条边的模型，并深入研究超级节点的问题，此时您需要根据预期的查询模式做出一些设计选择来处理此类事情。

每个“执行”都有（理论上）与其关联的无限属性，但可能是 10 < x < 100 个属性。那样可以么？图数据库是否支持一个顶点的很多很多属性？

在设计模式时，我认为图建模者倾向于根据图元素（即顶点/边）来考虑拥有无限属性的能力，但在实践中他们必须考虑图系统的能力，而不是全部假设是一样的。一些图，如 TinkerGraph 将仅受可用内存的限制。JanusGraph 等其他图将受到底层数据存储（例如 Cassandra、Hbase 等）的限制。

我不知道有任何图形系统在存储 100 个属性时会遇到问题。当然，所有这些一般性都有一些警告——举几个例子：

  1. 整数和布尔值的 100 个单独的简单原始属性不同于 100 字节数组，每个数组包含 100 兆字节的数据。
  2. 在大多数系统上存储 100 个属性是可以的，但您打算索引所有 100 个吗？在某些可能是问题的系统上。既然您用“CosmosDB”标记了您的问题，我将提供我认为他们不会太担心这一点，因为他们会自动索引所有内容。
  3. 如果这 100 个属性中的任何一个是多属性，您可以将自己置于创建不同类型的超级节点的位置 - 胖顶点（具有数百万个属性的顶点）。

综上所述，一般来说，您的模式对于任何图形系统来说听起来都是合理的。

于 2020-05-08T12:12:38.807 回答