nosql图数据库的比较

随着近年来GIS应用越来越广、应用的层次越来越深，传统的GIS平台，也随之出现了捉衣见肘的尴尬局面。

最早GIS只是作为一个数字地图的作用，用电子图形来代替纸质地图的。数字地图解决纸质地图不便于存储、检索、管理以及精度失真等问题；随之发展到分析应用等方面。GIS工具确实给人类带了一次飞跃，从简单的数理统计分析到空间分析的飞跃。人们真正从GIS中受益。然而这些应用同属于Desktop GIS。21世纪属于Web的时代，因此GIS只能与时俱进因为发展到了WEB GIS。WEB GIS如果只是作为一个展示平台，展示展示空间数据这是没有什么问题。可以将空间数据缓存化，通过缓存图片的方式为Web系统提供服务，例如现在各大地图网站，google map、百度地图、Bing Map等等都是采用的这种技术实现的。

现在所有的GIS平台厂商提供的GIS平台都是采用Web缓存技术来提供所谓的GIS应用。Web GIS刚刚起航的时候，相比传统门户网站那是相当的霸气。面子工程风波逐渐平淡，人们就开始追逐其实用性了，实用为主导的随之而来。Desktop GIS的相关应用就要求WEB化，WEB化则隐形要求系统的实时性。传统Desktop GIS可以用相当长的时间去计算一个正确的结果，因为人们只关心结果的正确性，实时性是没有做要求的。例如给某个公司做一个分析报告，可以让计算机跑上十天半个月。如果WEB GIS做应用分析，让客户在电脑面前登上十天半个月才能等到结果，绝对是不可能的。就像12306网站那种每个操作延长几分钟响应都是不可接受的。

下面分析一下，为什么传统GIS分析会如此的缓慢。现在主流的GIS平台厂商提供的GIS平台后台数据存储的数据库都是传统的关系数据库。关系数据库大伙都知道是采用关系模型建立起来的二维表的数据库，这种二维表用于存储简单信息某一刻的状态是完全满足应用的要求的。然而GIS存储的是复杂的地表地貌的特征，尽管可以将地表地貌特征抽象成点、线、面的对象，通过实体关系模型将其存储在关系数据库中。这种存储方式割裂他们之间内部的联系，要通过GIS分析重新找出它们之间的关系则是一件相当困难的事情。在关系数据库存储方式下GIS分析，是通过逐条遍历计算各个对象之间的关系的。它的计算复杂度随着数据量的剧增，随指数增长。是传统GIS分析运算缓慢的真正原因之一。还有另外一个原因就是传统GIS都是单机计算的，并没有真正的实现并行计算。（该原因我们暂不讨论）

为了满足新一代Web GIS的应用要求，我们需要从根上来解决问题——数据存储上改进。随着Nosql方面的研究不断深入，技术的不断成熟，Nosql家族的图形类数据库的也趋于成熟，因此未来采用图形数据库作为GIS数据存储方式，分析性能上将有一个很大的提升。在图形理论当中，一幅简单的图形是由一系列节点与边线所构成。事实上图形类数据库往往会赋予节点与连线更多类别与属性，以使其更具可描述性及实际应用功能。以便图形类数据库能够支持快速遍历，降低联合运算使用成本。

图形存储类产品中也以下列七种较为流行及常用：Neo4J,Infinite Graph,DEX,InfoGrid,HyperGraphDB,Trinity以及AllegroGraph。下面探讨一下这些产品及它们的细节：

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亿;

·尽快提供完备的说明文档与更好的应用实例;

·在短期之内将旧版本中的图形算法移植到新版本中。

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图形可以被看作一种特殊属性的图形。由于超图形是目前图形格式中最常见的类型，因此支持超图形的数据库在理论上也应该会支持属性图形。