关于在OrientDB上设计的一些问题

时间:2016-04-30 17:09:09

标签: orientdb

我们正在为我们创新的“协作应用程序”寻找最合适的数据库。对不起,我们不知道如何以一般理解的方式命名。事实上,租户,角色,用户,任务和账单之间的高度复杂的关系需要得到有效处理。

在阅读了5个DB(Postgrel,Mongo,Couch,Arango和Neo4J)之后,当我看到“......事物之间的关系比事物本身更重要”时,我决定深入研究OrientDB。 OrientDB的设计理念和创新功能(多模型,集群,OO,原生图,完整图形API,类SQL,LiveQuery,多主机,审计,简单RID和版本号......)不断激发我的热情

OrientDB启发我重新思考并尝试从完全不同的角度进行建模!

我们现在正在设计基于OrientDB的数据结构。但是,有些问题让我感到困惑。

  1. LINK vs. EDGE
  2. 假设客户可以放置数千个ORDER,如何在LINK和EDGE之间进行选择以存储关系?我更喜欢EDGE,但他们似乎在CLIENT记录中存储了数千个ORID的RID。

    1. 嵌入式记录的安全性
    2. 嵌入式记录可以独立于其容器记录进行授权吗?

      1. 记录级安全性
      2. 激活记录级安全性如何影响查询性能?

        希望我表达清楚。任何言语都将得到真正的赞赏。

1 个答案:

答案 0 :(得分:2)

LINK vs EDGE

如果您的拱门上没有属性,则可以使用链接,而不是使用边缘。如果你需要在两个方向上遍历关系,你真的需要边缘,而使用链接列表只能在一个方向上(就像网络上的超链接一样),没有边缘的开销。如果您需要通过图形走路,边缘是正确的选择。标记需要比链接列表更多的存储空间。它们之间的另一个区别是,如果你有两个顶点通过链接A相互链接 - >> (链接)B如果你删除B,链接不会消失它会保留但没有指向某事。它是这样设计的,因为当您删除文档时,查找链接到它的所有其他文档将意味着对数据库进行全面扫描,这通常需要很长时间才能完成。带有双向链接的Graph API专门用于解决此问题,因此通常我们建议客户使用它,或者在应用程序级别小心并管理链接一致性。

记录 - 级别安全

使用1百万个顶点和一个名为Luke的管理员用户,进行如下查询:select from where title =?使用NOT_UNIQUE_HASH_INDEX执行时间为0.027秒。 OrientDB具有用户和角色的概念,以及记录级安全性。它还支持基于令牌的身份验证,因此可以使用OrientDB作为授权/验证用户的主要方式。

嵌入式记录的安全性

我试图回答你的问题时做了这个例子

我有这个结构:

enter image description here

如果我想访问嵌入数据,我必须执行以下命令:select prop from User

enter image description here

因为如果我尝试通过包含汽车类型的类来访问它,我将不会有任何类型的结果

select from Car

enter image description here

<强>更新

OrientDB支持这种授权/身份验证,但它与您的示例略有不同。例如:如果没有管理员权限的用户A插入记录,则另一个用户B无法在没有管理员权限的情况下看到用户A插入的记录。用户只能看到已插入的记录。

希望有所帮助