<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

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

          共 9761字,需瀏覽 20分鐘

           ·

          2020-12-11 05:44

          大數(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é)果。


          點「在看」的人都變好看了哦!
          瀏覽 66
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  欧美九九九九 | 在线午夜黄色电影 | 无套暴操| 国产成人99精品免费视频明星 | 伊人天天色狠狠 |