本文来自社区用户投稿,感谢小伙伴的技术分享
项目背景
大家好!在春节这段时间里,由于一直在家,所以花时间捣鼓了一下代码,自己做了 SequoiaDB 和 JanusGraph 的兼容扩展工作。 自己觉得这个项目还是挺有意思的,本着开源即是美德的想法,我把自己的代码开源出来了,欢迎 JanusGraph 和 SDB 爱好者拍砖,也希望对这块比较感兴趣的朋友,可以和我一起来完善这个项目。 我们团队在做一个项目时,引入了国产数据库 SequoiaDB,感觉效率啊,维护性啊,都比较友好。自己呢,年前也刚好在其他场景需要应用到一些图计算相关的技术,就想着是否可以为 SequoiaDB 加个 JanusGraph 的翅膀。因为根据我的理解,JanusGraph 对存储扩展极度的友好。 (项目地址: https://github.com/ak918808/sequoiadb_for_janusgraph )JanusGraph 介绍
实际上,在图数据领域里,Neo4j 才是真正处于统治地位的,但是无奈它的社区版本,性能“限(yan)制(ge)”得太过分了,功能也是各种被砍,难以使用在生产环境里。至于企业版,目前也没有专门的预算给到这块的需求。 而再看看图数据库里的老二 -- JanusGraph ,Apache 基金会顶级项目,顶着当年明星项目 Titan 的光环,继续忍辱负重地前行。“这个孩子肯定有出息”,我就是这么想的。 如果大家好奇 JanusGraph 的前世今生,可以扒一扒 DataStax(Cassandra 母公司)对 Titan 干了啥。然后一群热爱开源,又相当牛叉的程序猿就独立单干了。反正这个故事听起来,和当年 MySQL 和 MariaDB 相爱相杀的故事差不多,只是 JanusGraph 的下场更加壮烈。JanusGraph 架构介绍
我从 JanusGraph 的官网里找了一个整体的架构图,大家可以看到 JanusGraph 的模块还是挺丰富的,功能也是比较的全面。 JanusGraph 在存储层中,分开了两个部分,一个专门存储数据(Storage Backend)的,另外一个是专门存储索引信息(Extemal Index Backend)的。存储层中这两个模块都设计得非常 open,逻辑比较清晰,简直就是希望大家踊跃尝试的意思。 JanusGraph 的操作语言,使用 Gremlin 语法进行操作。Gremlin 应该算是图计算里面的事实标准,很多的图计算语法,都是基于 Gremlin 进行二次开发的。 JanusGraph 还能够提供基于 Hadoop 啊,Spark 这些大数据的分析框架,为用户提供 OLAP 的服务。 但是最令我感到震惊的是,JanusGraph 竟然还支持事务功能,虽然是非常有限的事务,但确实提供了这个功能,但是需要存储层的产品来支撑事务功能。JanusGraph 存储部分介绍
JanusGraph 的存储模块,它本身就是按照插件式的形式组成,大家可以从它的源代码的结构就能够看出来。 这种插件方式,在大数据平台里很多产品都是这种设计,Hadoop、Spark、Hive 等,另外,大家能够想到连著名的 MySQL 也是采用这种插件设计吗?这种插件的设计方法,优点就是容易集成,大家可以根据需要&#x