聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

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

2022-11-24 19:57 浏览: 2606640 次 我要评论(0 条) 字号:

摘要:大数据时代下,实时推荐引擎成为个性化广告背后的助力,而数据库更是提供了推荐依据。本文作者指出,在如今这个数据增长速度十分迅猛的环境下,关系数据库已经比不上图数据库的高效了。

接: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 节点进行任何修改。


总结


尝试新技术绝非易事,但如果不紧跟前沿技术,就有可能被竞争对手抢先。

推荐引擎使用的数据正在以秒为单位增长,市场需要真正有意义的推荐。为了提供高价值的推荐,引擎需要考虑到市场趋势以及用户在平台上执行的所有操作(浏览、评论、添加到购物车或愿望清单、删除、分享或购买)

推荐引擎不仅需要与目标用户的购物习惯保持一致,而且还需要考虑到相似购物者的习惯。由于市场的变化,我们很难预测业务需求,从而导致业务模型也会发生变化。图数据库可以轻松适应任何必要的变更。

最后,如果由于数据过多而导致推荐引擎无法正常运转,公司的业务发展也因此受到了阻碍,那么从关系数据库迁移到图数据库将是一个明智的选择。

☞Windows 11 的开始菜单都要加广告了?网友:微软你清醒一点!
久未更新的老化工具,遍布在 82% 的开源项目里
让阿根廷队“告吹”的三个球背后,2022 年世界杯暗藏哪些技术玄机?



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复