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 官方文檔鏈接