马修·格雷·古柏勒，push push baby，丘倩鸣
>属性图由顶点（圆圈）、边（箭头）、属性（key:value）和标签组成，顶点和边可以有标签，比如顶点的标签是User，边的标签是FOLLOWS。图中标签为User的顶点有name属性，属性值为Johan或Peter或Emil。边表示了他们的关注关系。图中标签为FOLLOWS的边是单向边，如果是相互关注了，那么需要2条边表示。
如果不算上标签，属性图自身的关系可以用下图表示：
>Q：为什么需要图数据库，相比关系型数据库等有什么优势？
A：因为关系型数据库不擅长处理数据之间的关系。
>上图是一个使用关系数据库模型实现的商品交易的例子。如果要做商品推荐相关的查询时，可以发现其中一些查询是低效的(例如，“客户购买了什么产品?”)，而有些查询可能是无法完成的(例如，“哪些客户购买了该产品?”)。
Q：能举个更详细的对比例子吗？
A：假设我们要查找某个公司的员工Alice属于哪个部门。
>在关系型数据库中，一般需要建立员工信息表，员工和部门对应关系表（假设一个员工可以属于多个部门），部门信息表。查找时需分为3步：
A，先要通过员工信息表找到Alice对应的工号；
B，再使用工号去关系表中找到其对应的部门ID；
C，最后使用部门ID在部门信息表中找到部门名称等信息。
A需要一次索引查找过程，B也需要一次索引查找，C可能需要3次索引查找。如果是个大型公司，员工数万甚至十多万，那么员工和部门对应关系表的记录会非常多，B的查找效率会远低于A和C。
>但如果在图数据库中，就不需要那么复杂的查询。这正是因为图数据库与关系型数据库的建模方式不同，或者说数据的存储方式不同。在图数据库中，员工和部门都在同一张图中，通过边直接建立关系。在查找时也是分为3步：
a，先通过在员工标签Person上建立的全局索引（可稀疏）来找到Alice对应的节点Na；
b，再通过Na节点保存的标签为BELONGS_TO的边来找到对应的部门；
c，最后读取部门信息。
虽然也可以分为3步，但效率却大不相同。a的效率基本等价于A；b无需进行索引查找，直接可以通过Na节点获取，虽然Na节点可能存在非常多不同标签的边，但跟员工和部门关系表的记录数肯定不是一个数量级的，而且通过Na查找边时还可以走Na节点的局部索引来加速查找；c的效率不同的图数据库会有所不同，对于支持免索引邻接的Neo4J等图数据库，Na直接指向3个部门节点的物理地址，对于其他非原生图存储的数据库，比如JanusGraph，需要查找在部门标签Department上建立的全局索引。
Q：有具体的性能测试数据不？
A：我们举最经典的社交网络中查询的性能作为对比。
>上图为一个社交网络，图中包括了朋友、同事、夫妻和恋人等多种关系。有人曾做过一个测试：在一个包含100w人，每人约有50个朋友的社交网络中找到最大深度为5的朋友的朋友。下图为图数据库Neo4J和关系型数据库在寻找扩展朋友时的性能对比。
>从图中可以发现，深度为2时（即朋友的朋友），两种数据库性能相差不是很明显；深度为3时，很明显，关系型数据库的响应时间30s，已经变得不可接受了；深度到4时，关系数据库需要近半个小时才能返回结果，已经妄称在线数据处理系统了；深度到5时，关系型数据库已经掉入深渊。而对于图数据库Neo4J，深度从3到5，其响应时间均在3秒以内。
本文地址：http://www.reviewcode.cn/jiagousheji/177126.html 转载请注明出处！
