GIS資料庫的發展方向探討
隨著近年來GIS應用越來越廣、應用的層次越來越深，傳統的GIS平臺，也隨之出現了捉衣見肘的尷尬局面。
最早GIS只是作為一個數字地圖的作用，用電子圖形來代替紙質地圖的。數字地圖解決紙質地圖不便於儲存、檢索、管理以及精度失真等問題；隨之發展到分析應用等方面。GIS工具確實給人類帶了一次飛躍，從簡單的數理統計分析到空間分析的飛躍。人們真正從GIS中受益。然而這些應用同屬於Desktop
GIS。21世紀屬於Web的時代，因此GIS只能與時俱進因為發展到了WEB GIS。WEB GIS如果只是作為一個展示平臺，展示展示空間資料這是沒有什麼問題。可以將空間資料快取化，通過快取圖片的方式為Web
現在所有的GIS平臺廠商提供的GIS平臺都是採用Web快取技術來提供所謂的GIS應用。Web
GIS剛剛起航的時候，相比傳統入口網站那是相當的霸氣。面子工程風波逐漸平淡，人們就開始追逐其實用性了，實用為主導的隨之而來。Desktop GIS的相關應用就要求WEB化，WEB化則隱形要求系統的實時性。傳統Desktop
GIS可以用相當長的時間去計算一個正確的結果，因為人們只關心結果的正確性，實時性是沒有做要求的。例如給某個公司做一個分析報告，可以讓計算機跑上十天半個月。如果WEB 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圖形可以被看作一種特殊屬性的圖形。由於超圖形是目前圖形格式中最常見的型別，因此支援超圖形的資料庫在理論上也應該會支援屬性圖形。
| Neo4j | InfiniteGraph | DEX | InfoGrid | HyperGraphDB | Trinity | AllegroGraph | |
| 說明文件質量 | 好 | 好 | 一般 | 差 | 好 | 差 | 好 |
| 便攜性如何 | 好 | 差 | 好 | 好 | 好 | 差 | 差 |
| 是否支援Java | 是 | 是 | 是 | 是 | 是 | 否 | 是 |
| 是否免費 | 是 | < 1M | < 1M | 是 | 是 | 否 | < 50 M |
| 是否支援屬性圖 | 是 | 是 | 是 | 是 | 是 | 是 | RDF |
| 是否支援超圖形 | 否 | 否 | 否 | 否 | 是 | 是 | 否 |
基於對上述圖形資料庫的分析，我們可以選擇我們自己需要的資料庫做我們自己的應用，拿出自己的拳頭產品。
參考資料：
本人最近一直致力於HyperGraphDB資料庫的研究工作。如果哪位仁兄有興趣可以與之一起討論學習。