【问题标题】:Impacts of multiple Vertex Collections bound to an Edge Collection?绑定到边缘集合的多个顶点集合的影响?
【发布时间】:2016-05-25 22:15:16
【问题描述】:

我正在设计一个使用 ArangoDB 的解决方案,并且需要具有连接到 5 到 200 个顶点集合的单个边缘集合。

每个顶点集合将绑定 1 到 180 个边缘集合。

每个 Edge Collection 都会有一个为其创建的 Graph 对象。

我是 ArangoDB 的新手,如果有一些我需要注意的关键性能影响,我很感兴趣。

服务器硬件应该不是问题,因为可以在云提供商上使用更大的服务器实例。

我对 ArangoDB 的性能更感兴趣,其中边缘集合引用了如此多的共享顶点集合,以及其他任何不那么明显的问题。

我正在使用的 ArangoDB 的当前版本是 2.8.2。

谢谢!

【问题讨论】:

    标签: arangodb


    【解决方案1】:

    对于性能方面,有以下几个因素: 不使用图表:

    1. 向任意多个集合中的顶点添加边没有开销。
    2. 每个集合本身都有开销,它使用自己的数据文件等。
    3. 直接使用 AQL 或 Document API 删除顶点/边不受连接集合总量的影响。 (注意:在这种情况下,指向此文档的边缘不会被删除!)

    使用图表: 每当您通过图形 API 删除顶点时,都会发生以下情况:

    1. 顶点被删除(恒定时间)
    2. 此图已知的边集合中到该顶点的所有边都将被删除(扫描所有edge definitions 以及所有from 和所有to 定义,如果该顶点可能在此处连接。如果是这样,它将对该顶点的所有边进行索引查找并将其删除。
    3. 接下来,它将扫描所有其他图表,并为每个图表检查集合是否属于一个边定义。

    因此,据我了解,在您的情况下,删除操作将非常昂贵。 插入/更新/查找/查询不受连接集合数量的影响。

    但是我认为拥有这么多图表和这么多集合似乎有点过度设计,但由于我不知道您的用例的细节,我无法判断是否有必要。

    【讨论】:

    • 谢谢。很高兴听到非删除功能应该没问题。这些“群”集合中的数据将是只读的,当从系统中删除时,集合集群将转储到磁盘,然后从数据库服务器中删除。所有关于哪些集合是“活动”或“删除”的逻辑都是代码驱动的,因此它不会是手动的。我真的很喜欢允许图形由任意边/顶点集合组成时所获得的抽象,它允许极大的灵活性和顶点重用。感谢您的回复。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-12-10
    • 1970-01-01
    • 2020-08-01
    • 2020-12-27
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多