暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

图数据库与关系型数据库的区别及其应用

原创 Ivan Despot 2021-05-13
3902

在大多数开发工作的初期,就有一个重要的问题:选择哪个数据库?现在有如此丰富的数据库技术,难怪许多开发人员没有时间或精力去研究新技术。如果您是其中的一名开发人员,并且对一般的图形数据库不太熟悉,那么您来对地方了!

在本文中,您将了解图数据库和关系数据库之间的主要区别,哪种用例最适合每种数据库类型以及它们的优缺点。

图数据库与关系数据库有何不同?

主要区别在于实体之间关系的存储方式。在图形数据库中,关系存储在各个记录级别,而关系数据库使用预定义的结构(即表定义)。

关系数据库在处理大量记录时会更快,因为数据结构是事先已知的。这也导致较小的内存占用。图形数据库没有用于数据的预定义结构,这就是为什么在查询过程中必须单独检查每个记录以确定数据结构的原因。

图数据模型

第一件事第一!要确定是否需要图形数据库,您需要熟悉基本术语。图形数据库的基本组件是:

  1. 节点:图中的主要实体。您可以将它们视为关系数据库中的行。
  2. 关系:这些实体之间的联系。这些将是关系数据库中的外键。
  3. 标签:将相似节点组合在一起的属性。
  4. 属性:存储在节点或关系中的键/值对。

在典型的社交网络图中,节点表示不同社交组中的人们及其彼此之间的联系。每个人都用一个标记为的节点表示Person。这些节点包含的属性name,gender,location和email。该网络中人与人之间的关系是这种类型,FRIENDS_WITH并包含一个yearsOfFriendship用于指定友谊连接持续时间的属性。每个人通过:LIVES_IN与带有标记的节点的关系分配一个位置Location。

图片.png
社交网络图示例

尽管这是一个非常简单的示例,但它简洁地演示了使用图形数据库的强大功能和好处。例如,如果您想向某些节点添加不同的属性,则可以。与表不同,在表中您需要为每个其他属性添加一列,在这里,您可以更加灵活地使用数据结构和类型。原本应该是字符串的属性可以不受任何限制地用作整数。公平地说,从长远来看,这可能会给您带来麻烦,但是如果需要,您可以这样做。

关系数据模型

关系数据库需要一组预定义和精心建模的表。我们为每个实体创建一个实体,然后将所需的属性添加为列。尽管这也很简单,但它比图模式更严格,并且不那么可扩展。

例如,每个人都通过友谊与其他人联系在一起,并且要建立这种关系的模型,我们必须添加另一个表。如果存在不同类型的连接(与,不再是朋友…相关),我们将不得不相应地更改架构。关系数据库不适合此特定用例,因为重点不在数据本身上,而是在其中的关系上。

图片.png
关系数据模型

何时使用图形数据库?

每个故事总是有两个方面,而图形数据库并不是解决每个问题的完美解决方案。离得很远。在很多用例中,您应该坚持使用关系数据库,或者除了图数据库之外,还应该搜索其他替代方案。

您可以问自己三个简单的问题,以决定使用图形数据库是否有任何好处。

1.我的数据是否高度连接?

图形解决方案专注于高度关联的数据,这些数据具有进行关系分析的内在需求。如果数据中的连接不是主要焦点,并且数据具有事务性,则图形数据库可能不是最合适的。有时,存储数据非常重要,不需要进行复杂的分析。

在我们的示例中,如果只存储没有关系的人,那么最终将得到一个稀疏连接的图。是的,由于节点Person和之间的连接,将保留许多更简单的图Location,但是这种连接程度和数据结构的一致性非常适合关系数据库。

2.检索数据对我来说比存储更重要吗?

图形数据库针对数据检索进行了优化,如果您选择一个数据库,则可能应该经常使用此功能。如果您的重点是写数据库,而不关心分析数据,那么图形数据库将不是一个合适的解决方案。一个好的经验法则是,如果您不想在查询中使用JOIN操作,那么图形就不是必须的。

在我们的示例中,如果仅出于记录交互作用而存储数据,并且不打算在以后进行分析,那么图形数据库并不是特别有用。但是,如果要存储的数据中有许多连接,则可能需要考虑图形。

3.我的数据模型是否经常更改?

如果您的数据模型不一致并且需要频繁更改,那么使用图形数据库可能是可行的方法。因为图形数据库比模式结构更多地涉及数据本身,所以它们提供了一定程度的灵活性。

另一方面,拥有易于理解的预定义和一致的表通常会带来好处。开发人员很自在,并且习惯使用关系数据库,这一事实不能被轻描淡写。

例如,如果您要存储个人信息,例如姓名,出生日期,位置等,而又不希望出现许多新字段或数据类型发生变化,则关系数据库是首选的解决方案。另一方面,在以下情况下,图形数据库可能会很有用:

  • 某些时候可以添加其他属性,
  • 并非所有实体都具有表中的所有属性,并且
  • 没有严格定义属性类型。

在我们的示例中,由于特定的用例,一个人的属性和关系可以一成不变,并且不需要进一步的更改。

何时不使用图形数据库?

1.当查询不包含特定起点时

如果您需要运行频繁的表扫描并搜索适合已定义类别的数据,那么图形数据库将不会很有帮助。当您有一个特定的起点或至少一组起点(带有相同标签的节点)时,图形数据库就可以很好地遍历关系。它们不适合经常遍历整个图形。尽管可以运行此类查询,但其他存储解决方案可能会针对此类批量扫描进行更优化。

如果在我们的示例中,大多数查询都包括整个网络上按属性值进行的搜索,那么图形数据库将不合适。

2.当您需要键/值存储时

很多时候,数据库用于查找 信息存储在键/值对。当您拥有一个已知键并需要检索与其关联的数据时,图形数据库并不是特别有用。

例如,如果数据库的唯一目的是存储用户的个人信息并通过名称或ID检索它,则不要使用图表。但是,如果还涉及其他实体(例如访问的位置),并且需要大量连接才能将它们映射到用户,则图形数据库可以带来性能上的好处。一个好的经验法则是,如果大多数查询都通过简单的标识符(键)返回单个节点,则只需跳过图形数据库。

3.当您需要存储大量信息时

如果模型中的实体具有非常大的属性,例如BLOB,CLOB,长文本等,则图数据库不是最佳解决方案。尽管您可以将这些对象存储为节点并将它们链接到其他节点,以利用遍历关系的功能,但有时将它们直接与它们所连接的实体一起存储更有意义。

在我们的示例中,如果每个人都有一个很长的传记,需要将其包含在同一数据库中,那么图表将无法解决问题。但是,如果您需要将这些传记与数据库中的其他实体(例如,其中提到的人)联系起来,则图形数据库的优势可能会超出限制。

图形数据库值得吗?

这在很大程度上取决于您的特定用例。在处理互连数据时,图形数据库是一个非常强大的工具。如果您很难决定,那么请遍历上述要求,并检查是否有任何适用于您的方案的要求。

在本文中,您已经了解了关系数据库和图形数据库之间的根本差异。

文章来源:https://dzone.com/articles/graph-database-vs-relational-database

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论