实时计算图TigerGraph之高级特性(三)

上一篇gsql文章 介绍了TigerGraph的gsql常见的CURD和强大的自定义图算法功能, 并补充了一些性能和需要注意的的点. 这一篇来单独说说Tigergraph特有的一些高级特性, 这些特性可能不一定经常使用, 但是对性能影响可能会很大, 建议根据需要进行体验.

ps: gsql的内容因为太多, 所以一时也写不完…(也不可能全写).

0x00.数据压缩

这里分为几个方面, 一是系统自带的数据入库后的压缩, 另一个是可自己根据实际情况配置的压缩.(比如string compress 类型).

因为系统自带压缩目前不可控制, 只是需要注意的是压缩率是有很大差别的. 压缩的本质就是把重复字符用更少的方式表达, 所以当字符大量不连续, (比如MD5/UUID) , 也是很难压缩的, 可参考没写完的存 储与压缩 . 所以做实际存储压缩比的时候, 需要用多种实际业务场景数据来进行测试, 而不能用简单数据集表示.

接下来说说string compress 这种功能, 如果理解了我上面说的压缩的本质, 那么我想字符串压缩也是比较好理解的, 比如0x00000010x0000002 这种字符串, 大量重复的字符就可以被进一步压缩. 本质它也是一种整形来替代字符串的方式, 详细说明参考 . 这里比较好的介绍了除了简单的重复字串, 还有什么场景适合使用压缩字符 .

0x01.并发写入

这个在数据导入的最开始就会介绍, 因为提升效果的确是很明显, 4台测试机器上, 近乎可以接近线性的导入速度叠加. 这个在之前的测试里也有提到, 至于和单机导入的时候具体的底层区别, 我也不清楚 ,就不乱猜了. 这个功能推荐使用, 如果实际生产使用这个方式, 导入性能基本上不再会是问题…

就是你需要考虑如何生产数据的时候, 均匀的分发到各台机器, 以及写好对应的loading_job 就行. 反正不建议从HDFS上拉取然后手动分发… (但是我目前也不知道有什么好点的办法, 业务即需要有个地方安全保存原始数据, Tigergraph又需要从磁盘直接读取数据, 并且是多机器读取不同数据.)

0x02.分布式查询

这个功能在多机器迭代计算的时候效果很明显, 从实际观察来看, 如果是单纯的点查K步邻居 , 可能只有一台节点在处于高负载计算状态, 其他的节点其实是近空闲的, 那自然会想到可以更高的利用每台节点的性能, 比如一个社群发现的查询, 涉及的区域分布在多台机器, 就很适合.

详细参考文档 , 普通查询不需要使用这个特性. 貌似这也是V2.2最主要的新功能之一.

0x03.安全相关

这里主要有这几点:

  • 数据加密(多种方式)
  • LDAP权限管理
  • 请求校验
  • 子图划分和管理 (逻辑上 )

这些我选择的测试了一下, 但是感觉没必要都写了,参考官方文档为主. 不过着重需要注意的是HA方案和定时的全量备份, 以及节点故障/引入新节点的机制. 简单说说gbar 的备份 (全量&压缩备份)

1
2
#gbar自己有简要说明
$ gbar config

0x04.其他点

因为Tigergraph实际体验来看, 创新/突破的点的确不少, 所以有些小点, 但是我不清楚具体实现的我就放在这了.

1. 很方便的创建reverse_edge (反向边功能)

这个的确解决了一个大难题, 理论上实际的物理存储占用应该会很少. (但是不知道和双向边比如何?) , 简单的说一个Person A --likes-> Person B 这个关系, 我们可以用一个单向边表示, 因为你并不能说A喜欢B的时候, B就同时喜欢A, 所以使用双向边在很多业务场景下是严重的错误...

这点在很多图(比如JanusGraph, TinkerGraph 上采用默认的双向边)的确有很大逻辑问题. 那你说我不用双向边, 使用单向边不就好了, 但是这又带来一个问题, 就是这样A喜欢B的时候, 我如果从B出发, 并不能知道谁喜欢了B… 那么业务需求可能就没法满足. 而Tigergraph这里实际就是自动的反向边, 帮助业务解决这个既不能用双向边, 又想能反向查询的需求.

那不禁可以思考一下, 如果这个需要是让JanusGraph /DGraph来实现, 应该如何设计呢? 并且尽量使得实际物理存储增加最少.

2. 待补充


参考资料:

在每个点里附上的就不重复列出了… 很多小地方都没有时间单独列进来, 后面有机会补充.