日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

什么是圖數(shù)據(jù)庫以及應(yīng)用范圍？

圖數(shù)據(jù)庫是 NoSQL 的一種，一種將關(guān)聯(lián)數(shù)據(jù)的實(shí)體作為頂點(diǎn)，關(guān)系作為邊來存儲(chǔ)的特殊類型數(shù)據(jù)庫，能夠高效地對(duì)這些點(diǎn)邊結(jié)構(gòu)進(jìn)行存儲(chǔ)、檢索和查詢。它的優(yōu)點(diǎn)是可以很自然地表示現(xiàn)實(shí)世界。比如社交關(guān)系（可以清楚地看到共同好友）、股東關(guān)系甚至銀行賬戶流動(dòng)關(guān)系。

圖片

圖片

屬性圖

從數(shù)學(xué)角度來說，圖論是研究建模對(duì)象之間關(guān)系結(jié)構(gòu)的學(xué)科。但是從工業(yè)界使用的角度，通常會(huì)對(duì)基礎(chǔ)的圖模型進(jìn)行擴(kuò)展，稱為屬性圖模型。屬性圖通常由以下幾部分組成：

• 節(jié)點(diǎn)，即對(duì)象或?qū)嶓w。
• 節(jié)點(diǎn)之間的關(guān)系，通常簡稱為邊（Edge）。通常邊是有方向或者無方向的，以表示兩個(gè)實(shí)體之間有持續(xù)的關(guān)系。

在屬性圖模型中，每個(gè)頂點(diǎn)包括:

• 唯一的標(biāo)識(shí)符。
• 出邊的集合。
• 入邊的集合。
• 屬性的集合 (鍵-值對(duì))

每個(gè)邊包括 :

• 唯一的標(biāo)識(shí)符。
• 邊開始的頂點(diǎn)(尾部頂點(diǎn))
• 邊結(jié)束的頂點(diǎn)(頭部頂點(diǎn))
• 描述兩個(gè)頂點(diǎn)間關(guān)系類型的標(biāo)簽。
• 屬性 的集合 (鍵-值對(duì))。

很多數(shù)據(jù)可以建模為圖。典型的例子包括 :

社交網(wǎng)絡(luò)

頂點(diǎn)是人，邊指示哪些人彼此認(rèn)識(shí) 。

Web 圖

頂點(diǎn)是網(wǎng)頁，邊表示與其他頁面的 HTML 鏈接。

公路或鐵路網(wǎng)

頂點(diǎn)是交叉路口，邊表示他們之間的公路或鐵路線。

公司股權(quán)關(guān)系

點(diǎn)的屬性可以為股票代碼、簡稱、市值、板塊等；邊的屬性可以為股權(quán)。

有很多著名的算法可以在這些圖上運(yùn)行。例如，汽車導(dǎo)航系統(tǒng)搜索道路網(wǎng)中任意兩點(diǎn)之間的最短路徑，PageRank 可以計(jì)算 Web 圖上網(wǎng)頁的流行度，從而確定搜索排名。

在政采云，可以有很多使用的場(chǎng)景，比如：

1.項(xiàng)目圖譜，項(xiàng)目、供應(yīng)商、專家可以用圖中的點(diǎn)來表示，項(xiàng)目的中標(biāo)供應(yīng)商、評(píng)標(biāo)專家可以用邊來表示。

圖片

2.商品圖譜，商品、協(xié)議可以作為頂點(diǎn)，商品的合規(guī)、交易可以作為邊。

圖片

3.安全風(fēng)控： 業(yè)務(wù)部門有內(nèi)容風(fēng)控的需求，希望在專家、供應(yīng)商、代理機(jī)構(gòu)中通過多跳查詢來識(shí)別圍標(biāo)、竄標(biāo)等行為。

數(shù)據(jù)庫關(guān)系和選擇什么數(shù)據(jù)庫？

數(shù)據(jù)模型可能是開發(fā)軟件最重要的部分，它們不僅對(duì)軟件的編寫方式，而且還對(duì)如何思考待解決的問題都有深遠(yuǎn)的影響。

大多數(shù)應(yīng)用程序是通過一層一層疊加數(shù)據(jù)模型來構(gòu)建的 。每一層都面臨的關(guān)鍵問題是:如何將其用下一層來表示?例如 :

1. 作為一名應(yīng)用程序開發(fā)人員，觀測(cè)現(xiàn)實(shí)世界(其中包括人員、組織 、貨物 、行 為、資金流動(dòng)、傳感器等)，通過對(duì)象或數(shù)據(jù)結(jié)構(gòu)，以及操作這些數(shù)據(jù)結(jié)構(gòu)的 API 來對(duì)其建模。這些數(shù)據(jù)結(jié)構(gòu)往往特定于該應(yīng)用。
2. 當(dāng)需要存儲(chǔ)這些數(shù)據(jù)結(jié)構(gòu)時(shí)，可以采用通用數(shù)據(jù)模型(例如 JSON 或 XML 文檔、 關(guān)系數(shù)據(jù)庫中的表或圖模型)來表示。
3. 數(shù)據(jù)庫工程師接著決定用何種內(nèi)存、磁盤或網(wǎng)絡(luò)的字節(jié)格式來表示上述 JSON/XML/關(guān)系/圖形數(shù)據(jù)。數(shù)據(jù)表示需要支持多種方式的查詢、搜索、操作和處理數(shù) 據(jù)。

這和我們通常說的 MVC 模型也有點(diǎn)相似，數(shù)據(jù)層、應(yīng)用層、展示層都需要接受上一層的數(shù)據(jù)模型，通過封裝和處理給下一層使用。

這里說到數(shù)據(jù)模型，主要是為了說明不同的數(shù)據(jù)關(guān)系是我們選擇不同的數(shù)據(jù)庫的原因，因?yàn)椴煌臄?shù)據(jù)模型對(duì)應(yīng)了更適合哪種數(shù)據(jù)關(guān)系。

關(guān)系模型

現(xiàn)在最著名的數(shù)據(jù)模型可能是 SQL，它基于 Edgar Codd 于1970年提出的關(guān)系模型: 數(shù)據(jù)被組織成關(guān)系( relations)，在SQL中稱為表( table)，其中每個(gè)關(guān)系者J)是元組(tuples)的無序集合 (在 SQL中稱為行)。

多對(duì)多關(guān)系是不同數(shù)據(jù)模型之間的重要區(qū)別特征 。

如果數(shù)據(jù)大多是一對(duì)多關(guān)系(樹結(jié)構(gòu)數(shù)據(jù))或者記錄之間沒有關(guān)系，那么文檔模型是最合適的 。

但是，如果多對(duì)多的關(guān)系在數(shù)據(jù)中很常見呢 ?關(guān)系模型能夠處理簡單的多對(duì)多關(guān)系， 但是隨著數(shù)據(jù)之間的關(guān)聯(lián)越來越復(fù)雜，將數(shù)據(jù)建模轉(zhuǎn)化為圖模型會(huì)更加自然。

雖然關(guān)系型數(shù)據(jù)庫與文檔類型的數(shù)據(jù)庫，都可以用來描述圖結(jié)構(gòu)的數(shù)據(jù)模型，但是，圖（數(shù)據(jù)庫）不僅可以描述圖結(jié)構(gòu)與存儲(chǔ)數(shù)據(jù)本身，更著眼于處理數(shù)據(jù)之間的關(guān)聯(lián)（拓?fù)洌╆P(guān)系。具體來說，圖（數(shù)據(jù)庫）有這么幾個(gè)優(yōu)點(diǎn)：

• 圖是一種更直觀、更符合人腦思考直覺的知識(shí)表示方式。這使得我們?cè)诔橄髽I(yè)務(wù)問題時(shí)，可以著眼于“業(yè)務(wù)問題本身”，而不是“如何將問題描述為數(shù)據(jù)庫的某種特定結(jié)構(gòu)（例如表格結(jié)構(gòu)）”。
• 圖更容易展現(xiàn)數(shù)據(jù)的特征，例如轉(zhuǎn)賬的路徑、近鄰的社區(qū)。例如，如果要分析某個(gè)公司的股權(quán)關(guān)系，表的組織方式如下：

圖片

這顯然沒有圖數(shù)據(jù)庫直觀：

圖片

我們都知道關(guān)系型數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫，目前最廣泛使用的關(guān)系型數(shù)據(jù)庫有 Mysql、Oracle 和 Postgre。NoSQL 數(shù)據(jù)庫其實(shí)不是一個(gè)合適的詞，因?yàn)樗鋵?shí)并不代表具體的某些技術(shù)。

NoSQL 可以分為以下幾種數(shù)據(jù)庫：

1.文檔數(shù)據(jù)庫，比如 MongoDB 和 Elasticsearch;

2.鍵值數(shù)據(jù)庫，比如 Redis。

3.列式存儲(chǔ)，比如 HBase、Cassandra、HadoopDB

4.最后一種就是今天要說的圖數(shù)據(jù)庫，圖數(shù)據(jù)庫以點(diǎn)、邊、屬性的形式存儲(chǔ)數(shù)據(jù)。其優(yōu)點(diǎn)在于靈活性高，支持復(fù)雜的圖形算法，可用于構(gòu)建復(fù)雜的關(guān)系圖譜。常見的圖數(shù)據(jù)庫有：NebulaGraph、Neo4j、OrientDB、 DGraph等。

圖數(shù)據(jù)庫的類型和選型

在圖數(shù)據(jù)庫的選型上我們主要考慮遺下四點(diǎn)：

• 項(xiàng)目開源，暫不考慮需付費(fèi)的圖數(shù)據(jù)庫；
• 分布式架構(gòu)設(shè)計(jì)，具備良好的可擴(kuò)展性；
• 毫秒級(jí)的多跳查詢延遲；
• 支持千億量級(jí)點(diǎn)邊存儲(chǔ)；

現(xiàn)在有圖數(shù)據(jù)庫產(chǎn)品

	JanusGraph	Nebula Graph	Dgraph（原谷歌團(tuán)隊(duì)）	Neo4j
開放性	完全開源，Java 開發(fā)	企業(yè)版和社區(qū)版差異體現(xiàn)不具體	部分管理工具差距	閉源
部署成本	需要額外部署Hbase,Cassanda	原生	原生	原生
學(xué)習(xí)成本	gremlin 查詢語句，apache 推薦，java 語言開發(fā)	nGQL，C++ 語言開發(fā)	DQL,類似 GraphQL	cypher 查詢
實(shí)踐案例	ebay、360、redhat	美團(tuán)、騰訊、知乎	思科、西門子、貝殼	國外目前最廣泛使用
社區(qū)&文檔	不活躍，文檔數(shù)量尚可	活躍，中文友好，官方中文文檔	活躍，中文不友好，文檔較少	有社區(qū)版
分布式支持	原生支持	原生支持	原生支持	支持

我們將圖數(shù)據(jù)庫分為三類：

• 第一類：Neo4j[3]、ArangoDB[4]、Virtuoso[5]、TigerGraph[6]、RedisGraph[7]。 此類圖數(shù)據(jù)庫只有單機(jī)版本開源可用，性能優(yōu)秀，但不能應(yīng)對(duì)分布式場(chǎng)景中數(shù)據(jù)的規(guī)模增長，即不滿足選型要求
• 第二類：JanusGraph[8]、HugeGraph[9]。 此類圖數(shù)據(jù)庫在現(xiàn)有存儲(chǔ)系統(tǒng)之上新增了通用的圖語義解釋層，圖語義層提供了圖遍歷的能力，但是受到存儲(chǔ)層或者架構(gòu)限制，不支持完整的計(jì)算下推，多跳遍歷的性能較差，很難滿足 OLTP 場(chǎng)景下對(duì)低延時(shí)的要求，即不滿足選型要求。
• 第三類：DGraph[10]、NebulaGraph[11]。 此類圖數(shù)據(jù)庫根據(jù)圖數(shù)據(jù)的特點(diǎn)對(duì)數(shù)據(jù)存儲(chǔ)模型、點(diǎn)邊分布、執(zhí)行引擎進(jìn)行了全新設(shè)計(jì)，對(duì)圖的多跳遍歷進(jìn)行了深度優(yōu)化，基本滿足我們的選型要求。

DGraph 是由前 Google員工 Manish Rai Jain 離職創(chuàng)業(yè)后，在 2016 年推出的圖數(shù)據(jù)庫產(chǎn)品，底層數(shù)據(jù)模型是 RDF（實(shí)際上也是屬性圖差不多），基于 Go 語言編寫，存儲(chǔ)引擎基于 BadgerDB 改造，使用 RAFT 保證數(shù)據(jù)讀寫的強(qiáng)一致性。

NebulaGraph 是由前 Facebook 員工葉小萌離職創(chuàng)業(yè)后，在 2019 年推出的圖數(shù)據(jù)庫產(chǎn)品，底層數(shù)據(jù)模型是屬性圖，基于 C++ 語言編寫，存儲(chǔ)引擎基于 RocksDB 改造，使用 RAFT 保證數(shù)據(jù)讀寫的強(qiáng)一致性。

實(shí)時(shí)寫入性能

圖片

查詢性能

圖片

在查詢和插入的性能測(cè)試方面，兩個(gè)數(shù)據(jù)庫各有優(yōu)劣，都能滿足我們的需求，我們最后選擇了 Dgraph 作為我們使用的圖數(shù)據(jù)庫，因?yàn)閮蓚€(gè)原因：

• NebulaGraph 不支持模糊查詢，需要依賴 ElasticSearch，運(yùn)維成本較高，
• Dgraph 是使用RDF通用數(shù)據(jù)類型，遵守 w3c 查詢語句規(guī)范，而 NebulaGraph 的查詢是 nGQL，自己開發(fā)的一套語言，不具有通用性

Dgraph

一、架構(gòu)模型

圖片

dgraph可以分為三個(gè)部分：ratel、alpha、zero。

ratel：提供用戶界面來執(zhí)行數(shù)據(jù)查詢，數(shù)據(jù)修改及元數(shù)據(jù)管理。

alpha：用于管理數(shù)據(jù)（謂詞和索引），外部用戶主要都是和 alpha 進(jìn)行數(shù)據(jù)交互。

zero：用于管理集群，并在 group 之間按照指定頻率去均衡數(shù)據(jù)。alpha 節(jié)點(diǎn)分成若干個(gè) group，每個(gè) group 存儲(chǔ)若干個(gè)數(shù)據(jù)分片。由于分片的大小是不均勻的，因此不同 group 也是不均勻的。zero 節(jié)點(diǎn)的任務(wù)之一就是平衡 group 之間的數(shù)據(jù)大小。具體方法是，每個(gè) group 周期性地向 zero 報(bào)告各個(gè)數(shù)據(jù)分片的大小。zero 根據(jù)這個(gè)信息在 group 之間移動(dòng)分片，使得每個(gè) group 的磁盤利用率接近。

group：多個(gè) alpha 組成一個(gè) group，group 中的多個(gè) alpha 通過 raft 協(xié)議保證數(shù)據(jù)一致性。

二、擴(kuò)展、復(fù)制和分片

每個(gè)集群將至少有一個(gè) Dgraph 零節(jié)點(diǎn)和一個(gè) Dgraph Alpha 節(jié)點(diǎn)。然后以兩種方式擴(kuò)展數(shù)據(jù)庫。

高可用性復(fù)制

為了實(shí)現(xiàn)高可用性，Dgraph 使用三個(gè)零和三個(gè) alpha 運(yùn)行，而不是每個(gè)一個(gè)。

對(duì)于大多數(shù)生產(chǎn)應(yīng)用程序所需的規(guī)模和可靠性，建議使用此配置。

擁有三臺(tái)服務(wù)器既可以使整個(gè)集群的容量增加三倍，也可以提供冗余。

分片

當(dāng)數(shù)據(jù)大小接近或超過 1 TB 時(shí)，Dgraph 數(shù)據(jù)庫通常會(huì)被分片，這樣完整的數(shù)據(jù)副本就不會(huì)保留在任何單個(gè) alpha 節(jié)點(diǎn)上。

通過分片，數(shù)據(jù)分布在許多節(jié)點(diǎn)（或節(jié)點(diǎn)組）中以實(shí)現(xiàn)更高的規(guī)模。

當(dāng)需要提供大規(guī)模和理想的可靠性時(shí)，分片和高可用性相結(jié)合。

自我修復(fù)

在 Dgraph 的云產(chǎn)品中，Kubernetes 用于自動(dòng)檢測(cè)、重啟和修復(fù)任何集群（HA、分片、兩者或兩者都不），以保持事物平穩(wěn)運(yùn)行并滿負(fù)荷運(yùn)行。

三、數(shù)據(jù)存儲(chǔ)

在 Dgraph 中，數(shù)據(jù)的最小單位是一個(gè)三元組。三元組既可以表示一個(gè)屬性(subject-predicate-value)，也可以表示一條邊(subject-predicate-object)。Dgraph 為每個(gè)對(duì)象分配一個(gè)全局唯一的 id，稱為 uid。Uid 是一個(gè) 64 位無符號(hào)整數(shù)，從 1 開始單調(diào)遞增。

Dgraph 基于 predicate 進(jìn)行數(shù)據(jù)分片，即所有相同 predicate 的三元組形成一個(gè)分片。在分片內(nèi)部，根據(jù) subject-predicate 將三元組進(jìn)一步分組，每一組數(shù)據(jù)壓縮成一個(gè) key-value 對(duì)。其中 key 是 ，value 是一個(gè)稱為 posting list 的數(shù)據(jù)結(jié)構(gòu)。

Posting list是一個(gè)有序列表。對(duì)于指向值的 predicate(如 name)，posting list 是一個(gè)值列表；對(duì)于指向?qū)ο蟮?predicate，posting list 是一個(gè) uid 列表，Dgraph 對(duì)其做了整數(shù)壓縮優(yōu)化。每 256 個(gè) uids 組成一個(gè) block，block 擁有一個(gè)基數(shù)(base)。Block 不存儲(chǔ) uid 本身，而是存儲(chǔ)當(dāng)前 uid 和上一個(gè) uid 的差值。這個(gè)方法產(chǎn)生的壓縮比是 10。

Dgraph 的存儲(chǔ)方式非常有利于連接和遍歷，一個(gè)邊遍歷只需要一個(gè) KV 查詢。例如，找到 X 的所有粉絲，只需要用 當(dāng)做 key 進(jìn)行查詢，就能獲得一個(gè) posting list，包含了所有粉絲的 uid；尋找 X 和 Y 的公共粉絲，只需要查詢 和 的 posting lists，然后求兩者的交集。

如果有太多的三元組共享相同的 ，posting list 就變得過大。Dgraph 的解決方法是，每當(dāng) posting list 的大小超過一個(gè)閾值，就把它分成兩份，這樣一個(gè)分割的 posting list 就會(huì)對(duì)應(yīng)多個(gè) keys。這些存儲(chǔ)細(xì)節(jié)都是對(duì)用戶透明的。

四、索引

當(dāng)通過應(yīng)用函數(shù)進(jìn)行過濾時(shí)，Dgraph 使用索引來高效地搜索潛在的大型數(shù)據(jù)集。 所有標(biāo)量類型都可以被索引。

類型int、float、bool、geo只有一個(gè)默認(rèn)索引，他們都只有自己的分詞器。

對(duì)于 string 類型，支持正則表達(dá)式、fulltext、term、exact 和 hash 索引；

對(duì)于 datetime 類型，支持按年、月、日、小時(shí)索引；

對(duì)于 geo 類型，支持 nearby、within 等索引。

字符串函數(shù)	索引/分詞器
eq	hash，exact，term，fulltext
le，ge，lt，gt	exact
allofterms，anyofterms	term
alloftext，anyoftext	fulltext
regexp	trigram

索引跟數(shù)據(jù)一樣，以 key-value 的形式存儲(chǔ)，區(qū)別是 key 有所不同。數(shù)據(jù)的 key 是 ，而索引的 key 是 。Token 是索引的分詞器從 value 中獲取的，例如 hash 索引生成的 token 就是 hash 函數(shù)所計(jì)算的 hash 值。

在定義 schema 的時(shí)候，可以給 predicate 創(chuàng)建一個(gè)或多個(gè)索引。對(duì)該 predicate 的每次更新會(huì)調(diào)用一個(gè)或多個(gè)分詞器來產(chǎn)生 tokens。更新的時(shí)候，首先從舊值的 tokens 的 posting lists 中刪除相應(yīng)的 uid，然后把 uid 添加到新產(chǎn)生的 tokens 的 posting lists 里。

五、查詢

遍歷

Dgraph 的查詢通常從一個(gè) uidlist 開始，沿著邊進(jìn)行遍歷。

{
  movies(func: uid（0xb5849, 0x394c)) {
    uid
     m_name     
     code
     star{
         s_name
     }
  }
}

查詢的起點(diǎn)是 uid 為0xb5849 的單個(gè)對(duì)象，處理過程如下：

1. 查詢 、 兩個(gè) key，分別獲得一個(gè)值(或者值列表)和一個(gè) uidlist。
2. 對(duì)于 uidlist 中的每一個(gè) UID，查詢 、，獲取相應(yīng)的值。

函數(shù)

通常我們不知道 uid，需要根據(jù)名稱查詢

//查詢示例：具有dog，dogs，bark，barks，barking等的所有名稱。停止詞the which 會(huì)被刪除掉。
{
  movie(func:alloftext(name@en, "the dog which barks")) {
    name@en
  }
}

查詢 的處理過程是：

1. term 分詞器從"the dog which barks"字符串中獲取到 dog 和 barks 兩個(gè) tokens。
2. 發(fā)出兩個(gè)查詢 和 ，獲得兩個(gè) uidlist。由于使用了函數(shù) anyofterms，所以求這兩個(gè) uidlist 的并集，得到一個(gè)更大 uidlist。
3. 同查詢遍歷步驟。

過濾

過濾是查詢語句的主要成分之一。過濾條件也是由函數(shù)組成的。

{  
  me(func: anyofterms(name, "Julie Baker"))@filter(eq(sex, "female")){
    pred_A  
    pred_B {  
      pred_B1  
      pred_B2  
    }
  } 
}

深度查詢

這是一個(gè)查詢 4 度關(guān)注的語句。通過 A 的 uid 可以查詢到 E 的 name

A<-B<-C<-D<-E

{
  find_follower(func: uid(A_UID)) @recurse(depth: 4) {
    name
    age
    follows{
       name
      }
  }
}

圖數(shù)據(jù)庫的業(yè)務(wù)實(shí)踐

一、業(yè)務(wù)背景

1.知識(shí)圖譜

知識(shí)圖譜是應(yīng)客戶要求直觀的展示項(xiàng)目信息，包括招投標(biāo)供應(yīng)商、采購單位、代理機(jī)構(gòu)、評(píng)標(biāo)專家、預(yù)警、違規(guī)信息、公告信息，這些數(shù)據(jù)量在五百萬到千萬級(jí)別，后期甚至可能到上億，查詢條件復(fù)雜、數(shù)據(jù)量較大，如果使用普通的關(guān)系數(shù)據(jù)庫，難以應(yīng)對(duì)低延遲、數(shù)據(jù)量大的查詢需求?，F(xiàn)改用 Dgraph 圖數(shù)據(jù)庫，則可以輕松查詢千萬級(jí)數(shù)據(jù)。

2.機(jī)構(gòu)股權(quán)關(guān)系展示

不同于市面上的股權(quán)展示，客戶要求能展示多個(gè)公司的股權(quán)關(guān)系，包括有無共同股東。核心數(shù)據(jù)在 30萬 左右，總數(shù)據(jù)量在 500萬 左右，邊關(guān)系約有 1800萬。此需求的數(shù)據(jù)量不是特別大，但是假設(shè)股權(quán)關(guān)系復(fù)雜，理論上一家公司的股權(quán)關(guān)系可以無限套娃，舉個(gè)例子：假如 A 持有 B 股權(quán)，B 持有 C 股權(quán)，C 持有 D 股權(quán)，要查詢 D 公司的股權(quán)，則遍歷三次，深度每加一層，數(shù)據(jù)量呈指數(shù)級(jí)上升，會(huì)導(dǎo)致查詢時(shí)間久、甚至超時(shí)的現(xiàn)象。圖數(shù)據(jù)庫特有的物理索引和數(shù)據(jù)存儲(chǔ)模型，對(duì)圖的多跳遍歷進(jìn)行了深度優(yōu)化，可以滿足大數(shù)據(jù)量和多跳查詢，經(jīng)測(cè)試 Dgraph 滿足我們的性能要求。

二、解決方案

總體架構(gòu)圖

dgraph客戶端（SDK）

目標(biāo)

封裝對(duì)圖數(shù)據(jù)庫（例如：Dgraph、nebula graph）客戶端連接、查詢、寫入等操作，對(duì)外提供透明的操作接口，方便接入方低成本高效接入，減少其他團(tuán)隊(duì)學(xué)習(xí) Graph 的成本。

設(shè)計(jì)

客戶端的設(shè)計(jì)參照 Mybatis 查詢的半自動(dòng)模版配置模式，即在模版中寫半自動(dòng)的 Dgraph 語句，在代碼中將參數(shù)、條件等寫入，目前已經(jīng)完成通用模版的配置，調(diào)用方無需自己寫 Dgraph 語句，只需調(diào)用接口，構(gòu)造查詢條件，SDK 即可生成 Graphql 語句并執(zhí)行查詢，返回查詢結(jié)果。

圖片

設(shè)計(jì)框架圖

圖片

Dgrpah數(shù)據(jù)生產(chǎn)

目標(biāo)

不管是現(xiàn)有的數(shù)據(jù)還是以后實(shí)時(shí)產(chǎn)生的數(shù)據(jù)，原來的業(yè)務(wù)數(shù)據(jù)都是存儲(chǔ)在各個(gè)業(yè)務(wù)方的關(guān)系數(shù)據(jù)庫，我們都需要將歷史數(shù)據(jù)和實(shí)時(shí)增量數(shù)據(jù)導(dǎo)入到 Dgraph 數(shù)據(jù)庫。

設(shè)計(jì)

業(yè)務(wù)數(shù)據(jù)由大數(shù)據(jù)部門統(tǒng)一收集，再通過 Kfaka 消息發(fā)送給我們，我們?cè)偻ㄟ^ Dgraph 的 java 客戶端寫入到 Graph。由于數(shù)據(jù)量較大，時(shí)間較緊，我們采取批量接受 Kafka 消息，經(jīng)過轉(zhuǎn)換數(shù)據(jù)，再批量寫入數(shù)據(jù)到 Dgraph 的方式提高導(dǎo)入數(shù)據(jù)效率，在測(cè)試環(huán)境，每萬條數(shù)據(jù)只需要數(shù)秒時(shí)間，生產(chǎn)環(huán)境應(yīng)當(dāng)更快。

設(shè)計(jì)框架

圖片

總結(jié)和展望

本文一開始介紹了圖數(shù)據(jù)庫的概念和優(yōu)點(diǎn)，后面說明了數(shù)據(jù)模型、數(shù)據(jù)關(guān)系是誕生和選擇圖數(shù)據(jù)庫重要原因，中間主要是介紹 Dgraph 及其他圖數(shù)據(jù)庫的特點(diǎn)，對(duì)比各個(gè)圖數(shù)據(jù)庫和選擇 Dgraph 的原因；最后一部分是在公司業(yè)務(wù)的實(shí)踐應(yīng)用，比如解決大數(shù)據(jù)量查詢帶來的查詢緩慢的痛點(diǎn)；深度查詢帶來的難點(diǎn)，在使用方面做出的優(yōu)化，包括 sdk 的封裝和數(shù)據(jù)的導(dǎo)入。

圖數(shù)據(jù)庫的應(yīng)用，遠(yuǎn)遠(yuǎn)不止簡單的查詢。在智能問答、安全風(fēng)控、商品圖譜、數(shù)據(jù)挖掘等各方面的應(yīng)用都可以使用圖數(shù)據(jù)庫。圖數(shù)據(jù)庫在很多方面都優(yōu)于關(guān)系數(shù)據(jù)庫，更快速、更靈活、更直觀，可以預(yù)見，將來圖數(shù)據(jù)庫會(huì)更普及，根據(jù) verifiedmarketresearc, fnfresearch, marketsandmarkets, 以及 gartner 等智庫的統(tǒng)計(jì)和預(yù)測(cè)，圖數(shù)據(jù)庫市場(chǎng)（包括云服務(wù)）規(guī)模在 2019 年大約是 8 億美元，將在未來 6 年保持 25% 左右的年復(fù)合增長(CAGR)至 30-40 億美元，這大約對(duì)應(yīng)于全球數(shù)據(jù)庫市場(chǎng) 5-10% 的市場(chǎng)份額。

參考資料

https://dgraph.io/docs/dgraph-overview/

https://dgraph.io/docs/dql/dql-syntax/dql-query/

https://docs.nebula-graph.com.cn/3.5.0/1.introduction/0-0-graph/

https://docs.nebula-graph.com.cn/3.5.0/1.introduction/0-1-graph-database/#_6

https://docs.nebula-graph.com.cn/3.5.0/1.introduction/0-2.relates/

https://tech.meituan.com/2021/04/01/nebula-graph-practice-in-meituan.html

當(dāng)前名稱：圖數(shù)據(jù)技術(shù)調(diào)研以及業(yè)務(wù)實(shí)踐
瀏覽地址：http://www.5511xx.com/article/djidoie.html