老李最近在做推荐相关的项目,需要用到图数据库。前期调研选型是必须的,不然等项目做到差不多时才发现各种坑将后悔不已。目前,项目已基本完结,经过一段时间使用图数据库,老李总结了图数据库相关特性,并做了些对比。
图数据库介绍
现实世界中的一切事物都处在联系之中,如人际关系、电脑网络、地理数据、分子结构模型等,无一不处在纷繁复杂的联系之中。这种联系形成了一种互相关联的数据,联系才是数据的本质所在。传统的关系型数据库并不能很好地表现数据的联系,而一些NoSQL(Not Only SQL,非关系型数据库)数据库又不能表现数据之间的联系。同样属于NoSQL范畴的图数据库是以图的结构形式来存储数据的,它所存储的就是联系的数据,是关联数据本身。
关联数据中的联系本来就很复杂,若要在关系型数据库中使用结构化形式来表现这种联系,则一般不能直接表示,处理起来既烦琐又费事,并且随着数据的不断增长,其访问性能将日趋下降。无数的开发人员和数据库管理人员都或多或少地使用过关系型数据库,在其应用的规模化进展过程中,对于数据库的性能优化往往捉襟见肘、陷入窘境。图数据库没有模式结构的定义,也不需要这些定义,它使用非结构化的方式来存储关联数据,所以能够直接表现数据的关联特性。
图数据库不管是与关系型数据库相比,还是与其他NoSQL数据库相比,都具有很多前所未有的优势。
人物关系图谱 图数据库分类
第一是原生数据库,代表数据库为neo4j、orientdb,其原生体现在查点到边或者边到点的时候,不需要走原来关系型数据库的B+索引,节点本身就有指向索引,类似于链表的指针概念。
第二是直接在关系型数据库之上构建的图数据库,代表为agens graph,以及微软的GraphView。SparkGraphX也可以基于关系型存储结构进行转化成图结构,然后完成图运算。
第三是以Titan/JanusGraph为代表的使用外置nosql存储如hbase,以及使用外置的索引生成工具如elasticsearch,olap支持外接spark等工具。
第四是在图计算上基于batch进行优化的新一代图数据库,如dgraph。dgraph的存储结构与cayley同样借鉴了google的论文,将每个节点的属性也作为一个节点与主节点产生联系,这样更有益与基于batch来设计运算方法。
就目前情况来看,第一块与第二块的项目比较成熟,运行来说相对较稳定,而第三和第四块仍然处于起步阶段。究其原因,原生数据库起步早,发展时间较长,构建于关系型数据库之上的图数据库依托于关系型数据库的稳定,效果也不会太差。titan起步也较早,但是发展缓慢,自15年被收购之后开源项目维护停滞,直到17年才有在其之上构建的JanusGraph。
Titan数据库 图数据库优势:
1)对于节点间关系可简单快速查询其多层连接关系
2)快速遍历节点
各大开源图数据库优势
老李对比了几家业界常用的开源图数据库,得到如下表格
使用性对比
针对使用便捷性:
neo4j有几种强大且便利的第三方python包供使用,导入数据有自带的csv格式导入工具。orientdb自带有一种ETL工具,支持多种格式导入,数据操作是自研的python包,只提供全面的基础功能,使用相比neo4j强大的第三方python包来说略麻烦。dgraph仅支持GraphQL+-查询语言,一种JSON通信方法,python需构建出JSON语句进行交互,并且返回结果也需要用JSON语句,导入格式支持rdf。针对数据插入性能:
经测试,neo4j单条插入每分钟千条左右,单条插入很慢,批量导入数据需要借助csv导入工具。orientdb有自研ETL工具,导入速度较快。dgraph使用自带工具批量导入数据,可达到每秒近2k条数,支持压缩包导入(.gz)。
neo4j数据库 好了,老李也介绍得差不多了,针对大数据量,需要用到分布式存储,并且需要结合hadoop生态,老李推荐JanusGraph。如果数据量较小,只在单机上测试调研,老李推荐neo4j。