neo4j是native graph database,也就是有自己的数据库存储。它的长处在于支持交互式查询,属于oltp系统,很多人说不支持分片存储使其无法应付海量数据,本人觉得恰恰相反,可以说neo4j的存储方式是教科书式的以空间换时间。
neo4j是native graph database,也就是有自己的数据库存储。它的长处在于支持交互式查询,属于oltp系统,很多人说不支持分片存储使其无法应付海量数据,本人觉得恰恰相反,可以说neo4j的存储方式是教科书式的以空间换时间,每台服务器配备ssd磁盘阵列虽然贵,但是可以大幅减少分片存储的带宽占用和通信时间开销,保证oltp的效率。
neo4j很容易上手,特有的cypher查询语言以画草图的方式查询和建模数据,很直观。适当构建查询计划的情况下,neo4j的查询效率很高,能够迅速从整网中找出符合特定模式的子网,供随后分析之用。
此外,neo4j实现了tinkerpop接口,tinkerpop是刚刚毕业的一个阿帕奇项目,有望建立图数据库的一套标准用户接口。同样实现tinkerpop的还有titan,orient等主流图数据库。
再来看graphX。
graphX是spark的系统组件,存储是基于spark rdd的,有节点和边两种rdd。熟悉spark的朋友对rdd该不会陌生,spark通过缓存rdd的操作节省了大量计算和io开支,因此spark特别适合对海量数据进行运算,此理同样适用于graphX。因此,graphX自设计之初就是奔着图计算的目标去的,属于olap系统,而非oltp系统。
graphX有丰富的函数库,能完成很多经典图算法,如pagerank、三角计数、社群发现、最短路径计算等等。此外,图存储和计算的方式不禁让人想到神经网络算法,如果将隐层用节点rdd表示,隐层之间的边用边rdd表示,运用graphX的计算优势搭建起一套多层神经网络的想法很美妙,这应该就是MLlab相应算法模块的工作原理。
因此跟graphx相关的概念集中在图计算,而非图存储和查询领域。所以经常浏览db-engines的朋友们不难发现,图数据库列表里就没有graphx这一项。在比较图存储和图查询性能时,比较集合多是neo4j、orientdb、titan、arangodb等图数据库系统。而比较图计算时,比较集合多是graphlab、giraph、graphX。
简言之,图数据库系统和图计算系统不是一回事:前者是为了存储完整数据,并根据需求从中查询数据子集供分析展示之用;后者的任务是拿到一个图结构的数据集,从中计算一些有用的东西。
如果你有随时增长的海量数据,希望以图的方式存储这些数据,从而能在需要时顺利挖出一个子图来,那就要借助于图数据库,此时如果你有充足的资金,neo4j是不二之选,否则就要从db-engines里面第二名以后的一众数据库里挑选。进一步,如果你的需求不只停留在查询,还要依据查询结果计算出一些图的特征来,那么建议你将图数据库系统同图计算系统联合使用。
延伸阅读:
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系邮箱:hopper@cornerstone365.cn 处理,核实后本网站将在24小时内删除。