大數(shù)據(jù)文摘投稿作品

知識圖譜數(shù)據(jù)庫是NoSQL數(shù)據(jù)庫中增速最快的一個分支，它在大數(shù)據(jù)和人工智能領(lǐng)域的地位逐漸凸顯。但是目前主流的圖數(shù)據(jù)庫產(chǎn)品大都屬于海外產(chǎn)品，且售價極其高昂，為了解各大主流圖數(shù)據(jù)庫的讀寫性能指標，特將國產(chǎn)的新興圖數(shù)據(jù)庫AbutionGraph（AbutionGDB）與Neo4j，JanusGraph，TigerGraph等占據(jù)著市場95%份額的主流圖數(shù)據(jù)庫做了讀寫性能對比測試。

特別說明：AbutionGDB是唯一面向OLAP（數(shù)據(jù)分析決策）場景的圖數(shù)據(jù)倉庫，而其它對比者是面向OLTP（數(shù)據(jù)增刪改查）的圖數(shù)據(jù)庫，不過這并不影響讀寫性能的測試。

? ? ? ?

表1：實時批量寫入事件數(shù)性能測試結(jié)果

? ? ? ?

表2：一度關(guān)系統(tǒng)計查詢性能測試

測試用數(shù)據(jù)說明

? ? ? ?? ? ??

測試采用的數(shù)據(jù)來源于互聯(lián)網(wǎng)的消費/轉(zhuǎn)賬記錄模擬數(shù)據(jù)，每行記錄包含6個字段，分別是:付款方帳號(4bytes長整型)、付款方名字(11bytes字符串)、收款方帳號(4bytes長整型)、收款方名字(11bytes字符串)、交易時間(7bytes日期類型)、交易金額(8bytesBigdicemal雙精度浮點數(shù))，數(shù)據(jù)長度最低是45bytes，因為交易金額的長度是個不確定的值。數(shù)據(jù)樣例如下：

圖1數(shù)據(jù)示例

圖中的數(shù)據(jù)時間戳在測試中進行了調(diào)整，進入到系統(tǒng)中的時間戳沒有采用如圖所示的非嚴格的RFC3339格式，而是使用與1970-01-0100:00:00(UTC)時間的差(精確到毫秒)的時間戳表示方式(8bytes的長整型)，進入到系統(tǒng)中的金額數(shù)據(jù)也沒有采用如圖所示的Double標準雙精度浮點數(shù)類型表示，而是采用Bigdicemal非基本類型來存儲交易金額，因為交易金額很大時，與歷史記錄聚合很可能發(fā)生損失精度的情況，由于系統(tǒng)錯誤導致的財產(chǎn)損失這是絕對不允許的。為便于測試，實際數(shù)據(jù)均由計算機隨機生成，實體數(shù)限制為10w個并按照上述格式和數(shù)據(jù)庫語法格式寫入各數(shù)據(jù)庫。

因為每款圖數(shù)據(jù)庫使用的語言和方式都不一樣，本次主要測評過程以圖譜建模的最終結(jié)構(gòu)為標準，使用的KnowledgeGraph建模如下：

統(tǒng)計結(jié)果說明

對于任何一個測試，每個操作過程重復運行5次，且最終的統(tǒng)計結(jié)果是5次測試結(jié)果的算數(shù)平均值。

每次測試進行之前均重啟數(shù)據(jù)庫服務(wù)，避免緩存對于之前執(zhí)行獲得的結(jié)果產(chǎn)生影響。

本文中所說的延遲(latency)是指全部完成該操作所耗費的時間，例如針對多條記錄的查詢操作，其時間延遲是指完全將結(jié)果獲取到客戶端后，相對于請求發(fā)出時間之間的間隔。吞吐量(throughput)是單位時間內(nèi)完整完成該操作的數(shù)量。

AbutionGDB與其他數(shù)據(jù)庫單節(jié)點對比測試

測試環(huán)境及步驟說明

所有數(shù)據(jù)庫的對比測試在同一臺8H16G的阿里云服務(wù)器上進行，該服務(wù)器的詳細配置如下:

架構(gòu)：? ? ? ? ? ? x86_64

CPU：? ? ? ? ? ? 8

CPU運行模式：? ?32-bit， 64-bit

Size：? ? ? ? ? ? 16 GB

每個核的線程數(shù)：? 2

每個座的核數(shù)：? ? 4

座：? ? ? ? ? ? ? 1

廠商ID：? ? ? ? ? GenuineIntel

CPU系列：? ? ? ? 6

型號：? ? ? ? ? ? ?85

型號名稱：? ? ? ? ?Intel(R)Xeon(R)[email protected]

CPUMHz：? ? ? ? ?2499.998

BogoMIPS：? ? ? ? 4999.99

超管理器廠商：? ? ?KVM

虛擬化類型：? ? ? ?完全

LSB Version：? ? core-4.1-amd64:core-4.1-noarch

Description：? ? CentOS Linux release 8.2.2004 (Core)

本測試將AbutionGDB與Neo4j，JanusGraph，TigerGraph等圖數(shù)據(jù)庫進行了對比，所測試的Neo4j版本為3.5.24；JanusGraph的版本為0.5.2（使用Hbase后端存儲）；TigerGraph的版本為3.0.0，而AbutionGDB的測試版本為1.3.0，截止至2021年，皆為jdk-1.8支持下的最新版本。

在測試時，AbutionGDB、Janasgraph、Neo4j均使用JavaAPI并結(jié)合各自的查詢語言進行數(shù)據(jù)操作，由于TigerGraph只提供了HTTP接口，在測試中我們采用Java語言的Apache HTTP lib庫來編寫測試程序。

AbutionGDB提供更優(yōu)異的異步接口，支持使用Flink作為大規(guī)模實時數(shù)據(jù)源寫入數(shù)據(jù)，但Janasgraph、Neo4j、TigerGraph均不支持。只有AbutionGDB和TigerGraph可以使用Kafka作為實時數(shù)據(jù)源寫入數(shù)據(jù)，為了測試一致性及公平性，僅使用各自推薦的同步接口方式進行讀寫測試。

在本次測試中，AbutionGDB、Janasgraph及TigerGraph都采用默認配置，Neo4j則只修改dbms.memory.heap.initial_size和dbms.memory.heap.max_size，由默認的512m改到5g，以最大程度發(fā)揮Neo4j性能。

為避免網(wǎng)絡(luò)延遲的影響，應用與數(shù)據(jù)庫均在同一臺服務(wù)器上運行。為更進一步控制變量，本測試確保在對每個數(shù)據(jù)庫進行測試時只有該數(shù)據(jù)庫運行，因此數(shù)據(jù)庫所能占用的CPU資源最高可達100%。

本測試測試了各個數(shù)據(jù)庫在不同客戶端連接數(shù)同時寫入和讀取不同批量數(shù)據(jù)的表現(xiàn)，且每種情況均進行至少5次測試，最終結(jié)果為5次測試結(jié)果的平均值。同時為了避免測試與測試之間的干擾，每次測試結(jié)束后，都會刪除數(shù)據(jù)，重啟數(shù)據(jù)庫服務(wù)并且等待5分鐘左右。

寫入性能對比

數(shù)據(jù)庫的一個寫入請求可以包含一條或多條記錄，性能結(jié)果取每個客戶端每秒內(nèi)同時寫入數(shù)據(jù)量的總和，并取多次平均值?？偠灾?，一次請求里包含的記錄條數(shù)越多，寫入性能就會相應提升。

同時，一個數(shù)據(jù)庫可以支持多個客戶端鏈接，鏈接數(shù)增加，其系統(tǒng)總的插入通吐量會相應增加。因此測試中，對于每一個數(shù)據(jù)庫，都會測試一個客戶端和多個客戶端連接的情況。

在AbutionGDB中，可以定義任意多維度的指標列，其中動態(tài)聚合的存儲模型是其特有的，其中預計算模型可以大大提高查詢性能，而靜態(tài)歷史數(shù)據(jù)的存儲模型是與Janasgraph、Neo4j、TigerGraph一致的，為了凸顯寫入事件的速率和查詢性能的公平性，我們定義每一條完整的原始交易數(shù)據(jù)入庫完成才作為寫入一條數(shù)據(jù)，即一條事件數(shù)，而不是以每個實體或者每條關(guān)系作為一條數(shù)據(jù)。

AbutionGDB批量實時寫入結(jié)果

此測試中，基于AbutionGDB強大的吞吐量，我們專門把寫入事件數(shù)的區(qū)間拉大，按照每次請求包含1，100，1000，10000，100000，200000條事件記錄各進行了測試，同時也測試了不同客戶端連接數(shù)的數(shù)據(jù)。具體結(jié)果如下：

批次插入事件數(shù)	1client	2client	3client	4client	5client	6client	7client
1	1339	2628	3904	5177	6516	7843	9243
100	24599	50099	71167	87467	99567	112667	136267
1000	44343	84931	119931	145931	166907	195273	235861
10000	58878	95295	130416	160418	190975	199025	236070
100000	99040	129773	172025	196447	232315	267567	251729
200000	187402	229706	207413	233558	263547	264271	267015

? ? ? ?

因本測試將3條圖數(shù)據(jù)統(tǒng)一歸為1條事件數(shù)統(tǒng)計（每條事件包含2個實體1條關(guān)系），按照數(shù)據(jù)庫寫入性能標準，以上測試結(jié)果應該均乘以3即為真實寫入速率。具體結(jié)果如下：

批次插入事件數(shù)	1client	2client	3client	4client	5client	6client	7client
1	4017	7884	11712	16713	19548	23529	36729
100	73797	150297	213501	262401	298728	338001	408801
1000	133029	254793	359793	437793	500721	585819	707583
10000	176634	285855	391248	481254	572925	597075	708210
100000	297120	389319	516075	589341	696945	802701	755187
200000	562206	689118	622239	700674	790641	792813	801045

? ? ?

上述結(jié)果清楚表明，AbutionGDB的寫入速度隨客戶端連接數(shù)的增加近乎線性增加，而且隨單請求中記錄數(shù)目的增加而增加。在七個客戶端下，一個請求，寫入1條數(shù)據(jù)時，AbutionGDB就有超過10,000記錄/秒（30,000條圖數(shù)據(jù)/秒）的寫入速度。在一個寫入請求200,000條記錄時，在7個客戶端同時寫入時的情況下，AbutionGDB有高達267,015記錄/秒（801,045條圖數(shù)據(jù)/秒）的寫入速度。同時，從上圖中可以看出，這個速度并非AbutionGDB寫入速度的上限，該速度還會隨客戶端數(shù)目的增加而增加。

Neo4j批量實時寫入結(jié)果

在測試中，我們嘗試了兩種方式來更全面的測試Neo4j寫入性能，第一種是傳統(tǒng)的JDBC方式，通過DriverManager接收SQL，同時禁用了AutoCommit，采用批量手動提交commit的方式，Neo4j本身沒有此項功能支持，需要額外下載neo4j-jdbc-driver和neo4j-jdbc-bolt擴展包支持；第二種是使用的是官方推薦的bolt Driver連接方式，此方是沒有commit方法，Neo4j自動提交數(shù)據(jù)變更，所以測試只能通過客戶端的連接數(shù)觀察寫入性能，為此，我們做了5組測試來分別觀察客戶端的連接數(shù)對于寫入性能的影響。由于Neo4j不支持BigDecimal數(shù)據(jù)類型，因而交易時間將采用Double來存儲。

通過測試發(fā)現(xiàn)，兩種方式對于寫入速率沒有實質(zhì)性差距，Neo4j的批量提交寫入并不能有效提升其寫入效率，因此僅僅記錄了Neo4j連續(xù)寫入的多個客戶端同時寫入來達到批量寫入數(shù)據(jù)的效果。結(jié)果如下：

事件數(shù)	1client	2client	3client	4client	5client
test1	72	68	63	56	59
test2	70	70	64	54	61
test3	73	68	62	55	56
test4	73	68	62	55	53
test5	72	68	66	56	57

? ? ?

從上述結(jié)果表可以看出，Neo4j僅適用于單客戶端單條記錄的寫入，多組對照實驗結(jié)果幾乎相同，證明其寫入性能并不會由于客戶端鏈接數(shù)量的增加或單請求中記錄條數(shù)的增加而顯著改變。

JanusGraph批量實時寫入結(jié)果

在測試中發(fā)現(xiàn)，JanusGraph的寫入吞吐量與客戶端連接數(shù)沒有太大關(guān)系，而與批處理時單請求中的記錄數(shù)相關(guān)。批請求中記錄數(shù)目越大，其吞吐量也越大，但是當數(shù)據(jù)量達到1w左右的時候就出現(xiàn)了嚴重的寫入抖動，速率在3000-1w/s間波動。由于客戶端連接數(shù)對JanusGraph的吞吐量影響較小，本測試只給出JanusGraph在單客戶端和雙客戶端連接情況下的測試結(jié)果，且分別對每個客戶端按照每次請求包含1，100，300，500，1000，2000，10000,20000條事件記錄作出測試。測試結(jié)果計算為每秒寫入的數(shù)據(jù)總量，多秒完成的寫入計算結(jié)果為平均值。測試結(jié)果如下:

事件數(shù)	1	100	300	500	1000	2000	10000	20000
1client	316	3700	5400	8300	8200	8000	6666	6999
2client	4140	5070	7220	5450	5950	5800	7250	6333

? ? ?

上述結(jié)果表明，JanusGraph的寫入速度隨單請求中的事件數(shù)目的增加而增加，但最終增長速度趨緩，并在每次提交事件數(shù)在1000條左右到達寫入最佳性能，同時也到達了JanusGraph的寫入瓶頸，再隨著每批次寫入數(shù)據(jù)的不斷增加，寫入性能不增反降，且最終寫入速度維持在7000事件/秒上下。

TigerGraph批量實時寫入結(jié)果

本次我們測試的是TigerGraph，由于TigerGraph官方只提供基于HTTP的REST使用接口，此方式寫入較慢，無法批量寫入，所以我們使用開源的jdbc方式，且修補了一些版本匹配問題，此方式其實是HTTP接口的一種封裝。Jdbc提供了3種寫入方法，提交job的方式是離線導入，第2種方法PreparedStatement的寫入語法對Double數(shù)據(jù)類型參數(shù)支持不友好，最終我們選擇使用Statement方法寫入，并以默認的覆蓋歷史數(shù)據(jù)的形式寫入新數(shù)據(jù)，對不同對照組的Batch進行批量提交寫入，Statement的方式可以以批量提交的方式進行寫入，與AbutionGDB，Neo4j，JanusGraph測試方式一致。

在測試過程中發(fā)現(xiàn)，TigerGraph的寫入性能與客戶端連接數(shù)沒有太大關(guān)系，與批處理時單請求中的記錄數(shù)也沒有太大關(guān)系，反而會略微拉低其它客戶端的寫入能力，所以本測試只記錄了1-5個客戶端的同時寫性能，測試結(jié)果如下：

事件數(shù)	1client	2client	3client	4client	5client
1	143	267	338	469	450
100	250	400	441	580	625
1000	350	544	588	780	971
2000	351	510	702	888	976
10000	370	606	714	848	983

? ? ?

上述數(shù)據(jù)表明，基于HTTP接口的數(shù)據(jù)寫入方式并沒有很高效，隨著客戶端連接數(shù)和實時寫入數(shù)據(jù)量的增加，寫入性能成弱線性增長。

鑒于以上TigerGraph的測試結(jié)果不是很高效，我們專門對TigerGraph測試了離線寫入能力，即load job數(shù)據(jù)寫入方式，這是官方文檔推薦的做法。為了記錄離線寫入性能，我們使用與AbutionGDB，Neo4j，JanusGraph相同的數(shù)據(jù)生成程序隨機生成一批數(shù)據(jù)到文件，并將每一條事件記錄拆分為節(jié)點數(shù)據(jù)和關(guān)系數(shù)據(jù)兩個文件分別等待寫入，然后預先分別對每批次寫入數(shù)據(jù)的5個對照組預先創(chuàng)建LOADING JOB（不計入寫入耗時中），最后在gsql腳本中執(zhí)行批量導入JOB并記錄耗時，最終統(tǒng)計得出每秒寫入性能。經(jīng)測試一兩條、幾百條等少批量數(shù)據(jù)導入對性能表現(xiàn)不明顯，為了節(jié)省測試時間，避免生成離線數(shù)據(jù)的繁瑣過程，我們將從100條每批寫入開始記錄結(jié)果。

在測試過程中發(fā)現(xiàn)，TigerGraph的寫入性能與客戶端連接數(shù)沒有關(guān)系，反而會均分掉其它客戶端的寫入能力，所以本測試只對TigerGraph在1和2客戶端連接的情況下的性能進行了測試和分析，測試結(jié)果如下：

事件數(shù)	100	1000	10000	20000	60000	100000	200000	500000
1client	17	167	1751	3076	10000	14285	28571	76923
2client	10	91	952	2371	6315	9524	21052	47619

? ? ? ?

? ? ?

上述結(jié)果表明，TigerGraph的離線寫入速度隨單請求中記錄數(shù)目的增加而增加，入庫速率與批次入庫數(shù)量成正比增長，數(shù)據(jù)寫入及與節(jié)點個數(shù)成弱線性增長，也與實時寫入測試的結(jié)果增長趨勢成線性關(guān)系。

注意：本測試不與AbutionGDB，Neo4j，JanusGraph，TigerGraph已測試過的結(jié)果進行比較，因為實時寫入涉及的數(shù)據(jù)庫cache和flush的性能是性能測試和穩(wěn)定性測試的重要指標之一，與離線數(shù)據(jù)測試機理不同，TigerGraph離線導入使用MapReduce并行寫入，這與AbutionGDB和JanusGraph中的離線導入方式基本相同，故此不再展開分別測試。

TigerGraph實時寫二次測試

由于以上TigerGraph的測試結(jié)果與官方報道的性能差距太大，所以我們決定增加測試Kafka的寫入接口，為了盡量保證公平性，我們還是使用與AbutionGDB，Neo4j，JanusGraph相同的數(shù)據(jù)生成程序隨機生成一批數(shù)據(jù)到Kafka生產(chǎn)者，并在TigerGraph中實時接收批次事件數(shù)據(jù)。每輪測試我們都將重啟TigerGraph以清除緩存影響，Kafka程序無法準確記錄寫入速率，為了反映寫入速率，我們使用TigerGraph本身的計時器，重啟時同時也清空了上一輪的計時重新計算寫入，多輪對照測試結(jié)果取均值，結(jié)果幾乎無偏差。

在測試過程中發(fā)現(xiàn)，Kafka接口無法啟動多個客戶端在同一臺服務(wù)器，也必須是配置使用所有的Kafka分區(qū)才能啟動寫入，即默認了接收所有傳來的數(shù)據(jù)，所以TigerGraph單節(jié)點寫入與多客戶端沒有太大關(guān)系，因為已經(jīng)是使用最大化資源了，所以我們只對單一客戶端測試，這與AbutionGDB，Neo4j，JanusGraph測試使用的資源幾乎是一致的。測試TigerGraph數(shù)據(jù)寫入結(jié)果截圖如下：

結(jié)果中，LOADED MESSAGES表示每批次的實時寫入事件記錄數(shù)（包含兩個實體和一條關(guān)系），DURATION表示這批次數(shù)據(jù)入庫的時間。

為了進一步去除網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)纫蛩赜绊懀覀儗γ颗螌懭牒臅r統(tǒng)一減去3-4秒的數(shù)據(jù)接入響應，包括：Kafka生產(chǎn)者被接入消費者的時間，一般為1秒左右；以及數(shù)據(jù)實時隨機生成耗時，一般為1秒左右。最終得到超低誤差的實時寫入性能如下：

每批插入數(shù)：	1w	2w	10w	20w	100w	200w	500w
入庫事件/秒：	4000	8000	13333	25000	50000	60606	80645

? ? ?

上述結(jié)果表明，TigerGraph對于超大規(guī)模數(shù)據(jù)實時寫性能表現(xiàn)較好，同時也反映了想要獲取更好的性能需要更多的服務(wù)器資源。測試中TigerGraph的Kafka實時寫入和離線寫入性能最終趨向一致，入庫速率與批次入庫數(shù)量成正比增長。TigerGraph的寫入速度與單請求中記錄數(shù)目具有極大關(guān)系，且隨著單請求中記錄數(shù)目的增加而增加，并始終保持勻速正增長，但增速緩慢。從圖中可以看出，TigerGraph在本測試實時每批次寫入5,000,000條事件記錄和離線每批次寫入500,000條事件記錄時達到最高寫入性能，寫入速度大約為80,000事件記錄/秒。

各數(shù)據(jù)庫最佳性能對比

基于以上的測試數(shù)據(jù)，將各數(shù)據(jù)庫測試出來的最佳速度進行對比，結(jié)果如下：

事件數(shù)	1client	2client	3client	4client	5client	6client	7client
AbutionGDB	187402	229706	207413	233558	263547	264271	267015
Neo4j	72	68	63	56	59	55	53
JanusGraph	8300	7250	7220	5450	5950	5800	5700
TigerGraph	80645	80645	80645	80645	80645	80645	80645

注意：因為TigerGraph多客戶端實時寫性能很差，且變化很小，所以這里使用Kafka的實時寫加入比較，但又因Kafka接入無多客戶端，所以將TigerGraph每批次寫入的最佳性能并入比較，相較于AbutionGDB，Neo4j，JanusGraph有一定優(yōu)勢為便于對比，在這里適當不計。

? ? ? ?

? ? ?

從圖中可以看出，AbutionGDB是4個圖數(shù)據(jù)庫中唯一一個寫入速度隨客戶端一致線性增加的數(shù)據(jù)庫，且其寫入速度遠遠高于其他三個數(shù)據(jù)庫，也是唯一一個突破十萬事件記錄/秒寫入速度的圖數(shù)據(jù)庫。而TigerGraph、JanusGraph和Neo4j在測試中都展示出了瓶頸。JanusGraph雖然在客戶端較少的情況下就有接近1w的事件（約2.5w實體和關(guān)系）寫入速度，但是其速度無法因客戶端增加而線性增加，從圖可知JanusGraph的瓶頸在1w事件記錄/秒。而TigerGraph的實時寫不會因為客戶端的增加而顯著增加寫入性能，始終維持在一個低水平狀態(tài)，但在Kafka接口中達到了較好的寫入性能，不過只對于大規(guī)模量級數(shù)據(jù)表現(xiàn)較好。對于Neo4j，其寫入性能不會因為客戶端的增加而提高，反而略微下降，沒有很好的并行性。

綜上所述，AbutionGDB在多客戶端連接同步寫入的速度遠遠高于同等條件下的TigerGraph、JanusGraph和Neo4j等市場主流圖數(shù)據(jù)庫。AbutionGDB在7個客戶端連接同時寫入的情況下可達到~270,000事件記錄/秒的寫入速度（約810,000條實體與關(guān)系），是已測得JanusGraph的最大寫入速度的33倍，是TigerGraph普通接口最大寫入速度的222倍，是Neo4j最大寫入速度的3709倍。

讀取性能對比

本測試做了簡單的查詢測試，就是將插入的數(shù)據(jù)全部讀出并做一度關(guān)系計算與過濾出鄰居數(shù)大于5的人。因為各大數(shù)據(jù)庫的性能差異很大，為節(jié)省測試時間，我們使用一個客戶端查詢不同的記錄條數(shù)并進行計算。測試結(jié)果如下：

查詢響應時間	AbutionGDB	TigerGraph	JanusGraph	Neo4j
10w	220	210	21040(21s)	12570(12s)
20w	212	247	40780(40s)	17920(17s)
50w	225	359	106s	137s
100w	306	377	380s	441s
1000w	679	855	無法完成	無法完成

為了方便查看，我們對每個查詢耗時轉(zhuǎn)換為統(tǒng)計查詢性能：

查詢響應時間	AbutionGDB	TigerGraph	JanusGraph	Neo4j
10w	455	476	5	8
20w	943	810	5	11
50w	2222	1392	5	4
100w	3268	2653	3	2
1000w	14727	11696	1	1

? ? ? ?

? ? ?

從圖表中可以看出，AbutionGDB的單機最大OLAP讀取速度在15,000記錄/毫秒左右，TigerGraph的最大讀取速度在12,000記錄/毫秒左右，性能幾乎相同。在AbutionGDB中，實現(xiàn)原理是基于特有的預計算模型，數(shù)據(jù)在寫入的時候就已經(jīng)自動完成了部分規(guī)則統(tǒng)計，查詢時僅需少量后計算資源即可得到結(jié)果，這與實時數(shù)據(jù)倉庫的特性是類似的。

在TigerGraph中，因其高級查詢語句中支持累加器操作，所以我們針對測試場景定制了一個查詢函數(shù)，用于累計每個實體的一度關(guān)系，它將并行的將函數(shù)預先運行到每個實體中，安裝函數(shù)的步驟會花費幾秒鐘的時間，以后直接運行查詢就會很快，這有點類似AbutionGDB的預計算模型機制。JanusGraph因為不支持自定義id，查詢起來需要先匹配節(jié)點屬性做聚合，再做一度關(guān)系計算，每次計算量都會比AbutionGDB和TigerGraph大至少一倍，所以計算速度很慢。

而Neo4j與JanusGraph一樣，導入數(shù)據(jù)時都會自增生成一個ID來存儲節(jié)點，即使相同的事件數(shù)據(jù)也會重新得到一個新的存儲id，想要加速查詢只能對屬性添加索引支持，所以聚合類查詢都很慢，但因為是原生圖存儲，數(shù)據(jù)量少的情況下會比JanusGraph略快一些。所以從測試結(jié)果來看，AbutionGDB的查詢吞吐量遠高于JanusGraph和Neo4j。

綜上可以看到，AbutionGDB寫入性能具有良好的橫向擴展（scale-out）的能力，對于多節(jié)點構(gòu)成的集群也能提供優(yōu)秀的擴展支持，而讀取性能也具有千萬級/秒的速度，對于大規(guī)模的大多數(shù)數(shù)據(jù)統(tǒng)計查詢場景都能在1秒內(nèi)返回結(jié)果。

點「在看」的人都變好看了哦！

知識圖譜數(shù)據(jù)庫讀寫性能基準測試

測試用數(shù)據(jù)說明

統(tǒng)計結(jié)果說明

AbutionGDB與其他數(shù)據(jù)庫單節(jié)點對比測試

測試環(huán)境及步驟說明

寫入性能對比

AbutionGDB批量實時寫入結(jié)果

Neo4j批量實時寫入結(jié)果

TigerGraph批量實時寫入結(jié)果

讀取性能對比