海量图数据存储？ JanusGraph 了解一下！

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这种存储结构的数据，它可以作为一个依赖在客户端调用，然后直接操作底层存储。

关注 易学在线 公众号

每日更新大量优质技术文档
第一时间获知最新上架课程
与众多大数据猿分享与交流