推荐引擎中的数据迅速增长，并且可能变得非常复杂。像亚马逊这样的网站每个月都有超过1.7万用户，每隔几分钟就购买了4000件商品。对于关系数据库来说，存储所有数据可能不是问题，但是查询并找到有用的信息来提出建议可能是一场缓慢而痛苦的SQL噩梦。

不再足够知道某些用户，评论和产品之间存在联系。要拥有真正准确且适应性的推荐引擎，需要解剖这些关系才能提取其意义，影响力和体重。为了发现这些关系，更不用说分析它们了，由于大量（递归）联接操作而对关系数据库造成了压力。幸运的是，图数据库不需要识别连接 - 实体及其关系是图形数据库的构建块。

，如果您的业务模型在首次构建时未预见的方式在任何时候变化，则图形数据库可以轻松处理这些更改，因为它们在建模数据中的灵活性。

由于将焦点转移到图形数据库中的关系，与关系数据库相比，查询它们以找到有用的建议变得更加容易，更快。查看您最终如何停止考虑加入，并开始考虑您的客户实际需要购买的东西。

易于建模数据

在关系数据库中，通过创建多个表代表实体属性，包括一个唯一的键，可以通过与数据库中的其他表连接连接每个表。绘制关系数据模型和白板上的关联表有些挑战，但是熟悉其业务需求的任何人都可以使用图数据模型，即使它们对数据科学的分布不佳。

图数据库具有节点（顶点）和这些节点之间的关系（边缘），作为两个主要实体。有关每个节点的信息保存为其属性。因此，如果数据由产品，用户和评论组成 - 这些都是带有不同标签和属性的节点 - 产品的名称，品牌，尺寸和价格。用户看这些产品，将它们放在篮子里，购买，对它们进行评分或退还它们，并在自己与产品之间形成不同类型的关系。

为了在零售业中实现建议系统，关系数据库需要定义数据库模式并设置表，一个用于用户的表，一个用于产品的表，一个用于评级。表中的每一行都有一个唯一的键，该键存储在另一个表行中，作为显示连接的属性。模式看起来像这样：

有了大量的数据和一个比这个简单示例更多的表格的系统，很难理解表之间连接的性质。如果模型中的任何内容都会更改，我们需要返回模式重新排列内部工作，然后更新所有表和进程。

图形数据库中的节点之间的相互作用与数据存储和查询的方式对齐，以为建议引擎提供最佳结果。图形通过提供一种手段来以比关系数据库更好的方式表达实体之间的连接，从而有助于开发业务模型的准确表示。此外，它们为系统提供了急需的灵活性。

在大多数图形数据库中，数据库架构不是必需的，因此开始导入和更新数据要容易得多。节点和关系是在数据存储在数据库中的同时创建的。

用户创建一个配置文件帐户后，将创建带有标签USER的节点以及定义特定用户的属性。用户可以创建他们出售的产品，并使用标有PRODUCT的节点更新图形模型。 USER和PRODUCT节点与关系:SELLING相连。用户还可以购买产品并对其进行评分。在这种情况下，使用类型BOUGHT或与关系类型的:RATED以及实际额定值作为其属性之间形成了USER节点和PRODUCT节点之间的关系。图架构看起来像这样：

即使是快速浏览的，它们之间的所有实体及其之间的关系也立即清晰，可理解。

与关系数据库相比，与不同节点之间的关系创建的网络正是使研究和获得洞察力更加轻松，更快的原因。

推荐产品-SQL查询与Cypher查询

基于上一章中的数据模型（重要的是要指出它们比现实生活中的模型要复杂得多），让我们尝试创建一个可以推荐产品的查询对于某个以前没有购买该产品的用户。该建议将基于他们给予最高评级的产品，所有其他审查与目标用户相同产品并给予最高评级的用户也是如此。这也是引擎可以使用的简单查询推荐之一，因为它们可以通过社区检测，计算Pearson相关系数和机器学习更深入地进行挖掘。

要编写SQL查询，需要使用复杂的联接操作连接表。 SQL查询看起来像这样：

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

联接操作容易出现错误，缓慢且计算昂贵。每个加入操作的时间复杂性的时间为 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.id
RETURN pB;

通过图中的节点搜索的过程称为图形遍历。图形遍历的复杂性是 o（k），其中 k 是一个节点与其他节点具有的连接数。高优化是无索引邻接概念的结果，这是图形时要理解的最重要概念之一。在图中寻找相邻节点时，图数据库执行指针跳跃，即直接步行的内存 - 查看关系的最快方法。为了启用直接步行记忆，将关系存储为直接物理公羊地址。最重要的是，在创建数据而不是查询时建立了关系。

图形数据库不必使用任何其他数据结构或索引来从任何节点跳到相邻节点。在设计推荐引擎时，用户和购买的产品之间的连接将被明确添加为固定的物理公羊地址。增强性能的原因是，将相关节点彼此存储在内存中，从而最大程度地增加了数据在需要时数据已在CPUS缓存中的机会。

research表明，使用图形数据库的三个连接的用户向用户推荐产品比使用关系数据库快的速度要快180倍以上。

灵活性

关系数据库依赖于在数据库本身之前创建的预定架构。一旦发生意外或计划外的事情，关系数据库的模式显示了其真正的刚性面孔。在零售业务中，推荐引擎发挥着至关重要的作用，很难预测市场，因此平台将如何发展和变化。

例如，您的公司出售船只，您在该数据的基础上构建了推荐引擎。有一天，您想扩大业务并开始销售将补充船提供的捕鱼设备。使用关系数据库，您需要在基础上重新考虑关系数据库，因为必须遵循该信件。否则，将不会存储任何进入数据库但不适合使用的数据。因此，如果该模式不预测产品具有厚度，这是钓鱼线的非常重要的属性，而是在讨论船只时经常提出的话题，则需要重新设计该模式。

如果您采用简单的出路，只需添加所有可以应用于所有产品的属性，则其中一些必须具有无效的价值，因为钓鱼设备不能由诸如发动机电源等属性定义或船类型，而船只通常由任何东西的厚度定义。首先，您是在浪费内存，但是您还通过添加另一个过滤船来添加更多的复杂性，或者是避免由无效属性引起的页面断路的其他检查。

如果您选择忽略问题并显示所有属性，那么建议看起来很愚蠢且不专业。看看这个现实生活中的例子，其中一个架子被描述为男女通用，因为零售商主要专注于销售服装，并且没有使数据库适应销售家庭用品。

更好的解决方案是通过创建一个用于存放船只的桌子和另一个用于存放钓鱼设备的桌子来更新数据库模式。但是，您还需要在用户表中添加一个附加属性，以将捕鱼设备的独特钥匙以及船上的独特钥匙以及来自船只的独特钥匙存储。如果没有有关唯一键的信息，则可以连接两个表。

如果您的业务不断增长和扩展，则每次决定处理新型产品时，您都会面临这个确切的问题。这意味着用户的另一个表和另一个属性列。当然，这只是一个虚拟的示例，您绝对可以更好地改善数据库方案。但是，如您所见，当您使用关系数据库时，您需要解决许多技术细节和未来问题。一切都很快变得凌乱。

所有这些耗时的变化和突然系统辐射的可能性，因为未涵盖某些方案通过使用图形数据库最小化。

图形数据库没有预定义的模式，这意味着您可以使用数据库中不存在的标签和属性创建节点。您也可以将它们连接到现有节点，而无需破坏任何内容或对现有数据进行任何更改。那太棒了吗？

使用Graph数据库，您可以随时输入新的更改，而不会冒着当前功能的完整性的风险，而不是预先进行广泛设计域。

让我们以相同的例子为例，以销售和推荐钓鱼设备的新业务需求，但在图形数据库中。当您的平台决定开始销售钓鱼设备时，在创建一个新的PRODUCT节点时，您需要添加另一个标签，让我们说的FISHING_EQUIPMENT具有您需要定义该产品的属性，仅此而已，您就可以了。

您平台上的用户可以开始购买钓鱼设备，建议引擎将其包含在其算法中。购买时，在客户和产品之间建立了关系，而没有对CUSTOMER节点或FISHING_EQUPIMENT节点进行任何更改。

结论

尝试新事物绝非易事，但是如果您不在他们的最前沿，那么您的竞争可能就是。推荐引擎使用的数据增长了第二，市场要求真正有意义的建议。为了获得高价值建议，它们需要受到市场趋势以及用户在平台上所做的任何行动的影响（浏览，审查，添加到篮子或愿望清单，删除，共享或购买）。

发动机不仅需要与目标用户的购物习惯以及具有相似习惯的购物者的习惯保持一致。由于市场的变化，业务需求也不容易预测使业务模型变更。图数据库可以轻松适应任何必要的修改。而且，如果您的推荐引擎变得超过其处理能力和复杂查询的更多数据，这些查询和复杂的查询会导致公司的繁荣，那么从关系数据库转变为图形数据库应该是不明智的。