在经过几年的开发后,近日 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 项目)是非常重要的。
评论