1 概述
1.1 名詞娘香、術語
圖形數(shù)據(jù)庫是NoSQL數(shù)據(jù)庫的一種類型，它應用圖形理論存儲實體之間的關系信息楚里。圖形數(shù)據(jù)庫是一種非關系型數(shù)據(jù)庫匀泊，它應用圖形理論存儲實體之間的關系信息优训。最常見例子就是社會網(wǎng)絡中人與人之間的關系。關系型數(shù)據(jù)庫用于存儲“關系型”數(shù)據(jù)的效果并不好各聘，其查詢復雜揣非、緩慢、超出預期躲因，而圖形數(shù)據(jù)庫的獨特設計恰恰彌補了這個缺陷早敬。
直觀感受圖如下：
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í)行時間對比如下表醉顽。
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ù)中隱含的信息：
l 推薦好友、商品或資訊
通過好友關系痹雅、用戶畫像仰担、行為相似性、商品相似性绩社、資訊傳播路徑等摔蓝，實現(xiàn)好友、商品或資訊的個性化精準推薦愉耙。
l 用戶分群
通過對用戶畫像贮尉、行為相似度以及好友關系等，進行用戶分群朴沿，實現(xiàn)用戶群體精準管理猜谚。
l 輿情&****社會化聆聽
通過對資訊傳播败砂、好友關系分析，識別意見領袖及熱點話題魏铅，分析傳播路徑昌犹，增強輿情分析質量。
4.2 知識圖譜應用
基于圖引擎服務的知識圖譜览芳，融合各種異構異質數(shù)據(jù)斜姥，可以支持更大的規(guī)模以及更高的性能。
l 存儲海量知識
融合各種異構異質數(shù)據(jù)沧竟，方便治理铸敏，規(guī)模可達千億級
l 知識梳理
通過圖上分析計算悟泵，合并相似本體搞坝，進行知識消歧
l 學習路徑識別及推薦
通過知識點的先修關系，識別學習路徑魁袜，針對薄弱知識點進行學習路徑推薦
4.3 金融風控應用
面對層出不窮桩撮、復雜多樣的個人和群體行為，幫助客戶挖掘出潛在的風險峰弹，為客戶保駕護航店量。
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)控與管理山林。
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)定性、運維成本畔况、易用性）。
圖 圖數(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的所以二度好友：
查詢語句如下：
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之間的對比
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架構：
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架構圖如下：
從開源、成熟度蛛砰、可擴展性罐栈、文檔豐富度、性能泥畅、穩(wěn)定性荠诬、運維成本、易用性涯捻，分布式圖數(shù)據(jù)庫Dgraph浅妆、JanusGraph與單機版本的圖數(shù)據(jù)庫進行對比，詳見下圖障癌。
6 技術選型分析
單機 Neo4j
開源社區(qū)老大凌外，毋庸置疑，資源多技術成熟涛浙。學習成本低康辑。單機首選。
分布式 JanusGraph
分布式對比：
總結一下兩種圖數(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 官方文檔鏈接
