圖數(shù)據(jù)庫調(diào)研及選型分析

1 概述

1.1 名詞娘香、術語

圖形數(shù)據(jù)庫是NoSQL數(shù)據(jù)庫的一種類型,它應用圖形理論存儲實體之間的關系信息楚里。圖形數(shù)據(jù)庫是一種非關系型數(shù)據(jù)庫匀泊,它應用圖形理論存儲實體之間的關系信息优训。最常見例子就是社會網(wǎng)絡中人與人之間的關系。關系型數(shù)據(jù)庫用于存儲“關系型”數(shù)據(jù)的效果并不好各聘,其查詢復雜揣非、緩慢、超出預期躲因,而圖形數(shù)據(jù)庫的獨特設計恰恰彌補了這個缺陷早敬。

直觀感受圖如下:

1.png

1.1.1 圖數(shù)據(jù)庫

圖數(shù)據(jù)庫即Graph DBMS,簡稱GDBMS大脉。

圖數(shù)據(jù)庫是基于圖論或圖數(shù)據(jù)模型的NoSQL數(shù)據(jù)庫類型搞监。這些數(shù)據(jù)庫由表示實體的節(jié)點和表示節(jié)點之間關系或連接的邊組成。每個節(jié)點都有一個唯一的標識符镰矿、傳出和/或傳入邊緣琐驴,以及屬性或鍵值對。

圖的概念中存在點秤标、邊绝淡、屬性等概念。

1.1.2 Vertex/Node

Vertex:節(jié)點/頂點苍姜。用于表示現(xiàn)實世界中的實體對象牢酵。

Vertex Label:節(jié)點的類型,用于表示現(xiàn)實世界中的實體類型衙猪,比如“人”馍乙,“電話”。

1.1.3 Edge/Replationship

Edge:邊垫释,用于表示頂點間的聯(lián)系丝格。

Edge Label:邊的類型,用于表示現(xiàn)實世界中的關系類型饶号,比如“屬于關系”铁追、 “認識/朋友關系”等。目前大部分圖數(shù)據(jù)庫的邊都是帶方向的茫船,分單向邊和雙向邊琅束。

1.1.4 Property

Property:屬性,用于表示頂點的附加信息算谈,采用KeyValue結構涩禀。Key就是 Property Key,Value就是具體的值然眼。

1.1.5 Lable

Lable:標簽艾船,標簽指一組擁有相同屬性的節(jié)點,但是不強制要求相同,一個節(jié)點可以有多個標簽屿岂。

1.1.6 Path

Path:路徑践宴,指圖中任意兩個節(jié)點都存在由關系組成的路徑,路徑有長短之分爷怀。

1.2 閱讀對象

本說明書的預期讀者包括:

(1)參與開發(fā)的項目人員阻肩;

(2)大數(shù)據(jù)技術人員;

(3)數(shù)據(jù)挖掘技術人員运授;

(4)上級領導烤惊;

(5)技術經(jīng)理。

2 圖數(shù)據(jù)庫的誕生及基本特征

2.1 誕生

圖數(shù)據(jù)庫依托圖論為理論基礎吁朦,描述并存儲了圖中節(jié)點與其之間的關系柒室,隨著社交網(wǎng)絡Facebook、電子商務以及資源檢索等領域的發(fā)展逗宜,急需一種可以處理復雜關聯(lián)的存儲技術雄右,而采用圖形數(shù)據(jù)庫組織存儲、計算分析挖掘低結構化且互連接的數(shù)據(jù)則更為有效锦溪,因此圖形數(shù)據(jù)庫得W逐漸從實驗室走出,同時反過來也極大地推動了圖形數(shù)據(jù)庫的飛速發(fā)展不脯。

2.2 數(shù)據(jù)庫存儲引擎

圖存儲是所有圖數(shù)據(jù)庫最重要的功能之一府怯。此功能允許數(shù)據(jù)庫用戶以圖的形式存儲信息刻诊。數(shù)據(jù)庫引擎為快速存儲、查詢牺丙、索引和檢索提供處理和索引功能则涯。具有高級索引功能的圖數(shù)據(jù)庫允許用戶從大型數(shù)據(jù)庫中快速檢索圖信息。

2.3 查詢

這是所有數(shù)據(jù)庫管理系統(tǒng)中的一個基本功能冲簿。圖數(shù)據(jù)庫通常使用關聯(lián)的圖模型粟判,最簡單的查詢技術稱為無索引鄰接。查詢功能允許用戶查找節(jié)點峦剔、掃描相鄰節(jié)點档礁、檢索邊緣和檢索屬性值。用戶還可以執(zhí)行更復雜的查詢吝沫。

2.4 可伸縮性/分區(qū)/分片

盡管很難在多個服務器之間擴展圖數(shù)據(jù)呻澜,但可以針對大型數(shù)據(jù)集、讀取性能和寫入性能進行擴展惨险。此功能的可用性和擴展能力取決于您使用的產(chǎn)品羹幸。

2.5 ACID事務

所有數(shù)據(jù)庫系統(tǒng)都具有事務處理功能。圖數(shù)據(jù)庫包括創(chuàng)建辫愉、讀取栅受、修改和刪除信息所需的工具。它們還包括實時分析和報告等功能。圖數(shù)據(jù)庫還實現(xiàn)ACID(原子性屏镊、一致性依疼、隔離性和持久性)功能,以確保持久而芥、一致和完整的事務涛贯。

2.6 深度關聯(lián)分析

原生并行圖設計提供的最重要優(yōu)勢之一就是能夠在超大圖上實時處理遍歷多步(10 步以上)的查詢。原生圖存儲(加快每次數(shù)據(jù)訪問速度)和并行處理(同時處理多個操作)相結合蔚出,可將許多用例從不可能變?yōu)榭赡堋?/p>

2.7 高級聚合及分析

除了傳統(tǒng)的按組劃分聚合之外弟翘,原生并行圖數(shù)據(jù)庫還可以執(zhí)行更復雜的聚合,這些聚合在關系型數(shù)據(jù)庫中是不可想象或不切實際的骄酗。由于采用表模型稀余,關系型數(shù)據(jù)庫上的聚合查詢受到數(shù)據(jù)分組方式的極大限制。與此相反趋翻,圖的多維度性質和新型圖數(shù)據(jù)庫的并行處理功能可讓用戶高效地分割睛琳、切分、匯總踏烙、轉換甚至更新數(shù)據(jù)师骗,而無需預處理數(shù)據(jù)或使數(shù)據(jù)進入強模式。

3 圖數(shù)據(jù)庫 VS 關系型數(shù)據(jù)庫

3.1 性能

大數(shù)據(jù)時代讨惩,人類社會的數(shù)據(jù)量呈爆發(fā)式增長辟癌。任何業(yè)務或產(chǎn)品所積累的數(shù)據(jù)一定是快速增長的,這沒有疑義荐捻,但更重要的是黍少,數(shù)據(jù)與數(shù)據(jù)之間的關系數(shù)目將呈現(xiàn)平方級增長:3個點最多有6條有向邊,4個點最多有12個有向邊处面,N個節(jié)點最多有N * (N-1)個有向邊厂置。

在傳統(tǒng)的數(shù)據(jù)庫中,隨著關系的數(shù)量和深度的增加魂角,關系查詢的效率將急劇衰減昵济,甚至崩潰。然而圖形數(shù)據(jù)庫的性能將幾乎不變野揪,即使數(shù)據(jù)每天都在增長访忿。

為了有直接的效果,下圖將不同的關聯(lián)深度囱挑,圖形數(shù)據(jù)庫與關系型數(shù)據(jù)庫執(zhí)行時間對比如下表醉顽。


2.jpg

3.2 靈活性

圖形數(shù)據(jù)模型的結構和模式隨著解決方案和行業(yè)的變化而變化。開發(fā)團隊不必提前對未來的需求進行詳盡的建模(然后在某些業(yè)務/產(chǎn)品人員要求更改后徹底地推翻重做)平挑;相反游添,新的節(jié)點系草、關系、節(jié)點的屬性還有關系的屬性都可以后期添加到現(xiàn)有結構中唆涝,完全不會危及當前的功能找都。

3.3 敏捷性

使用圖形技術開發(fā)完全符合當今的敏捷、測試驅動的開發(fā)實踐廊酣,它允許數(shù)據(jù)層支持的應用程序隨著業(yè)務需求的發(fā)展而快速迭代更新能耻。

3.4 面向對象的思維

在圖中,每個點和邊都是自包含對象實例亡驰。在基于模式的圖數(shù)據(jù)庫中晓猛,用戶定義點類型和邊類型,就像對象類一 樣凡辱。此外戒职,將點關聯(lián)至其他點的邊有點類似于對象方法,因為邊說明點可以“做”什么透乾。要處理圖中的數(shù)據(jù)洪燥,需要 “遍歷”邊,在概念上是指從一個點遍歷到相鄰點乳乌,保持數(shù)據(jù)的完整性捧韵。比較而言,在關系型數(shù)據(jù)庫中汉操,要關聯(lián)兩個記錄再来, 必須將它們相連并創(chuàng)建新的數(shù)據(jù)記錄類型。

4 圖數(shù)據(jù)庫應用案例

4.1 互聯(lián)網(wǎng)應用

在移動互聯(lián)網(wǎng)時代客情,面對龐大的社交關系其弊,媒體傳播網(wǎng)絡,幫助客戶快速膀斋、有效地發(fā)現(xiàn)海量數(shù)據(jù)中隱含的信息:

3.png

l 推薦好友、商品或資訊

通過好友關系痹雅、用戶畫像仰担、行為相似性、商品相似性绩社、資訊傳播路徑等摔蓝,實現(xiàn)好友、商品或資訊的個性化精準推薦愉耙。

l 用戶分群

通過對用戶畫像贮尉、行為相似度以及好友關系等,進行用戶分群朴沿,實現(xiàn)用戶群體精準管理猜谚。

l 輿情&****社會化聆聽

通過對資訊傳播败砂、好友關系分析,識別意見領袖及熱點話題魏铅,分析傳播路徑昌犹,增強輿情分析質量。

4.2 知識圖譜應用

基于圖引擎服務的知識圖譜览芳,融合各種異構異質數(shù)據(jù)斜姥,可以支持更大的規(guī)模以及更高的性能。

4.png

l 存儲海量知識

融合各種異構異質數(shù)據(jù)沧竟,方便治理铸敏,規(guī)模可達千億級

l 知識梳理

通過圖上分析計算悟泵,合并相似本體搞坝,進行知識消歧

l 學習路徑識別及推薦

通過知識點的先修關系,識別學習路徑魁袜,針對薄弱知識點進行學習路徑推薦

4.3 金融風控應用

面對層出不窮桩撮、復雜多樣的個人和群體行為,幫助客戶挖掘出潛在的風險峰弹,為客戶保駕護航店量。


5.png

l 實時欺詐檢測

提供實時的用戶行為檢測,識別敏感用戶鞠呈,信息不一致的用戶融师,及時識別欺詐風險

l 群體發(fā)現(xiàn)

根據(jù)錯綜復雜的人物關系分析,進行用戶分群蚁吝,識別異常群體

l 失聯(lián)人員追蹤

可以輕松發(fā)現(xiàn)多人之間的關系旱爆,通過蛛絲馬跡尋找失聯(lián)人員

4.4 企業(yè)IT應用

網(wǎng)絡&IT基礎設備規(guī)模龐大、結構復雜窘茁,幫助客戶深入了解設備狀態(tài)怀伦、設備之間的關系,實現(xiàn)全網(wǎng)絡設備智能監(jiān)控與管理山林。


6.png

l 合理規(guī)劃網(wǎng)絡

快速確定故障節(jié)點對網(wǎng)絡的影響房待,并在依賴的節(jié)點周圍推薦備用路由,在新節(jié)點規(guī)劃時精確規(guī)劃網(wǎng)絡位置

l 分析故障根因

快速輕松地識別任何網(wǎng)絡或基礎設施問題的根本原因驼抹,也讓您能更好地了解構成IT基礎架構的所有組件和關系桑孩。

l IT****基礎設施管理

通過圖形化網(wǎng)絡設備關聯(lián)關系,讓您更好地了解設備框冀、資產(chǎn)的狀態(tài)流椒,極大降低設備管理成本

5 常見開源圖數(shù)據(jù)庫

目前市場上主流的圖數(shù)據(jù)庫有: Neo4j、Arangob明也、Orientdb宣虾、Allegrograph惯裕、Ontotext Graphdb、Graph Story安岂、Titan轻猖、Stardog、Graphbase域那、Dgraph咙边、Oracle Space And Graph、Hypergraphdb次员、Blazegraph败许、Aster、Sparksee淑蔚、Velocitygraph市殷、Sqrrl Enterprise、Ibm System G Native Store刹衫、Graph Engine醋寝、Thingspan、Bitsy带迟、Apache Giraph音羞、Flockdb、Infogrid仓犬、Grapholytic嗅绰,Weaver 等

根據(jù)https://db-engines.com/en/ranking_trend/graph+dbms調(diào)研分析,各個開源圖數(shù)據(jù)庫的活躍程度搀继。見圖****圖數(shù)據(jù)庫活躍折線圖 窘面,下面依次簡單介紹活躍指數(shù)前5的圖數(shù)據(jù)庫以及分布式的兩個數(shù)據(jù)庫JanusGraph、Dgraph(主要關注其:開源叽躯、成熟度财边、可擴展性、文檔豐富度险毁、性能制圈、穩(wěn)定性、運維成本畔况、易用性)。

7.png

圖 圖數(shù)據(jù)庫活躍折線圖

5.1 Neo4j

Neo4j是一個流行的圖形數(shù)據(jù)庫慧库,它是開源的跷跪。最近,Neo4j的社區(qū)版已經(jīng)由遵循AGPL許可協(xié)議轉向了遵循GPL許可協(xié)議齐板。盡管如此吵瞻,Neo4j的企業(yè)版依然使用AGPL許可葛菇。Neo4j基于Java實現(xiàn),兼容ACID特性橡羞,也支持其他編程語言眯停,如Ruby和Python。

Neo4J使用原生的圖存儲卿泽,以高度自由且規(guī)范的方式管理和存儲數(shù)據(jù)莺债。它可以明快地顯示數(shù)據(jù)每個相關部分之間的鏈接,也可以在數(shù)據(jù)庫查詢中忽略不必要的細節(jié)签夭。對比非原生圖解決方案中齐邦,隨著信息量的增加,使用面向對象的數(shù)據(jù)庫存儲數(shù)據(jù)庫使數(shù)據(jù)操作變得越來越慢第租。Neo4J可以以每秒一百萬條的驚人速度提供結果措拇,因為數(shù)據(jù)中的鏈接部分或實體在物理上是已經(jīng)相互連接的。(性能瓶頸

l Cypher****圖查詢語言

Cypher是Neo4j的圖形查詢語言慎宾,允許用戶存儲和檢索圖形數(shù)據(jù)庫中的數(shù)據(jù)丐吓。類似關系數(shù)據(jù)庫中的SQL,Cypher設計借鑒了基于SQL趟据、Python語言慣用做法券犁。

舉例,我們要查找Joe的所以二度好友:

8.png

查詢語句如下:

MATCH

(person:Person)-[:KNOWS]-(friend:Person)-[:KNOWS]-

(foaf:Person)

WHERE

person.name = "Joe"

AND NOT (person)-[:KNOWS]-(foaf)

RETURN

Foaf

Joe認識Sally之宿,Sally認識Anna族操。 Bob被排除在結果之外,因為除了通過Sally成為二級朋友之外比被,他還是一級朋友色难。

l Gremlin

Gremlin是Apache TinkerPop框架下的圖遍歷語言。Gremlin是一種函數(shù)式數(shù)據(jù) 流語言等缀,用戶可以使用簡潔的方式實現(xiàn)對復雜的屬性圖(property graph)的遍歷或查詢枷莉。每個Gremlin遍歷由一系列步驟(可能存在嵌套)組成,每一步都在數(shù) 據(jù)流(data stream)上執(zhí)行一個原子操作尺迂。

5.2 Microsoft Azure Cosmos DB

Azure Cosmos DB 是 Microsoft 提供的全球分布式多模型數(shù)據(jù)庫服務笤妙。 只需單擊一個按鈕,即可通過 Cosmos DB 跨任意數(shù)量的全球 Azure 區(qū)域彈性且獨立地縮放吞吐量和存儲噪裕。 你可以彈性縮放吞吐量和存儲蹲盘,并通過以下常用 API 利用個位數(shù)毫秒級的快速數(shù)據(jù)訪問:SQL、MongoDB膳音、Cassandra召衔、表或 Gremlin。 Cosmos DB 為吞吐量祭陷、延遲苍凛、可用性和一致性保證提供綜合服務級別協(xié)議 (SLA)趣席,這是其他數(shù)據(jù)庫服務無法提供的。

Azure Cosmos DB通過自動縮放吞吐量醇蝴、計算和存儲來提供多主數(shù)據(jù)庫功能宣肚。

5.3 ArangoDB

Arangodb以一種非常創(chuàng)造性和靈活的方式安排數(shù)據(jù)。數(shù)據(jù)可以存儲為鍵或值對悠栓、圖或文檔霉涨,所有這些都可以通過一種查詢語言訪問。為了更安全的選擇闸迷,查詢中可以使用聲明性模型嵌纲。用戶可以在一個查詢中組合不同的模型及其特性的原因是,ArangoDB對所有數(shù)據(jù)模型都使用相同的核心和相同的查詢語言腥沽。

Arangodb獨特的特性是它能夠在一個查詢中組合不同的數(shù)據(jù)模型逮走。這使得其展示方式令人印象深刻且美觀。它比其他數(shù)據(jù)庫具有更靈活的擴展性今阳、增強的容錯性师溅、大容量的存儲能力和更低的成本。arangodb最突出的特性是foxx盾舌,這是一個用于編寫數(shù)據(jù)庫中以數(shù)據(jù)為中心的javascript框架墓臭。

5.4 OrientDB

OrientDB是第二代分布式圖數(shù)據(jù)庫,以混合數(shù)據(jù)模型為特點,它包括可以在最復雜的場景中使用復制和分片妖谴,并以Apache2許可證提供開放源代碼窿锉。ORIENTDB工作速度快,能夠在最常見的硬件上每秒存儲220000條記錄膝舅,并且支持無模式嗡载、完整和混合模式,可以使用SQL作為查詢語言之一仍稀。ORIENTDB使用身份驗證洼滚、密碼和靜態(tài)數(shù)據(jù)加密等方式為所有機密數(shù)據(jù)提供安全保護。

l ArangoDB技潘、OrientDB遥巴、Neo4J之間的對比。

表 ArangoDB享幽、OrientDB铲掐、Neo4J之間的對比


image.png

5.5 Virtuoso

RDF數(shù)據(jù)庫,運用于知識圖譜的知識存儲值桩,國外比較火熱迹炼。官方文檔也不是很友好。國內(nèi)做關聯(lián)數(shù)據(jù)的感覺也不熱颠毙,相關的資源不太好找斯入。

5.6 JanusGraph(分布式)

JanusGraph 是一個高度可擴展的分布式圖數(shù)據(jù)庫,專門用于存儲和查詢包含數(shù)千億個分布在多機群集中的極點和邊緣的圖形蛀蜜。 JanusGraph 是一個事務處理型數(shù)據(jù)庫刻两,可以支持數(shù)千個并發(fā)用戶實時執(zhí)行復雜的圖遍歷。

l 支持海量的圖數(shù)據(jù)滴某。 JanusGraph所支持的圖的大小取決于集群中機器的數(shù)量磅摹。

l 支持大并發(fā)下圖的事務和操作處理。 JanusGraph的事務處理能力與集群中的機器數(shù)量成正比霎奢,并且能夠毫秒級的響應在海量圖數(shù)據(jù)上的復雜的遍歷查詢操作户誓。

l 通過Hadoop框架支持全量圖分析和批量圖處理。

l 支持對大圖的頂點和邊進行地理位置幕侠,數(shù)值范圍和全文的檢索帝美。

l 原生支持圖形遍歷語言Gremlin

JanusGraph的存儲系統(tǒng)依賴于像Cassandra、HBase晤硕、BerkelyDB等等這樣的存儲系統(tǒng)悼潭,索引系統(tǒng)依賴于Elasticsearch、Solr舞箍、Lucene等等舰褪。也基于這些原因,它和大數(shù)據(jù)生態(tài)結合的非常好疏橄,可以很好地和Spark結合做一些大型的圖計算占拍;但缺點就是它的維護成本會非常高,依賴于這么多的外部系統(tǒng)捎迫,搭建一套JanusGraph系統(tǒng)的同時需要搭建好幾套依賴系統(tǒng)晃酒;另一方面就是穩(wěn)定性,根據(jù)經(jīng)驗來看立砸,系統(tǒng)越復雜掖疮,依賴系統(tǒng)越多,整體可控性就越差颗祝,穩(wěn)定性風險就越大浊闪,學習成本高。

下圖為JanusGraph架構:

10.jpg

5.7 Dgraph(分布式)

Dgraph是分布式螺戳,支持事務搁宾,快速的圖形數(shù)據(jù)庫,谷歌開發(fā)倔幼,DGraph 的目標是提供 Google 生產(chǎn)水平的規(guī)模和吞吐量盖腿,在超過TB的結構數(shù)據(jù)里,為用戶提供足夠低延遲的實時查詢。DGraph 支持 GraphQL 作為查詢語言翩腐,響應 JSON鸟款。

Dgraph是一個真正的分布式圖數(shù)據(jù)庫,而不是以master-slave模式復制數(shù)據(jù)全集的茂卦。它根據(jù)謂語分片何什,并在集群中備份謂語,查詢可以在任何節(jié)點上執(zhí)行等龙,連接是基于分布式的數(shù)據(jù)執(zhí)行的处渣。

Dgraph架構圖如下:


9.png

從開源、成熟度蛛砰、可擴展性罐栈、文檔豐富度、性能泥畅、穩(wěn)定性荠诬、運維成本、易用性涯捻,分布式圖數(shù)據(jù)庫Dgraph浅妆、JanusGraph與單機版本的圖數(shù)據(jù)庫進行對比,詳見下圖障癌。


10.jpg

6 技術選型分析

單機 Neo4j

開源社區(qū)老大凌外,毋庸置疑,資源多技術成熟涛浙。學習成本低康辑。單機首選。

分布式 JanusGraph

分布式對比:


11.jpg

總結一下兩種圖數(shù)據(jù)庫特性的對比:

l 架構方面:JanusGraph構建在大數(shù)據(jù)組件之上轿亮,數(shù)據(jù)管理更方便疮薇。Dgraph是分布式的,但是獨自成立一套分布式系統(tǒng)我注,數(shù)據(jù)需要通過其它手段寫入集群中按咒。

l 副本方面:JanusGraph需要依賴底層的存儲DB,HDFS但骨。Dgraph是強一致性的励七。

l 數(shù)據(jù)均衡方面: JanusGraph也是依賴底層的存儲HDFS,Dgraph支持自動均衡奔缠。

l 語言方面:JanusGraph使用了比較常用的Gremlin掠抬,而Dgraph使用基于GraphQL改進的GraphQL。

l 可視化方面:JanusGraph依賴外部系統(tǒng)展示校哎,Dgraph有自己的可視化系統(tǒng)两波。

l 維護成本方面:由于不依賴其他系統(tǒng)瞳步,Dgraph遠低于JanusGraph。

附錄 Neo4j. 常見問題

l neo4j數(shù)據(jù)庫支持最大多少個節(jié)點腰奋?最大支持多少條邊单起?

目前累積統(tǒng)計它有34.4億個節(jié)點,344億的關系氛堕,和6870億條屬性馏臭。

l 在數(shù)據(jù)庫中,讀/寫性能跟節(jié)點/邊的數(shù)量有關嗎讼稚?

這個問題意味著兩個不同的問題。單次讀/寫操作不依賴數(shù)據(jù)庫的大小绕沈。不管數(shù)據(jù)庫是有10個節(jié)點還是有1千萬個都一樣锐想。 — 然而,有一個事實是如果數(shù)據(jù)庫太大乍狐,你的內(nèi)存可能無法完全緩存住它赠摇,因此,你需要頻繁的讀寫磁盤浅蚪。雖然很多用戶沒有這樣大尺寸的數(shù)據(jù)庫藕帜,但有的人卻有。如果不巧你的數(shù)據(jù)庫達到了這個尺寸惜傲,你可以擴展到多臺機器上以減輕緩存壓力洽故。

l neo4j數(shù)據(jù)庫支持的讀/寫并發(fā)請求最大數(shù)量是多少呢?

在并發(fā)請求上面沒有任何限制盗誊。服務器的并發(fā)量更多的是依賴于操作本身的性能(高壓寫操作时甚,簡單讀,復雜的遍歷等等)哈踱,以及使用的硬件性能荒适。據(jù)粗略估計,在遍歷最簡單路徑時每毫秒可以達到1000次請求开镣。在討論了指定的用戶案例后刀诬,我們能得到更好的性能優(yōu)化方案。

l 如何進行數(shù)據(jù)庫查詢邪财?

核心 API, Traversal API, REST API, Cypher

l 官方文檔鏈接

http://neo4j.com.cn/public/docs/index.html

?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末陕壹,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子卧蜓,更是在濱河造成了極大的恐慌帐要,老刑警劉巖,帶你破解...
    沈念sama閱讀 223,126評論 6 520
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件弥奸,死亡現(xiàn)場離奇詭異榨惠,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,421評論 3 400
  • 文/潘曉璐 我一進店門赠橙,熙熙樓的掌柜王于貴愁眉苦臉地迎上來耽装,“玉大人,你說我怎么就攤上這事期揪〉粞伲” “怎么了?”我有些...
    開封第一講書人閱讀 169,941評論 0 366
  • 文/不壞的土叔 我叫張陵凤薛,是天一觀的道長姓建。 經(jīng)常有香客問我,道長缤苫,這世上最難降的妖魔是什么速兔? 我笑而不...
    開封第一講書人閱讀 60,294評論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮活玲,結果婚禮上涣狗,老公的妹妹穿的比我還像新娘。我一直安慰自己舒憾,他們只是感情好镀钓,可當我...
    茶點故事閱讀 69,295評論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著镀迂,像睡著了一般废岂。 火紅的嫁衣襯著肌膚如雪邻吭。 梳的紋絲不亂的頭發(fā)上吃型,一...
    開封第一講書人閱讀 52,874評論 1 314
  • 那天喇勋,我揣著相機與錄音,去河邊找鬼别凤。 笑死饰序,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的规哪。 我是一名探鬼主播求豫,決...
    沈念sama閱讀 41,285評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼诉稍!你這毒婦竟也來了蝠嘉?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 40,249評論 0 277
  • 序言:老撾萬榮一對情侶失蹤杯巨,失蹤者是張志新(化名)和其女友劉穎蚤告,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體服爷,經(jīng)...
    沈念sama閱讀 46,760評論 1 321
  • 正文 獨居荒郊野嶺守林人離奇死亡杜恰,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,840評論 3 343
  • 正文 我和宋清朗相戀三年获诈,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片心褐。...
    茶點故事閱讀 40,973評論 1 354
  • 序言:一個原本活蹦亂跳的男人離奇死亡舔涎,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出逗爹,到底是詐尸還是另有隱情亡嫌,我是刑警寧澤,帶...
    沈念sama閱讀 36,631評論 5 351
  • 正文 年R本政府宣布掘而,位于F島的核電站挟冠,受9級特大地震影響,放射性物質發(fā)生泄漏镣屹。R本人自食惡果不足惜圃郊,卻給世界環(huán)境...
    茶點故事閱讀 42,315評論 3 336
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望女蜈。 院中可真熱鬧,春花似錦色瘩、人聲如沸伪窖。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,797評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽覆山。三九已至,卻和暖如春泥栖,著一層夾襖步出監(jiān)牢的瞬間簇宽,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,926評論 1 275
  • 我被黑心中介騙來泰國打工吧享, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留魏割,地道東北人。 一個月前我還...
    沈念sama閱讀 49,431評論 3 379
  • 正文 我出身青樓钢颂,卻偏偏與公主長得像钞它,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子殊鞭,可洞房花燭夜當晚...
    茶點故事閱讀 45,982評論 2 361