Neo4j：基于Java的NoSQL图形数据库

在经过几年的开发后，近日NeoTechnology发布了基于Java的图形数据库Neo4j 1.0，它遵循着属性图形数据模型。InfoQ有幸采访了NeoTechnology的COO Peter Neubauer以深入了解此次发布的Neo4j及其向开发者所提供的功能。

Neo4j的核心JAR文件大约有440k，既有基于AGPLv3的开源版本，也有商业版本。如果在闭源软件中使用Neo4j则需要商业协议。Neo4j中的信息主要通过如下3个基本的构建块表示：

• Node（又叫做vertex）——从概念上来说，这类似于对象实例，拥有唯一的ID。
• Relationship（又叫做edge）——它连接了两个Node，此外还有方向和RelationshipType。
• Property（又叫做attribute）——他们是字符串类型的key/Object值对，Node与Relationship都有Property。

相对于关系数据库来说，图形数据库善于处理大量复杂、互连接、低结构化的数据，这些数据变化迅速，需要频繁的查询——在关系数据库中，这些查询会导致大量的表连接，因此会产生性能上的问题。Neubauer详细解释了这一点：

Neo4j重点解决了拥有大量连接的传统RDBMS在查询时出现的性能衰退问题。通过围绕图形进行数据建模，Neo4j会以相同的速度遍历节点与边，其遍历速度与构成图形的数据量没有任何关系。此外，Neo4j还提供了非常快的图形算法、推荐系统和OLAP风格的分析，而这一切在目前的RDBMS系统中都是无法实现的。

由于Neo4j是个数据库，因此对图形结构的访问——读、写及遍历都是通过ACID事务系统进行管理的。图形遍历是通过Traverser API进行管理的，此外还借助于Lucene提供了对索引的支持，与Solr的集成也仍在开发当中。大家可以查看NeoTechnology CEO Emil Eifrem的讲座以深入了解Neo4j，此外还可以观看对Peter Neubauer的采访。

在被问到关于NoSQL运动的立场时，Neubauer说到：

当然支持NoSQL运动了，因为我们正在解决RDBMS目前所没有解决的问题。这就是说，我们首先关注的是数据、深度查询和分析的复杂性以及RDBMS中需要很多连接和稀疏表才能完成的操作；此外，很多其他的NoSQL项目正在努力解决可伸缩性和分片（sharding）等问题。

Neubauer说到：虽然Neo4j 1.0最近才发布，但在某些领域的产品中已经使用7年多了，此次发布的1.0版的重点并非代码基的稳定性而是API的稳定性。Neo4j的性能也得到了极大的提升，无须修改代码就能够处理拥有数十亿对象的图形；正常来说，Neo4j每秒能够读取200万个关系，同时最短路径计算的可伸缩性要远远好于关系数据库，如MySQL等（虽然使用了相同的性能基准，但众多的因素如硬件和数据集等都会对结果产生比较大的影响）。

除了主要的Neo4j代码基以外，还有一个贡献者与用户所构成的社区和一个庞大的生态圈，这里列举出几个：

• 扩展——jo4neo（Java Objects for Neo）、Gremlin（用于处理图形的编程语言）以及一个REST/JSON接口。
• 框架集成——Grails、Griffon、Django以及Spring。
• 语言绑定——JRuby、Python、Scala、PHP以及Clojure。

关于Neo4j的未来计划，最近一轮的资金将有助于未来的进一步开发，包括对现有的主／从复制的增强、在线的备份支持以通过最终的一致性和write-master重选来提供无缝的高可用性、更棒的全局操作支持以及完整的REST支持（包括基于JavaScript的动态遍历和用于数据发布的只读模式）等等。长远计划包括对分片（sharding）的支持（这会给Neo4j代码基带来全新的挑战），Emil Eifrem还表示用户与开发者所构成的庞大且快速增长的社区（已经创建了数百个Neo4j项目）是非常重要的。

查看英文原文：Neo4j: Java-based NoSQL Graph Database