数据元建模(图数据建模超级节点)

本文是先进图形建模的最新系列;该系列中的其他文章处理键,关系和分类变量。

今天我们将谈论超级节点,他们是什么,他们造成的问题,以及这些问题。本文是这些问题的摘要和循环以及他们如何触摸Neo4j。

数据元建模(图数据建模超级节点)(1)

> Super nodes! But not to the rescue

本文将涵盖它们是什么,它们是如何发生的,以及我们能做的事情。让我们开始吧。

什么是超级节点?

超级节点是遇到很多关系的任何节点。有多少关系?那不是真正定义的,所以让我们称之为很多。如果一件事与其他节点相比有关的关系,相对于图表中的其他节点,可以将其称为超级节点是公平的。多少方式太多了?那真是一个主观的东西,因为每个人都在运行具有不同内存配置和查询模式的机器。

数据元建模(图数据建模超级节点)(2)

发现超级节点并不难。如果您正在可视化图形以及您获得的内容是一个“毛球”,那么似乎与其连接到一切的密集连接节点可能是超级节点。

超级节点将头发放入毛球中。

在极端情况下,您甚至无法想象超级节点,因为如果您在节点上真正有数百万个出站关系,则可视化将只是一个混乱的黑色,具有太多重叠线来查看任何内容。

超级节点如何发生?

有两个关键原因:它们可以从您建模的域中出现,或者从域的建模选择中出现。

来自域本身:密集连接的网络

想象一下,我们将Twitter建模为一个图形,在彼此之间的帐户之间存在关系。我们知道流行的帐户有许多追随者,所以在那种图形结构中,Lady Gaga的节点将有8200万 关系。这是非常超级的,因为普通用户有700个粉丝。

数据元建模(图数据建模超级节点)(3)

> Lady Gaga the Super node was born this way (as a super node, not as a motorcycle)

密集连接的网络的另一个例子可能是(:Flight)-[:DEPARTED_FROM]->(:Airport)。亚特兰大的Hartsfield-Jackson机场每年可以很容易地完成200,000多个航班。这是很多 [:DEPARTED_FROM]->关系。

许多其他商业域具有大量的例子:

  • 长期存在的大公司银行账户,每天做数百或数千财经交易(:Account)-[:TRANSFER]->(:Account)。
  • 其他社交网络,就像这些技术招聘人员一样,您可以在LinkedIn上知道似乎有一个Zillion联系人。
从您的建模选择:分类变量过载

在上一篇文章中,我写了关于分类变量并在Neo4j中建模它们。分类变量只是一个可以采取少量价值的属性。变量的“基数”是指它可以具有多少不同值。

示例:想象一下您将客户填充作为单独节点的性别字段。这是低基数,因为唯一的选择可能是男性,女性,没有指定等。现在假设您拥有100万客户账户,然后我们可以确定,(:Gender)节点将是超级节点,如果将图表建模为(:Customer)-[:GENDER]->(:Gender)。

性别只是一个例子;它是一个常规问题,具有低基数变量,被建模为节点,当您有大图时,需要参考变量的数百万节点。Imagine Amazon.com占据了一些产品类别(“家庭和花园”,“电子”,“健康与健康”),并将他们的几以千万件产品联系在一起的节点 - 同样的情况。

数据已经超过了模型

通常,您通常有一个简单的图形模型,它在一个小型数据集上工作,但您可能无法进行缩放,即在完整的生产数据中,或者随后随着时间的时间而增加,您可能会缩放。想象一下客户/性别例子;与1000名客户来说并不是一项大笔交易,可能是一个拥有1000万客户的杀手。同样,Lady Gaga的账户可能在Twitter上不是2013年的问题,但这是一亿用户前。

在建模中,请注意,超级节点问题将来自基数不匹配;如果每个产品都需要一个类别,而且产品有一系列的说法,2000万和类别的基数12,这种大规模的错配可能与有类别一样多的超级节点。可以看到相同的模式(:X)-[:RELATED_TO]->(:Y) ,其中x和y的基数是不匹配的。

如果您的数据超过了模型,则是重构模型的时间。

为什么超级节点不好?

麻烦是他们分支的速度,给我们太多的途径来考虑。简单地说,这是一棵树的叶子很容易找到树干。树干找到一个单独的叶子更难。让我们来看看他们伤害阅读性能的某种方式。

吹掉你的绊倒

假设你写了一个这样的查询:

MATCH (bob:TwitterUser { name: "bob" }) WITH bob MATCH p=(bob)-[:FOLLOWS*]-(:TwitterUser { name: "karla" }) RETURN p

这就要求鲍勃和卡拉之间的所有路径。如果有人跟随Lady Gaga,这个查询将是一场灾难,因为为了让Neo4J回答查询,它必须分支出来潜在的8000万其他账户。Karla的路径数将爆炸;Bob和Karla都可以住在纽约市,但放心,这个查询需要看看Gaga的每个立陶宛语和韩国风扇(以及他们所有的追随者,以及他们的追随者追随者,等等)返回。

数据元建模(图数据建模超级节点)(4)

> Listen to Boromir, he knows what’s up

放慢其他读

另一个问题是关系过滤;neo4j(如4.1版本)不支持关系属性上的辅助索引。想象一下查询,找到2020年获得的所有追随者Gaga。

MATCH (gaga:TwitterUser { name: 'ladygaga' })<-[r:FOLLOWS]-(u:User) WHERE r.date > date('2020-01-01') RETURN u.name, u.followers

此查询必须考虑所有8000万 关系,因为您无法在关系上索引日期数据类型。当您需要在多个步骤的路径上使用关系过滤时,这成为更大的交易,其中任何电位步骤可以通过超级节点运行。

减慢写

正如NEO4J 4.1的那样,当您将关系合并到图形中时,它会暂时锁定源和目标节点以用于该事务。这对Lady Gaga来说非常糟糕,因为我们要把新的[:FOLLOWS]在她的下一张专辑下降时会这样做。当我们添加新的关系时,她锁定在世界其他地区,这将导致她的国际粉丝患者中的其他地方存在问题。

Dzone上的这篇文章涵盖了一些其他有趣的方面的性能影响,如果您想跟进更详细的情况。

并不总是世界末日

有一些情况,超级节点可以说不重要。

  • 如果超级节点位于路径的末尾,并且您不会遍历它,它不会产生太大的影响。
  • 如果它不是高交易速率查询的一部分或多用户更新,超级节点可能是无害的。
好的,那我们该怎么办?

这是一个有点艺术和一点科学 - 你最好的答案取决于你的域名,但这是一个工具箱,可以从你的图表中获得最大的技术。这些技术范围从简单到困难。

  • 关系方向性
  • 加入提示
  • Lucene关系索引
  • 标签和关系隔离
  • 超级节点重构

我们将详细介绍这些中的每一个,但实际上它们都归结为两类方法 - 要么帮助数据库运行查询时会考虑更少的关系,(使超级节点减去超级节点),或者尝试分解或者首先消除超级节点。一些技术是两者的组合。当然记住:你不必选择一种方法,随意混合和匹配。

关系方向性

Cypher允许美国快递路径作为无向(:User)-[:FOLLOWS]-(:User) 或按照指示(:User)-[:FOLLOWS]->(:User)。始终使用定向路径,因为它会削减您的查询需要考虑多少个关系。

您可以利用您对具有超级节点的方向性的信息。Lady Gaga拥有8000万个粉丝(即入境:遵循关系),但她只关注121,000个账户(出境关系)。实际上,当你想到这一点时,这是她所关注的多少人疯了,但仍然 - 这两个查询之间存在剧烈差异:

(:User)-[:FOLLOWS]-(:User { name: "ladygaga" })(80万 关系)

(:User)<-[:FOLLOWS]-(:User { name: "ladygaga" }) (121,000个关系)

数据元建模(图数据建模超级节点)(5)

> Keanu learns about one of the super node’s key weaknesses

联结提示

在这个知识库文章中,Andrew Bowman阐述了如何使用Cypher的Join hint来限制Cypher如何进行图形遍历。如果您知道图表中有一些超级节点,则可以使用此技术来确保Neo4j的查询评估不会进入该遍历问题。

这是重新覆盖整篇文章,这是关键位,简要说明这是如何工作的:

MATCH (me:Person {name:'Me'})-[:FRIENDS_WITH]-(friend)-[:LIKES]->(a:Artist)<-[:LIKES]-(me) USING JOIN on a RETURN a, count(a) as likesInCommon

此构造使用连接确保Cypher只能遍历:艺术家节点,但从未通过或远离它。如果有问题的艺术家是Gaga,这将是一个很好的技术,她有8000万粉丝。

有关此技术的详细信息,请选中Cypher手册的Planner提示部分。

Lucene关系索引

在较早的部分中,我说Neo4J不支持关系属性索引。这几乎是真的。实际上有一个特例。可以使用Lucene在关系上索引文本属性。

使用此文档此处,您可以调用:

CALL db.index.fulltext.createRelationshipIndex("taggedByRelationshipIndex",["FOLLOWS"],["date"], { eventually_consistent: "true" })

假设DATE属性:遵循的日期属性是一个字符串,您可以使用它来过滤关闭(利用索引)的关系,在某些有限的情况下,可以帮助解决问题。这不是超级节点问题的银弹。和呀,我们需要将日期视为一个字符串而不是很大,以便使其工作。

标签和关系隔离

接近超级节点问题的另一种方法是各个密集连接的节点(如Lady Gaga)看起来像图表的其余部分,但实际上它们是特殊情况。Twitter上大多数人(Coughcough)没有8000万追随者。因此,我们可以通过以不同方式标记图来分离图表中的超级节点。如果我们推出新标签怎么办?

数据元建模(图数据建模超级节点)(6)

> Lady Gaga: Kinda not like the regular average node in the graph, kinda special case

  • (:TwitterUser)为像我这样的普通的schmoes
  • (:Celebrity) or (:VerifiedUser)为超级账户

这将使我们的遍历更容易,因为如果我们希望,我们仍然可以指定通过所有节点,但如果他们被不同地标记,我们可以轻松地将名人排除在我们的遍历中。

相同的关系 - 而不是以不同方式标记节点,我们可以以不同方式标记关系:-[:FOLLOWS]->用于定期用户到用户关系,以及 -[:FAN]-> 用于与名人的未被划分的关系。

请注意,这对我们之前的查询示例是什么:

MATCH p=(:TwitterUser { name: "bob" })-[:FOLLOWS*]-(:TwitterUser { name: "karla" }) RETURN p

如果我们刚刚介绍了-[:FAN]->关系类型,突然这个查询看起来非常非常不同,我们不需要考虑女士Gaga。如果由于某种原因我们确实想要包括她,那么改变是微不足道的:

MATCH p=(:TwitterUser { name: "bob" })-[:FOLLOWS|FAN*]-(:TwitterUser { name: "karla" }) RETURN p

差异是简单的 -[:FOLLOWS|FAN*]->

这种方法的缺点是它仅适用于自然密集地连接的域。如果我们的问题是一个分类变量((:Gender) 你就无法通过这种方法摆脱这个问题。它所作的原因是因为我们可以将一小部分(:Celebrity)分离出我们更大的图表。当所有(:Gender)节点都是超级节点时,这将不会起作用。

超级节点重构

可能是最棘手的方法是重新推荐您的图形将单个超级节点分解为多个节点。你可以带走Lady Gaga的单一节点并将她闯入,说,1,000份Gaga。创建一系列等价关系,即(GAGA1:Twitterser) - [:smot_as] - >(gaga2:twitteruser),然后有一个策略用于在1,000个“gaga克隆”之间分发您的应用程序关系。

这是一个最后的度假略有战略。

虽然有几个原因,它只能有助于某些查询模式:

  • 如果需要了解Gaga的所有内容,则需要重写查询以便能够考虑相同的关系,而不仅仅是触摸该节点的本地克隆。
  • 如果你需要穿过Gaga,你仍然在同样的情况下;在遍历所有克隆后,您仍然最终得到8000万 的总基数,具体取决于查询。
  • 选择和实施用于在“GAGA克隆”之间的关系并保持平衡之间的策略更复杂,使得其中一个克隆不会逐渐增长成为自己的超级节点,因为GAGA随着时间的推移吸引了更多的粉丝。
结论

将所有这一切缠绕在一起,这里是要记住的关键点:

  • 超级节点是在图中密集连接的那些,相对于图中发现的平均值有很多事件关系。
  • 超级节点很糟糕,因为它们会损害读写性能。
  • 超级节点来自几个不同的地方,但大多数通常来自您域名的自然复杂性,以及您的建模选择。
  • 您在工具箱中获得了一堆不同的工具来解决问题,并且对于高级图形建模,这是一个问题,你肯定想要了解从你的图表中获得最佳性能。

(本文由闻数起舞翻译自Shradha Samantray的文章《Graph Modeling: All About Super Nodes》,转载请注明出处,原文链接:https://medium.com/neo4j/graph-modeling-all-about-super-nodes-d6ad7e11015b)

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页