做整合营销的网站,wordpress添加多首音乐,晋江是哪个省的城市,网站域名为个人的公司能备案大家好#xff0c;我是洋仔#xff0c;JanusGraph图解系列文章#xff0c;实时更新~图数据库文章总目录#xff1a;转载文章请保留以下声明#xff1a;一#xff1a;存储模式留言或私信我#xff0c;邀请你加入“图数据库交流”微信群#xff01;1、图内容本文以下所有…大家好我是洋仔JanusGraph图解系列文章实时更新~图数据库文章总目录转载文章请保留以下声明一存储模式留言或私信我邀请你加入“图数据库交流”微信群1、图内容本文以下所有内容基于JanusGraph基于属性图来进行构造图数据属性图 属性图是由 顶点(Vertex)边(Edge)属性(Property)组成的有向图Vertex可以包含PropertiesEdge也可以包含Properties2、存储方法图存储的方式常用的有两种邻接列表 和 邻接矩阵JanusGraph采用邻接列表进行图数据的存储如下图所示(此处将图中节点抽象为 只有节点没有属性)在Janusgraph中一个顶点的邻接列表包含该节点对应的属性和关联的边下述会详细说明 Janusgraph中邻接列表是如何实现的3、图切割方式图的切割方式分为两种按节点切割(Vertex Cut)和按边切割(Edge Cut)Vertex Cut根据点进行切割每个边只存储一次只要是节点对应的边便会多一份该节点的存储Edge Cut根据边进行切割以节点为中心边会存储两次源节点的邻接列表存储一次目标节点的邻接列表存储一次在Janusgraph中既存在Edge Cut也存在Vertex Cut的情况在默认的情况下使用边切割而针对热点节点可以通过配置makeVertexLabel(product).partition()来将节点类型为product类型的节点进行Vertex Cut也就是说在没有上述makeVertexLabel(product).partition()配置的话JanusGraph所有的图数据都是以Edge Cut的方式来进行切割存储的具体可以查看文章《JanusGraph-分区》中自定义分区部分中关于图切割部分的介绍我们例子来说明一下如下图 张三用户节点通过手机号关联出来李四用户节点张三 和 李四 代表Vertex指向的name、age、gender代表张三的属性edgeA 和edgeB 代表Edge也可以包含边的属性例如下图中边包含属性create_time按边切割后节点张三name(property)age(property)gender(property)edgeA(edge)phonephone(property)edgeA(edge)edgeB(edge)李四name(property)age(property)gender(property)edgeB(edge)上述可以看到按照边切割后每一条边会存储两次二BigTable模型在JanusGraph的存储中 JanusGraph将图形的邻接列表的表示存储在支持Bigtable数据模型的任何存储后端中BigTable模型如下图在Bigtable数据模型中每个表是行的集合由一个key唯一标识。每行由任意(可以很大数量但是必须有限数量)数量的cell组成cell由column和value组成column唯一标识某一个cell。上述图中有两部分需要排序的支持sorted by key 和 sorted by columnsorted by key标识存储后端存储的数据时按照key的大小进行排序存储的sorted by column这是JanusGraph对Bigtable数据模型有一个额外要求存储edge(边)的单元格必须按column排序并且列范围指定的单元格子集必须是有效可检索的 这句话详细解答在下述文章中有体现在Bigtable模型中的行称为“宽行”因为它们支持大量cell并且不必像关系数据库中那样预先定义这些cell的column。在关系型数据库中我们必须先定义好表的schema才可以存储数据如果存储过程中想要改变表结构则所有的数据都要对变化的列做出变化。但是Bigtable模型存储中就不必如此每个行的column不同我们可以随时仅对某一行进行变化也不许预先定义行的schema只需要定义图的schema即可。此外特定的Bigtable实现可以使行按其键的顺序排序。JanusGraph可以利用这样的键序来有效地划分图形从而为非常大的图形提供更好的加载和遍历性能。JanusGraph是如何基于BigTable数据模型针对于自身的图数据特性进行设计的呢下面我们看下JanusGraph的逻辑存储结构三存储逻辑结构JanusGraph基于使用BigTable模型的存储后端 实现了自己的存储的逻辑结构ps为了更好的理解下面部分知识点会基于HBase存储后端进行进一步的解释1、整体结构在JanusGraph中以节点为中心按切边的方式存储数据的。比如在Hbase中节点的ID作为HBase的Rowkey节点上的每一个属性和每一条边作为该Rowkey行的一个个独立的Cell。即每一个属性、每一条边都是一个个独立的KCV结构(Key-Column-Value)上图中我们可以发现图的存储整体分为三部分vertex id、property、edgevertex id 对应节点的唯一id如果底层存储使用的是Hbase则代表着当前行的Rowkey唯一代表某一个节点property 代表节点的属性edge 代表节点的对应的边排序方式分为三种sorted by id、sorted by type、sorted by sort keysorted by id 依据vertex id在存储后端进行顺序存储sorted by type此处的个人理解为针对于property 和 edge的类型进行排序保证同种类型的属性或者边连续存储在一块便于遍历查找 // TODO 深层次理解sorted by sort key sort key是边组成以的一部分主要作用是在同种类型的edge下针对于sort key进行排序存储提升针对于指定sort key的检索速度下面edge结构部分有详细介绍2、Vertex id 的结构此处的Vertex id唯一标识图中的某一个节点节点vertex id的组成结构我们在源码类IDManager的一段注释中可以发现/* --- JanusGraphElement id bit format ---* [ 0 | count | partition | ID padding (if any) ]*/这是在Janusgraph在生成所有的id时统一的格式包含vertex id\edge id\property id的时候这个顺序也 就是标识我们再使用gremlin查询出节点时节点上标识的vertex id 这个id值的顺序不同于hbase真实存储Rowkey的顺序在对vertex id进行序列化存储时位置有所调整为[ partition | 0 | count | ID padding (if any) ] 如下图从图中可以看出Vertex ID共包含一个字节、8位、64个bitVertex ID由partition id、count、ID padding三部分组成最高位5个bit是partition id。partition是JanusGraph抽象出的一个概念。当Storage Backend是HBase时JanusGraph会根据partition数量自动计算并配置各个HBase Region的split key从而将各个partition均匀映射到HBase的多个Region中。然后通过均匀分配partition id最终实现数据均匀打散到Storage Backend的多台机器中中间的count部分是流水号其中最高位比特固定为0出去最高位默认的0count的最大值为2的(64-5-1-3)55次幂大小3 6028 7970 1896 3968总共可以生成30000兆个id完全满足节点的生成最后几个bit是ID padding, 表示Vertex的类型。具体的位数长度根据不同的Vertex类型而不同。最常用的普通Vertex其值为000为什么在序列化存储vertex id时需要调整顺序序列化作为RowKey存储到Hbase呢我们通过下面的3个问题来回答为什么JausGraph分配的逻辑区间值可以影响hbase物理存储呢 可以将分区相同的数据存放的更近呢在上述描述中hbase使用vertex id作为rowkeyhbase根据rowkey顺序排序存储 每个hbase region存储是一段连续的Rowkey行在janusgraph的vertex id的设计中可以发现将分区值放到了64位的前5位存储 在存储数据到hbase时对rowkey进行排序因为partition id在前5位所以同一个分区的vertex id对应的rowkey值相差较小所以会存储在一块如何快速的查询到不同类型的节点呢 换个说法如何快速的确定当前的行就是我们需要的节点类型的行呢在JanusGraph的vertex id中包含的 ID padding就代表当前的节点类型(注意此处的类型lable)。000标识为普通节点在id的组成部分中我们经过前面的分析最前面是partition id只有把 ID padding放在最后几个字节便于查找了为什么查询出的节点显示的vertex id要把0|count放在最前面、partiton和id padding放在后面呢这里我们猜测一下count占用55位数据 试想如果把count不放在最前面那么id的最小值比2的55次幂还大显示不友好 如果把0|count放在最前面呢就会有两个效果0在有符号表示中标识当前id始终为正整数count是趋势递增的所以id值也是从小到大趋势递增的所以节点id的最小值在2的8次幂周边大小 比把count放在后面显示的id值友好多了~~~vertex id是如何保证全局唯一性的呢主要是基于数据库 号段模式进行分布式id的生成体现在图中就是partition id count 来保证分布式全局唯一性 针对不同的partition都有自己的0-2的55次幂的范围的id 每次要生成vertex id时首先获取一个partition获取对应partition对应的一组还未使用的id用来做countjanusgraph在底层存储中存储了对应的partition使用了多少id从而保证了再生成新的分布式vertex id时不会重复生成ps JanusGraph中分布式唯一vertex id、edge id、property id的生成分析请看《图解JanusGraph系列-分布式唯一id的生成机制》3、edge 和 property的结构在上述的JanusGraph的整体结构中property和edge都是作为cell存储在底层存储中其中cell又分为column和value两部分下图展示了这两部分的逻辑结构下面我们详细分析一下 property 和 edge对应的逻辑结构3.1 edge的结构Edge的Column组成部分label id边类型代表的id在创建图schema的时候janusgraph自动生成的label id不同于边生成的唯一全局iddirection图的方向out0、in1sort key可以指定边的属性为sort key可多个在同种类型的edge下针对于sort key进行排序存储提升针对于指定sort key的检索速度该key中使用的关系类型必须是属性非唯一键或非唯一单向边标签存储的为配置属性的value值可多个(只存property value是因为已经在schema的配置中保存有当前Sort key对应的属性key了所以没有必要再存一份)adjacent vertex idtarget节点的节点id其实存储的是目标节点id和源节点id的差值这也可以减少存储空间的使用edge id边的全局唯一idEdge的value组成部分signature key边的签名key该key中使用的关系类型必须是属性非唯一键或非唯一单向边标签存储压缩后的配置属性的value值可多个(只存property value是因为已经在schema的配置中保存有当前signature key对应的属性key了所以没有必要再存一份)主要作用提升edge的属性的检索速度将常用检索的属性设置为signature key提升查找速度other properties边的其他属性注意 不包含配置的sort key和signature key属性值因为他们已经在对应的位置存储过了不需要多次存储此处的属性要插入属性key label id和属性value来标识是什么属性属性值是什么此处的property的序列化结构不同于下述所说的vertex节点的property结构edge中other properties这部分存储的属性只包含proeprty key label id property value不包含property全局唯一id详细解释及思考在进行详细分析前请大家思考几个问题如下:基于上述的edge逻辑结构JanusGraph是如何构造邻接列表的 或者 是如何获取源节点的邻接节点的上述的Edge逻辑结构中的每部分的排列的顺序的含义是什么1、基于上述的edge逻辑结构JanusGraph是如何构造邻接列表的 或者 是如何获取源节点的邻接节点的从上述的整体结构部分中我们可以知道vertexId行后跟着当前的节点关联的所有的edge而在上述的edge的逻辑结构中有一个adjacent vertex id字段通过这个字段就可以获取到target节点的vertex id就相当于指向了target节点整理一下如上图通过上述的条件就可以构造一个VertexA指向VertexB 和 VertexC的邻接链表其实JanusGraph可以理解为构造的是双向邻接列表 依据上图我们知道vertexA 和 vertexB 和 vertexC存在边关系 当我们构造vertexB的邻接列表时会包含指向vertexA的节点只是说在edge对应的逻辑结构中边的方向不同而已总结JanusGraph通过vertex id行中包含所有关联的edgeedge逻辑结构中包含指向target节点的数据来组成双向邻接列表的结构2、上述的Edge逻辑结构中的每部分的排列的顺序的含义是什么首先在查询的时候为了提升查询速度我们首先要过滤的是什么针对于edge毋庸置疑是边的类型和边的方向所以为了我们可以更快的拿到类型和方向所以在edge的存储结构中我们发现作者将类型和方向存放在了column中并且是column的最前面部分这样我们可以直接通过判断column的第一部分字节就可以对边类型和方向进行过滤ps虽然我们在写Gremlin语句的时候可能是语句写的是先过滤边的属性或者其他但是JanusGraph会针对我们的gremlin语句进行优化为先过滤边类型和方向接下来我们可能对边的属性进行过滤我们怎样提升经常要过滤的属性的查询速度呢 我们将经常用于范围查询的属性配置为sort key然后就可以在过滤完边类型和方向后快速的进行属性的范围过滤(此处快速的指过滤配置为sort key的属性)3.2 property的结构property的存储结构十分的简单只包含key id、property id和value三部分key id属性label对应的id有创建schema时JanusGraph创建 不同于属性的唯一idproperty id属性的唯一id唯一代表某一个属性value属性值注意属性的类型包含SINGLE、LIST和SET三种Cardinality当属性被设置为LIST类型时因为LIST允许当前的节点存在多个相同的属性kv对仅通过key id也就是属性的label id是无法将相同的属性label区分出来的所以在这种情况下JanusGraph的property的存储结构有所变化 property id也将会被存储在column中如下图四index存储结构1、Composite Index-vertex index结构图一(唯一索引Composite Index结构图)图二(非唯一索引Composite Index结构图)Rowkey由index label id 和properties value两大部分组成index label id标识当前索引类型properties value索引中包含属性的所有属性值可多个 存在压缩存储如果超过16000个字节则使用GZIP对property value进行压缩存储Column由第一个字节0 和 vertex id组成第一个字节0无论是唯一索引还是非唯一索引此部分都会存在如图一vertex id非唯一索引才会在column中存在用于分别多个相同索引值对应的不同节点如图二value由vertex id组成vertex id针对于rowkey column查询到的value是vertex id然后通过vertex id查询对应的节点2、Composite Index-edge index结构图一(唯一索引Composite Index结构图)图二(非唯一索引Composite Index结构图)Rowkey同Vertex index部分Column由第一个字节0 和 edge id组成第一个字节0无论是唯一索引还是非唯一索引此部分都会存在如图一edge id非唯一索引才会在column中存在用于分别多个相同索引值对应的不同节点如图二value由以下4部分组成edge id边idout vertex id边对应的出边idtype idedge 的label type idin vertex id边对应的入边id2、Mixed Index结构这里以ES作为第三方索引库为例这里只介绍普通的范围查找的mixed index的构造ES的概念为index 包含多个 type每个type包含多个document id每个document id包含多个field name 和对应的field value在Jausgraph中index包含两种janusgraph_edge 和 janusgraph_vertex两种type可自定义document idedge id或者 vertex idfield name索引对应属性的label stringfield value属性对应的property value基于倒排索引的查询顺序为给定过一个property label 和 property value查询对应的Vertex id 或者 edge id则查询满足要求的field name 和 field value就可以获取到对应的document id即Vertex id 或者 edge id五序列化数据案例以序列化实例来看下上述所说的整体结构测试节点数据{label:user,propertyMap:{create_time:2016-12-09 02:29:26,user_name:张三,user_id:test110},vertexId:4152}测试边数据{edgeId:17514510,label:user_login_phone_number,propertyMap:{productid:2},sourceId:4152,targetId:40964120}跟踪Janusgraph源码获取其序列化信息后端存储使用Hbase节点序列化后数据(不包含索引)边序列化后数据(不包含索引)节点的vertex id序列化后的数据为56 0 0 0 0 0 0 -128一个节点对应的属性和边的Rowkey相同依据qualifier也就是column来进行区分在边的序列化结果中包含两部分一部分是节点4152的kcv一个是节点40964120的kcv这地方也可以说明JanusGraph是采用的双向邻接链表进行图存储的五Schema的使用从上述来看我们可以知道JanusGraph图的schema该怎样定义主要是由edge labels 、property keys 和vertex labels 组成(Each JanusGraph graph has a schema comprised of the edge labels, property keys, and vertex labels used therein)JanusGraph的schema可以显式或隐式创建推荐用户采用显式定义的方式。JanusGraph的schema是可以在使用过程中修改的而且不会导致服务宕机也不会拖慢查询速度。比如一个简单的显示定义的销售图的scheme当然我们也可以添加一些其他的可以组成schema的元素上述三个是必须的另外的比如索引(index)等主要的结构还是JanusGraph Schema|-----------Vertex Lables|-----------Property Keys|-----------Edge Labels和关系型数据库不同图数据的schema是定义一张图而非定义一个vertex的。在Mysql中我们通常将建立一张表定义为创建一个schema而在JanusGraph中一个Graph用于一个schema。六源码分析七总结JanusGraph采用Edge cut的方式进行图切割并且按照双向邻接列表的形式进行图存储JanusGraph每个节点都是对应的kcv结构 vertex id唯一标识节点对应的行cell存储节点属性和对应的边节点id的分布式唯一性采用数据库号段模式进行生成
