下载掌阅APP，畅读海量书库
立即打开
透过一个C360应用程序，让我们思考一下关系型数据库与图数据库的实现的优劣。在评估这两种技术时，我们将在四个领域对它们进行比较。我们将研究每种技术在数据建模、表示关系和查询语言方面的方法。
在比较关系型数据库和图数据库在数据建模方面的差异时，需要考虑量化及主观的维度。围绕数据模型设计的定量论证将指向关系型系统，因为关系型系统的资源量和生产环境使用量更大，是明显的赢家。关系型系统在技术、技巧和优化各个方面都有完备的文档，供开发团队中的所有成员和各种职能使用。
从更主观的角度来看，使用图技术的数据建模技术明显更直观。具体来说，当使用图技术时，人类对计算机的数据转换被保留下来，你对数据的思考方式与在计算机中的数字化表示方式几乎相同。这种从人类直觉到机器表示的更简单转换，能够激发你从数据的关系中提取更深的见解。也可以说使图技术比关系型数据库中的相同实现所需的系统设计更容易使用。
在数据库中建模和存储关系的需求一直在增长，并将持续增长。这给关系型系统同时带来了好消息和坏消息。好消息是，如前所述，用关系型技术建模的提示、技巧和技术都有良好的文档。在现有的关系型数据库添加关系可以像添加一个连接表或外键约束一样简单。有了新的连接表或外键，关系可以被查询和访问。从本质上讲，将数据录入这些系统有文档可查，对开发者来说也相对容易。
而坏消息是，想以看得懂的方式从关系型系统中取回关系数据就有些难度了。由于从想法到实现再到机器的巨大差异，理解存储在关系型系统中的关系是非常困难的。与图技术相比，从讨论到建模再到解释模型的过程，在关系型技术中显得更加脱节。这种脱节在于将人类对数据的理解映射到关系型模型和表格中所需要的思维转换。这种转换需要大量的思维解释，以追寻和理解存储在关系型数据库中的数据关系。
这种差距激发了图技术的产生。如果需要对数据中的关系进行建模和理解，图技术提供了数据从人类理解到机器表示的双向无缝切换。选择这条路的决定因素是，你的数据中是否存在关系，并且这些关系对更深入的分析和推理是否有用。如果你需要对数据中的关系进行建模和推理，那么图技术就是你要走的路。
在比较两个系统的查询语言时，我们想考察三个方面：语言复杂性、查询性能和表达能力。
首先，让我们来谈谈我们所说的语言复杂性是什么意思。将关系设计纳入系统后，在评估架构中的数据库时，查询语言引入了额外的复杂性。在这个层面上，查询语言会凸显所有实现过程中的复杂性或简洁性。随着查询的开发和扩展以将所需的数据拉到一起，会遇到额外的复杂性。
团队通常通过查询开发时间、可维护性和知识转移的便利性来衡量查询语言的复杂性。当对比SQL和Gremlin时，这些比较归结为采用广泛度和个人偏好。在语言成熟度方面，SQL显然是赢家。然而，在深度嵌套查询或需要大量连接的查询中，天平则向Gremlin倾斜。
接下来对查询语言的评估是度量查询性能。查询性能度量的是数据库优化工作的多方面复杂依赖关系，包括索引、分区、负载平衡以及更多本书无法涵盖的优化措施。
当范围限定在一个小型部署中的C360应用程序时，很可能一个有适当索引的关系型系统的查询性能会优于图数据库。这是因为简化的C360应用程序查询是非常浅的图查询；查询会停留在客户的第一个邻接点范围内。随着图查询的深入，就像我们将在第4章看到的那样，图技术和关系技术之间的性能天平就会严重倾向于图解决方案。
最后一个对比是考虑查询语言的表达能力。根据我们的经验，图查询语言的表达能力强化了在应用中使用图数据的能力。这两个系统之间的查询复杂性的差异说明，像Gremlin这样的表达能力更强的语言很大程度上提升了查询系统中的关系的能力。基于图数据库的图查询语言可以大大减少访问和从数据中提取关系所需的代码。但想要图技术成熟到与关系型标准相同的水平，我们还需要一些时间。
我们做一个简单的总结，为每个选项提炼出一些点，如表3-2所示。
表3-2：为C360应用程序选择关系型或图数据库时的考虑因素摘要
对于这两种技术的可以比较的任何领域，每一种选择的优势和劣势都可以归结于成熟度。与图技术相比，关系型技术的采用、文档和社区的发展要好得多。这种成熟度可能转化为传统应用的低风险和快速执行。迄今为止，图技术在成熟度和新应用的交付时间方面，还无法与关系型技术竞争。
而另一方面，关系型技术在提供对数据内部关系的有价值的洞察力方面已达到极限。这是一个重要的问题，因为关系自然而然地出现在数据中，并有助于提供更佳的业务洞察力。在这方面，对于需要依赖关系来做出商业决策的应用，图技术是更好的选择。它是在你的数据中提供和推理关系的最佳选择，这在深度和规模上是关系型数据库无法实现的。