【工作】RedisGraph简单调研

2020-05-13  本文已影响0人  苏柏亚的星空

目前业界图数据库主要以Neo4j、tigergraph、janusgraph等为主,但是前2个并不开源,公司不太考虑使用。通过一段时间的janusgraph调研与测试,总结以下几点

janusgraph最大的问题可能在于点的ID映射(节点的内部longid与节点本身的key)即创建点或边时需要判断点是否已经存在,需要拿到点的long id,在实时增量场景,性能会严重下降,可能只有1万ops/s(同上集群)

由于这个原因,希望调研下其他图数据库的可行性。基于Redis内存数据库底层的图数据库,可能性能上更与众不同?
RedisGraph github (1000+ star 看来确实很小众。。)
RedisGraph docs

另一个开源图数据库DGraph似乎也不错,但是基于RDF描述的存储结构和自定义查询QL,分片与Raft,强大的原生存储,原生索引,理解起来很费劲。。暂时看不下去

主要目标

1 简介

RedisGraph是一种基于Redis全新设计实现的图数据库。它使用了新的Redis Modules API,扩展Redis并提供了一些新的命令和功能。其主要特性包括:

2 技术设计

RedisGraph: A High Performance In-Memory Graph Database

Hexastore的结构由一系列三元组组成。其中,每个三元组包括如下三部分:

主语(Subject);
谓词(Predicate);
目标(Object)。
主语表示源节点,谓词表示关系,目标表示目的节点。对于图中的每条关系,Hexastore将保存源节点、关系边和目的节点间所有可能存在的六种排列。以下面这条关系为例:

(Aldis_Hodge)-[act]->(Straight_Outta_Compton)
其中, Aldis_Hodge 是源节点,act是关系,Straight_Outta_Compton是目标节点。

该关系的六种可能排列如下:

SPO:Aldis_Hodge:act:Straight_Outta_Compton
SOP:Aldis_Hodge:Straight_Outta_Compton:act
POS:act:Straight_Outta_Compton:Aldis_Hodge
PSO:act:Aldis_Hodge:Straight_Outta_Compton
OPS:Straight_Outta_Compton:act:Aldis_Hodge
OSP:Straight_Outta_Compton:Aldis_Hodge:act
一旦构建了Hexastore,我们可以轻易地实现图搜索。例如,如果要查找“Straight Outta Compton”电影中的演员,那么可以实现为搜索Hexastore中所有包含前缀OPS:Straight_Outta_Compton:act:*的字符串。

如果要查找Aldis Hodge参演的所有电影,那么可以实现为查找所有包含前缀SPO:Aldis_Hodge:act:*的字符串。

尽管Hexastore会占用大量的内存,因为每条关系表示为六个三元组,但是这样的三元组数据结构不仅支持快速搜索,而且可以高效地使用内存,因为它并不会重复地生成已有的字符串前缀。

3 接口和使用

"MATCH (n1)-[r]->(n2) RETURN n1, r, n2.name"
1) 1) "n1"
   2) "r"
   3) "n2.name"
2) 1) 1) 1) 1) "id"
            2) (integer) 0
         2) 1) "labels"
            2) 1) "person"
         3) 1) "properties"
            2) 1) 1) "age"
                  2) (integer) 27
               2) 1) "name"
                  2) "Pam"
      2) 1) 1) "id"
            2) (integer) 0
         2) 1) "type"
            2) "works"
         3) 1) "src_node"
            2) (integer) 0
         4) 1) "dest_node"
            2) (integer) 1
         5) 1) "properties"
            2) 1) 1) "since"
                  2) (integer) 2010
      3) "Dunder Mifflin"
3) 1) "Query internal execution time: 1.858986 milliseconds"

4 一些测试对比

非自测,来自网络
4000万点,15亿边 twitter数据集
单机 250G内存 32核机器

image.png image.png image.png

其他问题

小结

附1 最新 DB-Engines Ranking(图数据库相关)

image.png

附2 关于图数据库的基本模型

附3 主要图数据库查询语言Cypher、Gremlin和SPARQL

个人理解,gremlin面向路径,表达功能很强大,
cypher更偏向SQL习惯(非数据库SQL,一些更特定的语法),
至于SPARQL,理解不能,略。

附4 基于RDF三元组的Dgraph的基本思路

image.png

每条数据是一个三元组(主S - 谓Q(关系)- 宾O)。分别对SQO建立倒排索引以支持检索。。。
索引允许附带信息(即属性),所以我附上了每个实体的类型信息(即演员,书,人等等)。


image.png

【有点不太能理解关系posting list的的快速过滤。。这里量级很大吧?猜测是分裂?】

上一篇 下一篇

猜你喜欢

热点阅读