JanusGraph 分布式图数据的优化存储和获取
JanusGraph是Titan的一个fork。Titan项目创建于2012年，于2016年停止维护，
是一个方便拓展的图数据库，支持HBase、Cassandra等作为后端（BerkleyDB不提了）
ES、Lucene等做全文索引，以TinkerPop作为图的查询和计算框架。2017年，JanusGraph项目fork了Titan，到目前已经推出了0.2.0版本。
JanusGraph从Apahce TinkerPop中吸收了对属性图模型（Property Graph Model）的支持
和对属性图模型进行遍历的Gremlin遍历语言

JanusGraph官方文档

第一部分 简介

CAP理论(C =一致性Consistency，A =可用性Availability，P =分区容错性Partition tolerance),三个指标无法同时达到

• HBase以输出为代价，优先考虑一致性Consistency，即完成请求的概率。
• Cassandra以收获为代价，优先考虑可用性Availability，即响应的完整性（数据可用性/完整数据）

启动JanusGraph的Console /usr/lib/awaken-graph/SERVICE-JANUSGRAPH-e1cd98416eb74aa087e3e8feecd8405d/bin/gremlin.sh

The Gremlin Console interprets commands using Apache Groovy

Chapter 3

3.3 全局的图索引
Graph indices
Vertex-centric indices
========================================================================

第二部分 JanusGraph Basics

Chapter 5. Schema and Data Modeling 图模式和建模

1. Indexing for Better Performance

JanusGraph支持两种类型的索引：graph index和vertex-centric index。
*graph index
常用于根据属性查询Vertex或Edge的场景；
1/Composte index 组合索引可以对边和点的单个或多个属性建立索引，以此加快点和边的属性查询，这种加速效果仅限于等式条件查询。
不需要外部的索引系统
2/Mixed Index 相比于组合索引，混合索引更为灵活，其支持更多查询谓词（如小于、大于、包含等）；但对于等式查询，组合索引要更快。
要设定索引后端
Odering
1/ composite graph index 原生不支持对返回结果排序，数据会被先加载到内存中再进行排序，对于大数据集合来讲成本非常高
2/ Mixed graph index 本身支持排序返回，但排序中要使用的property key需要提前被加到mix index中去，
如果要排序的property key不是index的一部分，将会导致整个数据集合加载到内存。
Label Constraint: indexOnly

*vertex index    在图遍历场景非常高效，尤其是当Vertex有很多Edge的情况下
静态索引采用Hash函数进行分片，分片个数保持不变，查询时通过计算索引键的Hash值确定查询的分片，查询速度较快
动态索引会监控es索引分片的大小，当索引分片超出一定的阈值后，则会对分片进行分裂，降低索引分片文件的大小

VI. JanusGraph Internals

1. JanusGraph Data Model
   采用邻接表adjacency list的存储结构

Graph Partitioning
1、随机分区：
随机安排顶点到所有机器上
这是默认策略
2、精确分区

• EdgeCut(开启集群自定义分区策略后默认边分割)

  背景：一条边的两个顶点分别在不同的机器上，那么这条边叫做cut edge。 包含对这条边的遍历的图查询会慢因为需要在两台设备间通信 出发点：对于频繁遍历的边，应该减少cut edge的存在，从而减少跨设备间的通信，提高查询效率。 即把进行遍历的相邻顶点放在相同的分区，减少通信消耗。 为顶点确定分区：JanusGraph通过配置好的 placement strategy来控制vertex-to-partition的分配。

a/默认策略：在相同事务中创建的顶点分配在相同分区上。

  缺点：如果在一个事务中加载大量数据，会导致分配不平衡。

b/定制分配策略：实现IDPlacementStragegy接口，并在通过配置文件的ids.placement项进行注册。

• VertexCut

  背景：一个拥有大量边的顶点，在加载或者访问时会造成热点问题

出发点：顶点切割，即把一个顶点进行切割，把一个顶点的邻接表分成多个子邻接表存储在图中各个分区上。

切分方式：按照lable进行切分。

A vertex label can be defined as partitioned which means that all vertices of that label will be partitioned across the cluster in the manner described above.

<br />总结：图数据小使用Random分区策略，图大时（超过10亿条边）就要使用自定义分区策略(点切分或者边切分)

JanusGraph分区，默认采用的是按边分割？

切断后的边会在起始Vertex上和目的Vertex上各存储一次。 通过这种方式，JanusGraph不管是通过起始Vertex，还是从目的Vertex，都能快速找到对端Vertex

JanusGraph的边都是单向边。
如果需要双向边，则通过两条相反方向的单向边组成。
JanusGraph不存在无向边

4、JanusGraph配置

5、Schema and Data Modeling
请注意，JanusGraph图模式可以不断的调整，而不需要中断正常的数据库操作。
修改图模式不会减慢查询应答速度，也不需要数据库停机
5.1. Defining Edge Labels
定义Edge标签
makeEdgeLabel(String)
5.2. Defining Property Keys
makePropertyKey(String)
cardinality 基数
5.3. Relation Types
5.4. Defining Vertex Labels
========================================================================
星图核心特性：
图概况统计
compute
实例分布自适应
Jclient
自动删除过期数据
JMaster
JServer