对实时推荐引擎来说，关系数据库已过时，图数据库才是王道

择要：年夜数据期间下，及时保举引擎成为个性化告白背后的助力，而数据库更是提供了保举根据。本文作者指出，在现在这个数据增加速率十分迅猛的情况下，关系数据库已经比不上图数据库的高效了。

链接：https://memgraph.com/blog/faster-recommendations-with-graph-databases?continueFlag=7773e661db7a5655443a7c4ae921524d

声明：本文为 CSDN 翻译，未经容许制止转载。

作 者 | Niko Krvavica

译者 | 弯月 责编 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

保举引擎中的数据增加速率十分快，并且会变得异常繁杂。例如亚马逊等网站每月的用户拜访量跨越 1.97 亿次，每隔几分钟就有 4000 件商品被购置。

对付关系数据库来说，存储这些数据并不成问题，但查询有效的信息并天生保举可能成为一个迟缓而痛苦的 SQL 噩。

只清晰某些用户、评论和产物之间存在的接洽远远不够。想拥有一个十分精确且顺应性异常强的保举引擎，我们就必要剖析这些关系，提取它们的紧张性、影响力和权重。就算姑且岂论阐发，只发现这些关系就必要年夜量（递归的）JOIN 操作，终极给关系数据库带来压力——荣幸的是，图数据库不必要辨认衔接，由于实体及其关系是图数据库的根本模块。

无论何时，即便营业模子以某种没故意料到的方式产生变化，图数据库也可以轻松处置，它具有异常机动的数据建模。

因为图数据库的重心是关系，是以与关系数据库相比，查找图数据库并天生保举信息会加倍容易，速率也更快。你无需斟酌若何编写 JOIN 语句，只必要斟酌客户现实想要购置什么。

数据建模更容易

在关系数据库中，数据是经由过程创立多个表来存储的，此中每一列代表实体的一个属性，包含独一的键，每个表都可以使用 JOIN 与数据库中的其他表衔接。在白板上绘制关系数据模子以及联系关系的表异常有难度，但任何认识营业需求的人都可以使用图数据模子，纵然他们并不精晓数据科学。

图数据库包括两个主要实体：节点（极点）和节点之间的关系（边）。每个节点的信息都作为属性保留起来。举个例子，假设数据由产物、用户和评论构成，这些都是具有分歧标签和属性的节点，好比产物包括名称、品牌、尺寸和价钱等信息。用户查看这些产物，并将它们放入购物车、购置、评价或退货，如许用户和产物之间就会形成分歧类型的关系。

假如想在零售范畴实现一个保举体系，关系型数据库必要界说数据库模式并创立各类表：用户表、商品表、评分表等等。表中的每一行都有一个独一的键，该键可作为属性存储在另一个表中，以表现两个表之间的衔接。这里的数据模式绘制成图形，年夜致如下：

这个示例异常简单，相较而言实际生涯中体系包括的数据量和表远不止这么多，懂得表之间衔接的本色是一项异常艰难的事情。假如模子产生任何变化，我们还必要重审模式以及内部的关系，然后更新所有表和流程。

在图数据库中，节点之间的交互建模与数据的存储和查询方式同等，可认为保举引擎提供最佳成果。图数据库提供了一种比关系数据库更好的方式来表达实体之间的接洽，是以有利于开发精确的营业模子。此外，它们还为体系提供了异常需要的机动性。

在年夜多半图数据库中，数据库模式不是必须的，是以导入数据和更新数据的难度更小。节点和关系是在数据存储到数据库时创立的。

用户创立小我账号时，体系会创立一个带有标签 USER 的节点以及界说特定用户的属性。用户可以创立他们贩卖的产物，图模子会更新所有带有 PRODUCT 标签的节点。节点 USER 和 PRODUCT 之间经由过程关系衔接：SELLING。用户还可以购置产物，并对其进行评分。这时，节点 USER 和 PRODUCT 之间就形成了另外两种关系，分离为 BOUGHT（购置）或 RATED（评分）。图数据库的模式如下所示：

如你所见，实体与它们之间的关系清楚了然。

与关系数据库相比，经由过程图数据库反省和深刻相识数据的难度更低，速率更快，恰是由于分歧节点之间树立的这种关系网。

保举产物：SQL 查询与 Cypher 查询

下面，我们依据上述数据模子创立一个查询，向某个用户保举某个产物。我们的保举基于以下信息：用户赐与最高评分的产物，以及阅读雷同产物后同样给出最高评分的其他用户。这也是保举引擎可以使用的最简单查询之一，由于这个查询可以经由过程社区检测、计算皮尔逊相关系数和机械进修进行更深刻的发掘。

这个 SQL 查询必要使用繁杂的 JOIN 操作衔接表，如下所示：

select B.* from user User1join rating Rating1 on User1.user_id = Rating1.id and Rating1.value = 5join product A on A.id = Rating1.product_idjoin rating Rating2 on Rating2.product_id = A.id and Rating2.value = 5join user User2 on User2.id = Rating2.user_id and User2.id <> User1.idjoin rating RatingB on RatingB.user_id = User2.id and RatingB.value =5join product B on B.id = RatingB.product_idWHERE User1.id = 1;

JOIN 操作很容易失足，并且速率很慢，计算量年夜。每个 JOIN 操作的光阴繁杂度为 O(M * log(N))，此中 M 代表一个表中的记载数，N 代表另一个表中的记载数，这意味着我们必要扫描两个表中的所有行，并测验考试经由过程独一的键衔接二者。跟着保举引擎中数据的增加，必要衔接多个表的查询和阐发将越来越繁杂，关系数据库的速率也会越来越慢。

每个图数据库都使用本身的查询语言，而在图数据库的天下中，最常用的语言是 Cypher。获取雷同成果的 Cypher 查询如下所示：

MATCH (pA:PRODUCT)<-[r1:Rated {"大众rating"大众:5}]-(n1:USER)-[r2:Rated {公众rating"大众:5}]->(pB:PRODUCT)MATCH (n2:USER {id:1})-[r3:Rated {公众rating"大众:5}]->(pb)WHERE n1.id != n2.idRETURN pB;

在图中搜刮节点的进程称为图遍历，图遍历的繁杂度为 O(K)，此中 K 代表一个节点与其他节点的衔接数。高度优化是无索引毗邻观点的成果，这是图数据库最紧张的观点之一。在查找图中的相邻节点时，图数据库会执行指针跳跃，即直接遍历内存，这是最快的查看关系的方式。为了直接遍历内存，关系会以物理 RAM 地址的情势存储起来。最紧张的是，关系是在创立数据时创立的，而不是查询时。

图数据库不必使用任何其他数据布局或索引，即可从随意率性节点跳至相邻节点。在设计保举引擎时，用户和他们购置的产物之间的衔接会作为固定的物理 RAM 地址保留起来。而将相枢纽关头点存储在相邻的内存地址内，可以进一步晋升机能，从而最年夜限度地进步数据缓存到 CPU 的概率。

研讨注解，使用图数据库向相距三个衔接的用户保举产物的速率，比使用关系数据库快 180 倍以上。

机动性

关系数据库依附于之前所创立的预定模式，一旦呈现不测或方案外的状态，关系数据库的模式就无法机动应对。但在保举引擎起着症结作用的零售营业中，我们很难猜测市场和平台的成长与变化。

举个例子，假设有一家贩卖船只的公司，在现稀有据之上构建了一个保举引擎。有一天，你想扩展营业，开端贩卖打鱼装备。假如你使用的是关系数据库，则必要从新斟酌整个数据库，由于你必需严厉遵照已有的数据模式。不然，任何不匹配模式的数据都无法存储。是以，假如原有模式不具有垂纶线一个异常紧张的属性——粗细（不是船只属性），则必要从新设计模式。

为了低落事情量，你可以添加可利用到所有产物的所有属性，但此中一些属性将是 NULL 值，由于打鱼装备没有动员机功率或船型等属性，而船只通常没有粗细等属性。但如许做的问题在于，起首会造成内存挥霍，其次你还必要添加一个过滤器来过滤失落船只，或者要经由过程额外的反省来避免由 NULL 属性引起的问题，这势必会加剧代码的繁杂性。

假如你选择疏忽这些问题，直接显示所有属性，天生的保举就会显得很愚蠢且不专业。看看如下这个真实的例子，因为零售商的主要营业是贩卖服装，并没有调整数据库中的家居用品贩卖，是以“性别”属性为“男女咸宜”的架子就呈现在了保举列表中。

更好的办理计划是，更新数据模式，经由过程一个表来存储船只，另一个表来存储打鱼装备。然则，你还必要向 USER 表添加一个附加属性，以存储打鱼装备的独一键以及船只的独一键。假如没有独一键的信息，你将无法衔接两个表。

跟着营业进一步扩大，每次添加一种新型产物，你都将面对统一个问题。也便是说，你必要新建一个表，并添加一个属性列。当然，这只是一个示例，你可以更好地改良数据库模式。然则，正如你所见，使用关系数据库时，我们必要办理许多技术细节和问题。

反之，假如使用图数据库，我们就可以将这些繁琐的变革减到最小，并将因为未涵盖某些场景而导致体系突然瓦解可能性降到最低。

图数据库不必要预先界说模式，这意味着，你可以使用数据库中不存在的标签和属性创立节点，还可以将它们衔接到现有节点，而无需破坏现有节点或对现稀有据进行任何变动。

使用图数据库，你可以随时输入新的变革，而不会破坏现有的功效。

下面，我们尝尝看应用图数据库处置上述新的营业需求：贩卖和保举垂纶装备。假如你的平台决议开端贩卖垂纶装备，那么在创立新节点 PRODUCT 时，你必要添加另一个标签：FISHING_EQUIPMENT 。

如斯，用户就可以开端购置垂纶装备，保举引擎也可以将这项新营业纳入算法中。用户在购置垂纶装备时，就会创立一个二者之间的关系，而你无需对 CUSTOMER 节点或 FISHING_EQUPIMENT 节点进行任何改动。

总结

测验考试新技术绝非易事，但假如不紧跟前沿技术，就有可能被竞争敌手争先。

保举引擎使用的数据正在以秒为单元增加，市场必要真正故意义的保举。为了提供高代价的保举，引擎必要斟酌到市场趋向以及用户在平台上执行的所有操作（阅读、评论、添加到购物车或希望清单、删除、分享或购置）。

保举引擎不仅必要与目的用户的购物习气坚持同等，并且还必要斟酌到类似购物者的习气。因为市场的变化，我们很难猜测营业需求，从而导致营业模子也会产生变化。图数据库可以轻松顺应任何须要的变革。

末了，假如因为数据过多而导致保举引擎无法正常运转，公司的营业成长也是以受到了阻碍，那么从关系数据库迁徙到图数据库将是一个明智的选择。