JanusGraph 是一个分布式图形数据库引擎。分布式的作用大家都知道,根本目的就是为了解决“数据量”的问题,对于单机图数据库来说,neo4j 基本上已经是没什么对手了,但是它的社区版本不支持集群模式,所以,催生了这一款分布式图数据 JanusGraph 来填补开源社区的空白。简单的说,对图形数据的实时遍历和分析查询是 JanusGraph 的基本优势。本文将讨论 JanusGraph 及其支持的持久性解决方案的各种特定优点。
另外,JanusGraph 和我们常用的Hadoop生态圈的大数据组件可以无缝衔接,利用Hadoop进行图分析和批处理图处理。JanusGraph 为数据持久性,数据索引和客户端访问实现了强大的模块化接口。JanusGraph的模块化体系结构使其可以与多种存储,索引和客户端技术进行互操作。它还简化了扩展JanusGraph以支持新的存储方式。
在JanusGraph和磁盘之间,可以选择不同的存储和索引引擎。JanusGraph标配了以下引擎,另外,JanusGraph 的模块化体系结构使它对第三方适配器的支持非常友好,所以如果有需要我们也可以进行二次开发,使他支持其他底层存储。
数据存储:
- Apache Cassandra
- Apache HBase
- Oracle Berkeley DB Java Edition
索引(可以加快并启用更复杂的查询)
- Elasticsearch
- Apache Solr
- Apache Lucene
广义上讲,应用程序可以通过两种方式与JanusGraph交互:
- 将 JanusGraph 嵌入到直接针对同一JVM中的图执行 Gremlin 查询的应用程序中。查询执行,JanusGraph 的缓存和事务处理都在与应用程序相同的JVM中进行,而从存储后端检索的数据可能是本地的或远程的。
- 通过向服务器提交 Gremlin 查询,与本地或远程 JanusGraph 实例进行交互。JanusGraph 本机支持 Apache TinkerPop 堆栈的 Gremlin 服务器组件。

JanusGraph 优点
- 底层存储是分布式架构,所以能支持非常大的图形存储, JanusGraph图可以根据集群中的机器数量进行伸缩。
- 支持很多并发事务和操作图处理。JanusGraph的事务处理能力也是随集群中节点的数量而伸缩,并在毫秒内响应大型图上的复杂遍历查询。
- 通过Hadoop框架支持全局图分析和批量图处理。
- 支持在非常大的图上对非常大的边进行地理,数字范围搜索以及全文检索。
- 原生支持当下流行的开源属性图数据模型 Apache TinkerPop 。
- 原生支持图遍历语言 Gremlin 。
- 丰富的图形级配置,可以用于调节集群的性能,以达到最佳水平。
- 以顶点为中心的索引提供了顶点级别的查询,以缓解臭名昭著的超级节点问题。
- 提供优化的磁盘表示形式,以实现存储的有效利用和访问速度。
- 在自由 Apache 2 许可下开放源代码。(简单解释下,就是开源的代码可以商用,只需带上license即可)

JanusGraph 集成 Apache Cassandra
- 连续可用,无单点故障。
- 由于没有主/从体系结构,因此该图没有读/写瓶颈。
- 弹性可伸缩性允许引入和删除机器。
- 缓存层确保连续访问的数据在内存中可用。
- 通过将更多计算机添加到群集来增加缓存的大小。
- 与Apache Hadoop集成。
- 在自由Apache 2许可下开放源代码。

JanusGraph 集成 HBase
- 与Apache Hadoop生态系统的紧密集成。
- 对强一致性的本机支持。
- 线性扩展性,支持集群的扩展。
- 严格一致的读写。
- 使用HBase表支持Hadoop MapReduce作业的便捷基类。
- 支持通过 JMX 导出指标。
- 在自由 Apache 2 许可下开放源代码。
CAP定理
Despite your best efforts, your system will experience enough faults that it will have to make a choice between reducing yield (i.e., stop answering requests) and reducing harvest (i.e., giving answers based on incomplete data). This decision should be based on business requirements.
— Coda Hale
翻译一下:
尽管尽了最大的努力,您的系统仍会遇到足够的故障,因此必须在降低产量(即停止回答请求)和减少收成(即根据不完整的数据给出答案)之间做出选择。该决定应基于业务需求。
又是我们熟悉的 CAP 问题,CAP 定理即(C =一致性,A =可用性,P =可分区性)。JanusGraph带有3个支持后端:Apache Cassandra,Apache HBase 和 Oracle Berkeley DB Java版,(BerkeleyDB JE是一个非分布式数据库,通常仅与JanusGraph一起用于测试和探索目的),我们最熟悉的当然还是 HBase ,所以后续相关的文章底层存储会围绕 HBase + ElasticSearch 来展开。
分布式系统必须支持 P ,既然没法放弃 P,那只能在 C 和 A 之间做选择了。
- HBase优先考虑一致性(C),但是可用性(A)会降低,即完成请求的可能性。
- Cassandra优先考虑可用性(A),但要以一致性(C)为代价,即查询答案的完整性(可用数据/完整数据)。
另外,JanusGraph 并不存在 CAP 问题需要解决,因为它本身并不是一个分布式的系统,也不存储数据,它的作用只是将图结构的数据转化为类似HBase这种存储结构的数据,它可以作为一个依赖在客户端调用,然后直接操作底层存储。

关注 易学在线 公众号
每日更新大量优质技术文档
第一时间获知最新上架课程
与众多大数据猿分享与交流
DOIT.EDU 资料来自网络收集整理,如有侵权请告知