1.Overall Comparison
|
Name |
Neo4j |
JanusGraph |
Giraph |
Jena |
|
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
类似于边，顶点也有标签，但顶点标签是可选的。标签有助于区分不同的顶点类型，虽然顶点标签在概念和数据模型