关系图和图表图哪个最适合你的数据库

在结构化关系数据库模型和“非结构化”图形模型之间进行选择越来越不是一个非此即彼的命题。对于某些组织来说，最好的方法是使用标准的关系运算符来处理它们的图形数据，而对于其他组织来说，将它们的关系数据迁移到图形模型会更好。

传统观点认为，关系就是关系，图形就是图形，两者永远不会相遇。事实上，关系数据库和图形数据库现在经常会相遇，两者都可以因此变得更好。

“非结构化”图形数据与关系模式和平共存的最常见场景是将图形内容放置在关系数据库表中。麻省理工学院计算机科学和人工智能实验室(CSAIL)的阿列克·金达尔(Alekh Jindal)在2014年7月9日发表在英特尔大数据科学技术中心博客上的一篇文章中指出，大多数图形数据源自关系数据库管理系统。

金达尔建议应用关系数据库的图形分析特性，而不是从关系数据库管理系统中提取图形数据导入图形处理系统。当图形在RDBMS中存储为一组节点和一组边时，可以应用内置的关系运算符(如选择、投影和连接)来捕获节点/边访问、邻域访问、图形遍历和其他基本图形操作。这些基本操作的结合使得更复杂的分析成为可能。

类似地，存储过程可以用作驱动程序来捕获图形算法的迭代操作。将图形分析表示为SQL查询的缺点是，在节点和边的表上进行多次自连接会导致性能下降。 RDBMSs的查询流水线和其他并行处理特性可以用来减轻任何由此产生的速度减慢。

当金达尔在PageRank和ShortestPath上比较面向列的关系数据库和Apache Giraph的性能时，前者在两个图形分析数据集上优于后者:一个来自LiveJournal，有4个。800万个节点和6800万条边；一个来自推特，有4100万个节点和1个。40亿条边。

一个面向列的关系数据库管理系统在处理两个图形数据集时匹配或超过了本地图形数据库的性能。资料来源:Alekh Jindal，MIT CSAIL。

虽然在许多情况下，扩展关系模型以适应图形数据处理是最好的选择，但是在其他情况下，需要切换到图形模型。一个这样的例子是由Whitepages维护的大规模人员数据库，它在孤立的PostgreSQL、MySQL和Oracle数据库中驻留了很多年。

正如2014年11月12日Linkurious上的一篇帖子所解释的那样，Whitepages发现其许多业务客户正在使用该目录询问类似图表的问题，主要是为了防止欺诈。特别是，企业想知道某个特定的电话号码是否与实际地址上的真人相关联，以及还有哪些其他电话号码和地址与特定的人相关联。

Whitepages雇佣的开发团队使用Titan可伸缩图形数据库来满足公司对可伸缩性、可用性、高性能(每秒处理30，000个顶点)和高接收速率(每秒超过200次更新)的需求。生成的图表模式更准确地模拟了Whitepages客户查询数据库的方式:从一个位置到另一个位置，从一个数字到另一个数字。

白页图模式跟踪人们改变物理地址和电话号码以及其他属性。资料来源:Linkurious。

白页已经通过白页专业应用编程接口2向公众提供了它的图形基础设施。0.

无论您发现组织的数据更适合图形还是关系模型，莫斐斯虚拟设备都将帮助您获得实时数据库和系统操作洞察力。通过简单的点击式界面配置您的蒙古数据库、MySQL、弹性搜索或Redis数据库，并跨混合云管理SQL、NoSQL和内存数据库。