在图形理论当中，一幅简单的图形是由一系列节点与边线所构成。事实上图形类数据库往往会赋予节点与连线更多类别与属性，以使其更具可描述性及实际应用功能。至少用户希望图形类数据库能够支持快速遍历——这也是大家不会简单地使用像HBase或者Cassandra这样的表格类数据库存储所有边线的原因(联合运算往往会提高使用成本)。
图形类数据库属于NoSQL数据库四大类型之一，图形存储类产品中也以下列七种较为流行及常用： Neo4J, Infinite Graph, DEX, InfoGrid, HyperGraphDB, Trinity 以及AllegroGraph。本文以Java程序员的视角出发，与我们共同探讨上述产品的各类细节。 1. Neo4J (Neo Technology出品)
Neo4J可能是当下人气最高的图形数据库。从名称我们就能看出Neo4J在设计上主要考虑到Java应用程序的实际需求，但它同时也支持Python。Neo4J属于开源项目，共有GPLv3社区版、高级版、企业版三种版本;后两者都以AGPLv3商业许可为基础。 Neo4J中的图形模型如图一所示。简单来说： ·节点与边线可以被赋予属性(键-值对); ·只有边线能够与类别相关联，例如“KNOWS”; ·边线可以指定为有指向或无指向。
▲图一
由于节点名称的存在，如果大家想在图中找到对应节点，那么必须依靠索引。Neo4J使用以下索引机制：一个超级参考节点通过一条特殊类别的边线“REFERENCE”与所有节点相连。这实际上允许我们创建多个索引，借以通过不同的边线类别对其加以区分。索引结构如图二所示。
▲图二
Neo4J还提供了一些特殊功能，例如列出特定节点的相邻诸节点或是两节点间长度最短的诸类路径等。请注意，要使用上述各类“遍历”功能，Neo4J要求大家指定路径中经过的边线类别，其实这一点并不麻烦。
其实大家不必将Neo4J作为软件加以安装。我们完全可以简单地导入JAR文件来建立一套嵌入式图形数据库，该操作将在硬盘上建立对应的目录。具体信息在Neo4J的说明文档中已经相当完备，而且其免费版本也没有设置节点支持数量的上限。 缺点：
·尽管我们可以手动为节点类别通过“type”键添加注释，但相比之下为节点类别在API中提供本地支持无疑更好，因为这将使图形模型更具普遍意义。另外一旦某个节点具备多种不同类别，麻烦也将随之而来。
·由用户手动为新边线设置索引机制似乎有点奇怪并且很不方便。最好是采用如今关系类数据库的普遍做法：用户只需表明要“为一组节点创建索引”，工作即可完成。
2. Infinite Graph (Objectivity Inc.出品)
InfiniteGraph 是一款由Objectivity公司推出的图形类数据库，该公司还推出过一款同名的对象类数据库。免费许可版本只能支持最高100万节点及边线总数。InfiniteGraph需要作为服务项目加以安装，这与以MySQL为代表的传统数据库颇为相似。InfiniteGraph借鉴了Objectivity/DB中的面向对象概念，因此其中的每一个节点及边线都算作一个对象。尤其是：
·所有节点类都将扩展BaseVertex基本类; ·所有边线类都将扩展BaseEdge基本类。
在 http://wiki.infinitegraph.com/w/index.php?title=Tutorial:_Hello_Graph!中所显示的展示页面中,假设人是一个节点类、而会议算作为边线类。以下是将一条边线加入到两个节点之间的代码：
Person john = new Person(\"John\\"Hello \");
helloGraphDB.addVertex(john);
Person dana = new Person(\"Dana\\"Database!\");
helloGraphDB.addVertex(dana);
Meeting meeting1 = new Meeting(\"NY\\"Graph\");
▲图三
InfiniteGraph还提供了一套可视化工具用以查看数据。由上述代码所生成的边线将如图三所示呈现出可视化效果。相比Neo4J在图一中所展现的图形模型，InfiniteGraph能够支持同时具备多种不同类别/类的节点。请注意，Neo4J中的键-值对能够对应InfiniteGraph类中的成员变量。 缺点：
·作为服务项目进行安装本身没什么问题，但配置过程完全可以更简单些。
·由于节点与边线都能成为用户的定义对象，因此在灵活性得到保证的情况下，作者怀疑当其处理庞大的图形结构时，性能方面将受到严重影响。请大家记住，NoSQL数据库一直以来所赢得的广泛关注都建立在其始终傲人的性能表现上。 3. DEX (Sparsity Technologies出品)
DEX一直被形容为一款具备高性能及优秀可扩展性的图形类数据库，这对于NoSQL应用程序来说无疑拥有相当强的吸引力。其个人评估版本最多可支持100万个节点。目前最新的版本是4.2，同时支持Java及.Net编程。请注意，旧的4.1版本只支持Java，且无法与新版本相兼容。直到文章截止之日(2011年11月24日)，4.2版本的说明文档仍不完备，而且很难在网上找到新版本的使用指导。
▲图四
图四展示的是DEX的架构，这也解释了为什么DEX能够达成如此优异的性能表现。本地C++ DEX核心正是关键所在。在此活动页面中，DEX项目团队演示了以其为基础的数款令人兴奋的应用程序：
·书目探索: DEX使用实例，存储着DBLP(即数字书目索引与图书馆项目)中的所有数据(点此进入演示);
·在DEX中载入Twitter: 其中包括45亿个图形;
·在DEX 及Query中载入维基百科: 效果明显好于Neo4J。
DEX在安装方面同样简便，大家只需要一个JAR文件并加以运行即可。与Neo4J不同，DEX的当前数据库只是一个单独的文件。DEX Java API同样易于使用，而图形类则几乎能够提供任何一项大家需要的操作。不过DEX也并非完善无缺，相信摒除下列缺点的DEX会在发展的道路上走得更远：
·最好将个人版的节点上限数量提升到10亿; ·尽快提供完备的说明文档与更好的应用实例; ·在短期之内将旧版本中的图形算法移植到新版本中。
点击此处查看另一篇文章，其中详细阐述了在DEX中部署图形的流程。
4. InfoGrid (Netmesh Inc.出品)
InfoGrid一直标榜自己是一款“网页图形数据库”，也就是说它的某些功能主要面向网页应用程序。图五展示了InfoGrid的整体框架，而图形数据库在其中所扮演的似乎并不是主要组成部分。InfoGrid在OpenID项目中也拥有几款应用程序，该项目同样由Netmesh公司所支持。作者怀疑InfoGrid这套东西其实只在Netmesh公司内部使用，因为它存在着以下硬伤：
·此处公布的最新Java API并不完善，且在某些地方有混淆情况; ·此处公布的使用教程语意含糊且不够正式。
▲图五
点击如下链接 http://infogrid.org/wiki/Examples/FirstStep可以查看首个应用实例。虽然总体来说在阅读方面没什么难度，但像TAGLIBRARY, TAG, TAG_LABEL以及TAGLIBRARY_COLLECTS_TAG这类内容的大量出现却让人相当困惑。这些内容似乎嵌入在模块当中，为什么会这样?看起来该应用实例其实是用在Netmesh公司的某个内部项目中的，旨在为某些特定应用程序提供服务。 5. HyperGraphDB (Kobrix Inc.出品)
HyperGraphDB是一套开源数据存储机制，并依托于BerkeleyDB数据库存在。HyperGraphDB的图形模型被称为直接式超图形。从数学角度来讲，超图形允许其一条边线指向两个以上的节点。HyperGraphDB在此基础上更进一步，允许一条边线指向其它边线，如此一来HyperGraphDB在概括性方面就大大超过了其它图形类数据库。图六显示的就是四条边线在超图形实例中的情况，各边线以不同颜色加以区分。
▲图六
HyperGraphDB教程似乎比较完备。HyperGraphDB中的每个节点被称为一个原子，而索引及遍历等操作也得到了良好的支持。
备注:尽管这份教程写得不错，但同样的错误提示“….dll: Can’t find dependent libraries”仍然在Win 7操作系统中出现。在作者改用Ubuntu 64位系统后，示例程序弹出如下异常信息：“ELFCLASS32 (错误原因分析: 架构字元宽度不匹配)”。这可能是因为HyperGraphDB只支持32位Linux系统。
6. Trinity (微软出品)
微软不久之前才刚刚携Trinity首个发布版本V0.1(只允许企业内网接入)加入角逐。根据介绍，Trinity是一款基于内存的图形存储机制，且具备丰富的数据库功能，其中包括高并行性联机查询处理、ACI事务支持等等。在图形处理方面，Trinity只为用户提供了C# API。
由于Trinity软件包还不对微软公司之外公开，因此目前尚无法获悉更多细节信息。不过至少Trinity拥有以下关键性功能： ·使用超图形作为数据模型; ·适合部署于公布式模型中。
Trinity的系统架构可点此查看。总体而言，在将Trinity与其它开源图形类数据库进行比较时，我们很难发现它所独有的明显优势。然而，由于Trinity仍处于开发原型阶段，因此适当加以关注也是必要的。此外，Probase作为一个进行中的项目，似乎在本体论/分类法知识方面将Trinity当成了理论基础。点击此处可以查看另一篇讨论Probase与Trinity的好文。
7. AllegroGraph (Franz Inc.出品)
AllegroGraph是一款老牌图形类数据库了，据称其负载“数十亿RDF(即资源描述框架)三元组仍可保持高性能”。尽管RDF三元组可以作为边线来处理，但AllegroGraph的原本设计意图是创建以RDF为中心的语义网络应用程序，并支持SPARQL、RDFS++以及Prolog等由包括Java程序在内的各类客户应用推衍得出的程序。AllegroGraph RDFStore免费版本支持最多5000万个三元组。
▲图七
图七展示的正是RDF图形实例。AllegroGraph为每个三元组配备了一个名为“命名图”的额外接口，这就使得三元组成为四边形结构(但为了方便起见仍称其为三元组)。以下是作者根据图七内容所做出的判断：
主语 谓语 对象 图形 Robbie …的宠物 jans jans的主页 …的宠物 反义 拥有宠物 英语语法 狗 子分类 哺乳动物 科学
要在RDF图形中添加大量三元组，AllegroGraph提供了一套批量加载N个三元组与RDF/XML文件的工具。总而言之，AllegroGraph是RDF存储的上佳选择，但一般图形则不太适合用这套方案。说明文档似乎相当冗长。点击此处可以查看介绍与Java API教程，Sesame版本点此而Jena版本点此。 总体比较
总体比较结果如下表所示。每款产品似乎都支持高性能及分布式部署。“1M”是指对应图形数据库可以支持100万个免费节点。RDF图形可以被看作一种特殊属性的图形。由于超图形是目前图形格式中最常见的类型，因此支持超图形的数据库在理论上也应该会支持属性图形。
Neo4j InfiniteGraph DEX
InfoGrid
HyperGraphDB Trinity
AllegroGraph
说明文档质量
好
好
一般
差
好
差
好
便携性如何
好
是否支持Java 是否免费 是否支持属性图 是否支持超图形
否
否
否
否
是
是
否
是
是
是
是
是
是
RDF
是 是
差 是 < 1M
好 是 < 1M
好 是 是
好 是 是
差 否 否
差 是 < 50 M
暂定排名:
哪款数据库能够胜出?哈哈，还是老答案，“取决于实际需求”。尽管对具备不同特点的产品进行排名总会惹来激烈的辩论，但有时我们还是需要做出这个“艰难的决定”。作者根据个人理解给出了以下排名结果：
·如果大家需要存储RDF三元组，那么AllegroGraph是首选; ·处理属性图，Neo4J与DEX是当仁不让的利器; ·处理超图形，HyperGraphDB堪称行家。
因篇幅问题不能全部显示，请点此查看更多更全内容