主流图库对比以及JanusGraph入门
1.Overall Comparison
|
Name |
Neo4j |
JanusGraph |
Giraph |
|
1.Compute Framework |
Yes |
Yes |
Yes |
|
2.External Components Demand |
Option |
Yes |
Yes |
|
3.Algorithm Support |
Official/Spark/ Mazerunner/ XData |
Spark/Giraph/HDP/ XData |
XData |
|
4.HF Subgraph Mining |
Yes (On Sparser Data)(Memory limit) |
Yes |
Yes |
|
SparQL Support |
Yes |
No |
No |
|
Gremlin Support |
Yes |
Yes |
No |
|
Cypher Support |
Yes |
No |
No |
|
Relation Inference |
Supported base on multi-thread single link query and thread d3-format result merge |
||
2.Detail
2.1 Compute Framework
|
组件名 |
Neo4j |
JanusGraph |
Giraph |
|
URL |
|||
|
计算框架概述 |
使用spark连接器，可以使用SparkSQL、Streaming、GraphX框架进行计算。 使用Mazerunner组件，允许将专用数据集（例如节点或关系列表）导出到Spark。 |
OLAP Traversals引擎可以选用Gremlin Graph Computer，默认安装Gephi、Giraph、TinkerGraph、Hadoop、Spark等大数据平台插件，或使用ManagementApi、GremlinApi。 |
Giraph基于Hadoop而建，将MapReduce中Mapper进行封装，未使用reducer。在Mapper中进行多次迭代，每次迭代等价于BSP模型中的SuperStep。一个Hadoop Job等价于一次BSP作业。 |
2.2 External Components Demand
|
组件名 |
Neo4j |
JanusGraph |
Giraph |
|
URL |
|||
|
额外组件依赖 |
官方提供组件，可以与ES、MongoDB、Cassandra等NoSqlDb进行交互 |
计算框架可以选用Gephi、Giraph、TinkerGraph、Hadoop、Spark框架。 数据存储服务可以选用Cassandra、HBase或Berkeley DB服务。 数据索引可以选用Es、Solr或Lucene服务。 |
Giraph基于Hadoop而建，依赖Hadoop、Hive。 |
2.3 Algorithm Support
|
组件名 |
Neo4j |
JanusGraph |
Giraph |
|
URL |
http://tinkerpop.apache.org/docs/3.2.4/reference/#_a_collection_of_vertexprograms |
||
|
算法支持 |
官方： 中心性算法：Pag`eRank、ArticleRank、中介中心性、接近中心性、调和中心性等算法。 社区检测算法：Louvain、LPA 标签传播、连通元件与强连通元件、三角形计数、聚类系数等算法。 路径探寻算法：最小权重生成树、最短路径、单源最短路径、All Pairs最短路径、A *法、（YenK）K最短路径、随机漫步等算法。 相似度算法：杰卡德相似度、余弦相似度、欧几里得距离、重叠相似度等算法。 |
官方： PageRankVertexProgram、PeerPressureVertexProgram 其他实现(Sotera)： |
官方： 最短路径、出/入度计数、PageRank、连通元件算法。 其他实现(Sotera)： |
2.4 HF Subgraph Mining
|
组件名 |
Neo4j |
JanusGraph |
Giraph |
|
URL |
https://www.slideshare.net/ptgoetz/large-scale-graph-analytics-with-janusgraph |
https://code.fb.com/core-data/scaling-apache-giraph-to-a-trillion-edges/ |
|
|
高频子图挖掘 |
节点数量受单机内存容量影响，最大连接数受Bolt线程池配置影响，在小数据集或稀疏数据集下性能表现良好，可以实现高频访问。 OLAP使用spark-connector通过大数据平台Apache Spark集群实现，拥有横向扩展的计算能力。 |
JanusGraph通过与大数据平台（Apache Spark，Apache Giraph，Apache Hadoop）的集成支持全局图形数据分析，报告和ETL 。 拥有横向扩展的计算能力，可进行计算密集型子图挖掘。 |
Giraph应用程序作为单个MapReduce作业运行，因此可以通过增加作业的工作者（Mapper节点）数量来轻松并行化。 拥有横向扩展的计算能力，可进行计算密集型子图挖掘。 |
3.JanusGraph Detail
3.1 Basic Pattern
JanusGraph本身就是一组没有执行线程的jar文件。连接和使用JanusGraph数据库有两种基本模式(JanusGraph Embedded、JanusGraph Server)和交互式Shell（Gremlin Console）方式：
|
模式 |
描述 |
|
Gremlin Console |
Gremlin控制台是一个REPL（即交互式shell），与JanusGraph一起打包，可以通过控制台进行JanusGraph 图库的创建（连接）、查询等操作。 |
|
JanusGraph Embedded |
嵌入式查询，JanusGraph 作为应用程序的一部分，执行Gremlin，查询同一JVM中的图库。 查询执行、JanusGraph缓存和事务处理均发生于此JVM。 存储后端，即查询结果的数据来源库，可能是本地库或远程库。 |
|
JanusGraph Server |
机器上长期运行的服务器进程，允许远程客户端或运行在程序中的逻辑进行JanusGraph调用。 提交Gremlin查询到服务器，与JanusGraph实例交互。 |
3.2 Configuration Each Pattern
不同模式下配置加载示例：
|
模式 |
配置加载 |
|
Gremlin Console |
通过加载配置文件路径 graph = JanusGraphFactory.open （'path / to / configuration.properties' ） |
|
JanusGraph Embedded |
通过加载”后端存储名：配置文件地址或主机名” graph = JanusGraphFactory.open('cql:localhost') graph = JanusGraphFactory.open （'berkeleyje：/ tmp / graph' ） |
|
JanusGraph Server |
... graphs: { graph: conf/janusgraph-berkeleyje.properties } scriptEngines: { gremlin-groovy: { plugins: { org.janusgraph.graphdb.tinkerpop.plugin.JanusGraphGremlinPlugin: {}, org.apache.tinkerpop.gremlin.server.jsr223.GremlinServerGremlinPlugin: {}, ... |
3.3 Classification Of Configuration
JanusGraph区分本地和全局配置选项，具体区分了以下五个配置选项范围：
|
配置类型 |
作用域 |
修改指南 |
|
LOCAL（本地配置） |
单个JanusGraph实例 |
初始化实例时提供 |
|
MASKABLE（可屏蔽配置） |
集群中的某个JanusGraph实例 |
本地配置文件提供则覆盖配置，若无本地配置文件则读取集群的全局配置 |
|
GLOBAL（全局配置） |
集群中的所有JanusGraph实例 |
由全局配置提供，且无法在某实例上覆盖配置 |
|
GLOBAL_OFFLINE（离线全局配置） |
集群中的所有JanusGraph实例 |
类似GLOBAL配置，但修改需要重启集群： 2：关闭所有运行中的事务且无新事务提交 3：通过ManagementAPI修改配置，并commit 4：重启所有节点 |
|
FIXED（固定配置） |
集群中的所有JanusGraph实例 |
由集群初始化是提供，且无法修改 |
3.4 Data Loading Process
后端存储中，数据被加载到JanusGraph的过程
|
过程描述 |
|
对图创建全局和以节点为中心的索引 |
|
加载所有节点 |
|
加载所有边 |
3.5 Storage Backend Comparison
不同后端存储架构、优点以及业务选用逻辑。
|
组件 |
架构 |
限制 |
优点 |
选用逻辑 |
|
Oracle Berkeley DB Java版 |
单机节点，同个JVM。 |
最大一亿节点限制； 整库遍历操作易耗尽内存； 受单点故障影响； |
得益于处于同JVM，对于中小规模图库的访问，Berkeley DB具有比分布式存储更快速度。 |
测试和探索逻辑时选用。 对中小图库保证可用性和一致性。 无分布式架构。 |
|
Cassandra |
分布式架构 |
- |
高可用，无单点故障； 弹性扩展，可以动态增加或减少节点。 |
优先考虑可用性和可扩展性，在一致性上有所妥协，即查询结果的完整性（可用数据/所有数据）。 |
|
HBase |
分布式架构 |
- |
Hadoop生态系统紧密集成; 强一致性读写模型； 可扩展更多机器； |
优先考虑一致性与分布性，并在可用性部分进行妥协，即响应请求的概率（查询结果数/查询总数）。 |
3.6 Schema and Data Model
每个JanusGraph图库都有一个由边标签、属性键和用到的顶点标签组成的模式。JanusGraph模式可以被显式或隐式地指定，官方建议明确指定模式，模式可以随着系统发展而作出调整，并对性能进行调优。
3.6.1 Defining Edge Labels
可以通过在graph（或management transaction）对象上调用makeEdgeLabel(String labelName)方法，得到一个builder，之后通过builder定义边的多重性，边的多重性有以下设置选项：
|
多重性 |
描述 |
|
MULTI |
任意一对顶点，允许存在任意多个当前标签类型的边 |
|
SIMPLE |
任意一对顶点，最多允许存在一条当前标签类型的边 |
|
MANY2ONE |
任何顶点，最多允许一条当前类型出射边和任意多条当前类型入射边 |
|
ONE2MANY |
任何顶点，最多允许一条当前类型入射边和任意多条当前类型出射边 |
|
ONE2ONE |
任何顶点，最多允许一条当前类型入射边和最多一条当前类型出射边 |
示例：（若不指定多重性则默认为MULTI）
mgmt = graph.openManagement()
follow = mgmt.makeEdgeLabel('follow').multiplicity(MULTI).make()
mother = mgmt.makeEdgeLabel('mother').multiplicity(MANY2ONE).make()
mgmt.commit()
3.6.2 Defining Property Keys
边或顶点上的属性是键值对，属性键是Schema的一部分，并且可以限制属性类型和值的基数。可以通过在graph（或management transaction）对象上调用makePropertyKey(String propertyName)方法，得到属性键的builder，之后通过builder. datatype(Class)指定属性键的数据类型。JanusGraph会强制所有与属性键关联的值拥有数据类型配置，以此保证图数据的有效性。
数据类型
- 数据类型Object.class，可以允许任何（可序列化）值与键关联。官方建议尽可能使用具体的数据类型。配置的类型必须是具体的类，而不是接口或抽象类。
- JanusGraph会考虑类相等性，因此不允许添加已配置类型的子类。
JanusGraph原生支持的数据类型
|
类型 |
描述 |
|
String |
字符数组 |
|
Character |
单个字符 |
|
Boolean |
true or false |
|
Byte |
字节值 |
|
Short |
短整型 |
|
Integer |
整型 |
|
Long |
长整型 |
|
Float |
4字节单精度浮点数 |
|
Double |
8字节双精度浮点数 |
|
Date |
java.util.Date |
|
Geoshape |
地理学形状：点、圆、方形 |
|
UUID |
java.util.UUID |
属性键基数
使用cardinality(cardinality)，在任意指定节点上，定义与键关联的值基数，以下是基数可选项：
|
名称 |
描述 |
|
SINGLE (default) |
对于每个元素，当前键最多允许一个值 |
|
LIST |
对于每个元素，当前键允许任意个值 |
|
SET |
对于每个元素，当前键允许任意个非重复值 |
默认基数项为SINGLE，故所有边的基数均为SINGLE，所以向边上的某个键附加多个值是不允许的。
示例：
mgmt = graph.openManagement()
birthDate = mgmt.makePropertyKey('birthDate').dataType(Long.class).cardinality(Cardinality.SINGLE).make()
name = mgmt.makePropertyKey('name').dataType(String.class).cardinality(Cardinality.SET).make()
sensorReading = mgmt.makePropertyKey('sensorReading').dataType(Double.class).cardinality(Cardinality.LIST).make()
mgmt.commit()
3.6.3 Relation Type
边的标签和属性键一同被引用作为关系类型，JanusGraph API中有一些方法可以查询是否存在或检索包含属性键和边标签的关系类型。
示例：
mgmt = graph.openManagement()
if (mgmt.containsRelationType('name'))
name = mgmt.getPropertyKey('name')
mgmt.getRelationTypes(EdgeLabel.class)
mgmt.commit()
3.6.4 Defining Vertex Labels
类似于边，顶点也有标签，但顶点标签是可选的。标签有助于区分不同的顶点类型，虽然顶点标签在概念和数据模型
2018-11-23 graph图数据库概览,经过一个星期的Demo终于看懂了这篇文章20180818图数据库概览
20180818图数据库概览
20180818图数据库概览
1.总体趋势
Knowledge Base of Relational and NoSQL Database Management Systemsdb-engines.com
根据DB-Engines的数据库DB-Engines排名，图数据库一骑绝尘，
图数据库2018-8的最新排名如下
Neo4j仍是最流行的图数据库，图中JanusGraph的排名并不靠前，但要考虑到他是之前很火已经被收购停止发展的titan的fork分支，所以这点加成还是可以算上的。图中与OrientDB趋势基本一致的哪个黑线就是titabDB生前的排名。
CosmosDB/DatastaxStardog/Sqrrl等商业数据库就不做分析了， 本文只对Neo4j、OrientDB、JanusGraph、Giraph、HugeGraph做下分析，其中HugeGraph并不在上面，这是百度开源的图数据库，简单看了下也不错，列在这。
2.图数据库组件
一个完善的图数据系统应该至少包括图存储及图处理引擎，数据导入导出，管理运维，查询和计算，商业化产品需要有高可用及容灾备份。
图存储和图处理：这个是图数据库的核心，图存储负责将关系型数据集非结构化数据转成图结构进行存储，这里的存储可以为原生存储或序列化之后的非原生存储；图处理则负责数据的更新及运算。
数据导入导出：数据从外界到图存储的导入导出能力，如从外界的json、csv，rdf等数据形式导入到图数据库中，或将图数据库中的数据导出来。
管理运维：管理运维则包含系统的监控，配置及可视化能力
查询和计算：主要指提供查询语言供用户进行图的查询遍历等操作。
3.图数据库：
【1】Neo4j
是老牌的图数据代表。其功能强大，性能也不错，单节点的服务器可承载上亿级的节点和关系，单节点性能不够时也可进行分布式集群部署。
Neo4j有自己的后端存储，不必如同JanusGraph等一样还要依赖另外的数据库存储。 Neo4j在每个节点中存储了每个边的指针，因而遍历时效率相当高。
Neo4j分为社区版和企业版，社区版功能受限，另外其提供可视化的客户端感觉很不错。
据neo4j的中国合作方的社区中描述，主要区别如下：
1、容量：社区版最多支持 320 亿个节点、320 亿个关系和 640 亿个属性，而企业版没有这个限制；
2、并发：社区版只能部署成单实例，不能做集群。而企业版可以部署成高可用集群或因果集群，从而可以解决高并发量的问题；
3、容灾：由于企业版支持集群，部分实例出故障不会影响整个系统正常运行；
4、热备：社区版只支持冷备份，即需要停止服务后才能进行备份，而企业版支持热备，第一次是全量备份，后续是增量备份；
5、性能：社区版最多用到 4 个内核，而企业能用到全部内核，且对性能做了精心的优化；
6、支持：企业版客户能得到 5X10 电话支持（Neo4j 美国电话、邮件，微云数聚电话、微信、邮件）；
考虑到这些限制，要选开源免费大容量分布式的图数据库的可以跳过了，研究图论及小型应用或不差钱的项目则选其的支持服务则另当别论。另外neo4j的协议为GPLv3，这个也不适合选用。
【2】OrientDB
OrientDB据描述性能可以达到Neo4j的数倍，但也有测试表明在遍历时磁盘空间增加，以空间换时间，遍历性能不高，但计算最短路径等性能高。 Neo4J和OrientDB在插入数据时候都会默认建立索引，索引的不同也造成了其不同操作的性能差异； Neo4J：擅长遍历图及不存在大量关系的节点的图计算 OrientDB：侧重文档数据库，主要还是SB树索引导致，空间浪费比较大；插入节点与neo4j差不多，但是在插入节点关系即边时无优化；在图论算法上性能高，但遍历性能低。 OrientDB也有社区版及企业版，但是其基于Apache2.0协议，这个更友好
【3】JanusGraph
Distributed graph databasejanusgraph.org
JanusGraph基于Titan发展而来，包含其所有功能，采用Tikerpop的Gremlin图查询语言，
有单独的后端存储，支持Cassandra/HBase/BerkeleyDB等做存储，支持Solr/ES/Lucence等做图索引 支持Spark GraphX/Giraph等图分析计算引擎及Hadoop分布式计算框架 原生支持集成了Tinkerpop系列组件：Gremlin查询语言，Gremlin-Server及Gremlin applications。 采用很友好的Apache2.0协议，支持对接可视化组件如Cytoscape， plugin for Apache TinkerPop，Graphexp，KeyLines by Cambridge Intelligence，Linkurious
【4】HugeGraph
王二铁：百度安全开源大规模图数据库HugeGraphzhuanlan.zhihu.com
HugeGraph是支持Apache TinkerPop 3框架和Gremlin图查询语言的大型分布式图数据库，据其描述其性能是相当强劲，刚开源不久。不过貌似每个都说自己是最好最强的...
HugeGraph是一款面向分析型，支持批量操作的图数据库系统，它能够与大数据平台无缝集成，有效解决海量图数据的存储、查询和关联分析需求。HugeGraph支持HBase和Cassandra等常见的分布式系统作为其存储引擎来实现水平扩展。HugeGraph可以与Spark GraphX进行链接，借助Spark GraphX图分析算法（如PageRank、Connected Components、Triangle Count等）对HugeGraph的数据进行分析挖掘。 HugeGraph的主要特点包括： 基于TinkerPop 3 API实现，支持Gremlin图查询语言； 拥有完善的周边工具链和相关功能组件，可以满足图数据库开发的基本需求，提供易用高效的使用体验； 具备独立的Schema管理模块，丰富完善的Schema校验机制，确保图数据库中的数据完整性和一致性； 支持数据的备份和还原，可以在不同的后端存储之间转换； 多种ID生成策略应对不同业务场景，拥有完善的索引管理机制，支持多种索引查询操作； 可以实现与Hadoop、Spark、HBase、ES等大数据系统集成，支持多种Bulk Load操作，实现海量数据快速插入； 除上述特定之外，HugeGraph还针对图数据库的高频应用（例如：ShortestPath、k-out、k-neighbor等）做了特定性能优化，并且为用户提供更为高效的使用体验
我的感觉是跟titan/JanusGraph蛮像的
看其致谢果不其然，不过里面还是蛮多创新及扩展的，如果他能持续的接纳Janus和DataStax的新特性并长久发展的话用这个倒是不错。
HugeGraph relies on theTinkerPopframework, we refer to the storage structure ofJanusGraphand the schema definition ofDataStax. Thanks to Tinkerpop, thanks to JanusGraph and Titan, thanks to DataStax. Thanks to all other organizations or authors who contributed to the project.
3.图分析系统
上面简单介绍了几个图数据库，也提到其后端存储，neo4j等使用自己的原生图存储，而JanusGraph/HugeGraph等则用非原生图存储。
原生图存储一般都是经过专门为了存储和管理图结构而优化的，遍历查询性能很高，但掐非遍历类的查询则不占优势，且为了全局搜索还会占用大量内存。
非原生图存储通常将图结构序列化存储到RDBMS或其他通用存储中，如JanusGraph的HBase/Cassandra，HugeGraph甚至增加了对MySQL等的支持。
一个图分析系统除了图数据库外还要有图计算引擎，主要目的是为了进行除遍历外的图算法分析。前述的图数据库相当于OLTP，而图计算则相当于OLAP。有的图数据库也继承了少量的图计算能力，但真正的大型系统还是需要单独的计算框架。
基于图的并行计算框架，有google的Pregel，基于Spark的GraphX，Apache下的Giraph/HAMA以及GraphLab，其中Giraph是Pregel的开源实现。
昵称：
退出 订阅评论
[Ctrl+Enter快捷键提交]
【推荐】零基础轻松玩转云上产品，获壕礼加返百元大礼
【推荐】华为IoT平台开发者套餐9.9元起，购买即送免费课程
· janusgraph的数据模型
· JanusGraph的schema及数据建模
· JanusGraph:图和图数据库的简介
· JanusGraph与Cassandra集成模式
· JanusGraph入门，schema及数据模型
· 开源峰会 FreeBSD 相遇 Linux
· 京东方上半年实现净利润16.7亿元 同比减少43.92%
· 科学家发明纳米温度计 可以测量细胞内温度
· Android 10正式版发布时间敲定：9月3日，支持Pixel全系列
· 三六零上半年净利润40.52亿元 同比增163.7%
» 更多新闻...