原文：http://blog.baojie.org/2012/12/03/graph-databas/
2012年4月到12月間一些關於Graph Database微博的匯總
http://www.weibo.com/xiguadawanzitang/profile?is_tag=1&tag_name=GraphDB
OWL推理一個思路是通過hypertableau，做模型構造。另一個思路是作為圖論問題，通過圖的
構造，最大化可並行性任務(如“或”)。在推理任務的另一端，簡單如 semantic wiki的推理，我們
也發現推理的所有任務都可以歸結到圖的路徑計算。http://t.cn/zjVMZsw 用圖數據庫做語義網的
數據平台是很自然的
我個人最喜歡OrientDB，知識建模靈活，內置推理，查詢語法易懂。唯一的問題是那個公司太
小，還沒有證明自己的穩定性，用的人很少。Titan如果發展好了，很有希望，陣容很強大，但
是現在還早了點。Neo4j用的人最多，不過能力最弱//@盧小東-知識梳理: 如果要兼顧語義知識
庫管理的難度，不知道哪個更適合？
另外，圖數據庫往往和其他數據庫結合，做多級存儲，獲得性能和表達力的折衷。其實數據庫
的大部分並不需要圖查詢。搞大點的內存，用內存模式跑圖數據庫，持久化非圖結構數據到其
他，比如mongodb或elastic aearh//@SiDT:使用Neo4j，規模大了，性能會有問題。ID不能指定，
有其他更好推薦嗎
回復@SiDT:看你的規模有多大。幾十萬用戶的話，做適當的數據分割，neo4j應該可以拿下。
orientdb的並行版本應該也可以。Titan並行支持最好，在cassandra和hbase上都能跑；不過太
新，文檔不全，各種編程接口也很初級 //@SiDT:使用Neo4j，規模大了，性能會有問題。ID不能
指定，有其他更好推薦嗎
關聯圖數據庫和elastic search。甚至可能用gremlin或類似orientdb sql的語言直接檢索索引
//@SiDT:存取和關系計算是強項，但檢索是難點，有好的方案么
圖數據庫比語義數據庫好的四個原因 1 構造更簡單，對字符串更友好，避免過早優化 2 對大規
模並行支持好，有現成的解決方案 3 工具系統集成好，json數據交換 4 本身支持sparql甚至推
理，所以相對語義數據庫並沒失去什么
回復@個體小知: pregel和hama之類，表達力有限，一般適合傳統圖論操作，和titan, orientdb,
neo4j這種圖形數據庫比，上面還要再包裝一層屬性圖查詢語言才能好用。但是這種包裝現在還
沒有。Titan在大規模分布式上已經做得很好了 //@個體小知:所以適合不大不小，夾在中間的公
司使用
在各種圖數據庫里，Titan是個新生，不過貌似潛力驚人 http://t.cn/zlboiMo 。作者Marko
Rodriguez就是圖數據庫標准Blueprint的奠基人
其實在這個三個里面, OrientDB算是最容易用的，。pregel現在支持硬盤模式嗎？對小公
司，prege，hama這些都有點重了。 //@個體小知: 貌似是夾在中間，論成熟文檔易上手不如
neo4j，論性能強大靈活不如pregel
OrientDB文檔通讀了一遍。幾個感想1) 比Neo4j靈活，強大，但是文檔不夠全，bug不知道會不
會多 2) 貌似比neo4j更能支持cluster，節點自動組網，每節點可以每秒15萬條插入，100萬用戶
以下應該都夠用 3) 適合不懂語義、圖DB，只懂SQL的程序員來學習 4） 內置推理，連推理機都
不用了。 5）SPARQL可以去死了
RDF數據庫由於三元組的無組織性(organization, context)，索引結構不免復雜和冗余。同樣規模
的數據，triple store和圖數據庫比，磁盤空間消耗常大10倍，相應的I/O和網絡消耗都大，性能
上不能滿足需求也就可以理解了
數據冗余和實時一致性在Web應用中通常都不是問題。在數據源分布、用戶行為被驗證之前就
明確（符合第三范式的）數據schema本質上是一種過早優化。RDF引入schema，特別是OWL，
是推理的過早優化。圖數據庫則把存儲結構和推理變成逐步驗證的過程，優化用戶需要部分，
很適合lean startup的原則
RB+-tree在圖形數據庫中做索引，做局域索引，據說上可以和圖本身的大小無關。很神奇
Web 1.0的模型是普通圖。Web 3.0的模型可能是屬性圖(Property Graph)。肯定不是RDF Graph
其實RDF1.1努力的方向就是把RDF變得更像一個圖數據庫(graph database)語言。那為何不直接
用圖數據庫呢？工程的穩定性還更好些。Freebase底層就是圖數據庫
到底是OrientDB好呢，還是neo4j好？糾結，糾結
不允許字符串做主語subject是RDF讓人很不爽的一個地方。有這限制是為了模型論語義——這
是整個W3C體系的一個問題: 工程的方便性讓位於模型論語義的精確性。在RDF OWL RIF
SPARQL里我們反復看到這個主題。這大概是非W3C的graph database后來居上的原因吧
RDF用URL做節點和關系的名字困惑了很多人。很多場合下，沒必要精確到URL這個級別，字符
串就很好了。Property graph在這點上比RDF GRAPH方便很多
什么是圖形數據庫? 本質上是分布式索引。
最近在看Graph Database, 不禁想，搞這個的，其實也就是一小群hacker，和美國歐洲各大學校
+公司+W3C不能比，結果兩三年的功夫，把多少億美元投入、成千上萬的研究人員、上十個工
作組在“語義網”上的工作生生得給比下去了。什么叫實事求是的力量啊，這就是
例證：http://t.cn/zOKYqXR 在Google Insights里，neo4j一家就單挑triple store和SPARQL了。
Blueprint技術堆棧比語義網的W3C蛋糕模型看起來要靠譜得多。 http://t.cn/zOKYPma 現在用
Blueprint方案數據庫的用戶（比如neo4j）要遠遠多於RDF triple store。這還只是多種非W3C路
線的語義網解決方案的一種。
更正：Neo4j的商業版本也要2.4萬美元一年（或者AGPL，最嚴格的開源協議）。我一開始以為
是免費的。
從web到semantic web，從數學上講不過是從single relation graph到multi-relation graph。可這么
一個”簡單”的進步，在工程上大概要花30年才能完全實現。這個世界的進步，並沒有想象的那
么快
純nerdness：Gremlin是一個圖靈機完備的查詢語言。從表達力上講，啥都可以說。定義個
SPARQL到Gremlin的轉化理論上是可以做到的。所以所有的graph database都是SPARQL-ready
RDF Virtual Machine by Marko A. Rodriguez http://t.cn/zOK7kFT 有點意思。這位老哥是圖形數據
庫的主要人物之一，Germlin的發明人。
語義網的數據庫也該考慮支持支持Gremlin
Neo4j讓我特別滿意的一點是支持SPARQL。這樣RDF數據庫的靈活性和圖數據庫的強大性都有
了。AllegroGraph也可以同時做到這兩點，就是商業版本貴點。
開始：忍受不了RDB僵硬的表結構=>使用鍵,值數據庫；發現完全沒有結構也不好=>使用文檔數
據庫；發現文檔結構其實也很討厭，特別是沒join => 使用圖數據庫；發現其實上述其實都是
圖，但很快就有越來越多復雜的路徑查詢=>把這些查詢寫死在代碼里；能不能不寫死呢 =>恭
喜，您現在是語義網的程序員了。