NEO4J 圖數據庫怎樣解決STEP BY STEP

NEO4J 圖數據庫怎樣解決STEP BY STEP，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

本來想收筆，開過社交網絡在風控中的應用的會后，提到了NEO4J 在更新數據庫的時候，會比較慢，當然一般的操作流程是，通過傳統(tǒng)數據庫查找相關信息后，在根據主鍵查找NEO4J 的數據，保證查詢的速度。隱約記得 NOE4J 是支持索引的，但由于NEO4J 和傳統(tǒng)數據庫是非常不一致的，所以對索引能否提高查詢和更新的速度這方面是需要驗證。

本著這個想法，開始做這方面的研究，NEO4J 官方是非常肯定，INDEXES 在一個節(jié)點中，是可以加速相關和改善性能的。通過INDEX 在 MATCH WHERE  IN 這三種COLUMNS中的應用來提高 NEO4J 的相關方面的速度。

但NEO4J 明顯和傳統(tǒng)數據庫在結構設計上的不同，在創(chuàng)建索引的時候也有所體現.

在圖數據庫中需要理解三個模塊， 節(jié)點，關系，標簽。

什么是標簽，在NEO4J 中 標簽可以理解為表，但也不一樣，暫時這樣理解，因為標簽內的節(jié)點可以看做一個組

什么是節(jié)點： 節(jié)點記錄著屬性，一個節(jié)點可以記錄多個屬性，所以我們理解節(jié)點，是行的概念

屬性名： 列（不解釋了）

這里混亂的就是，表，的概念，按理說一個表有行，而這行信息必然屬于這個表，但是在NEO4J 中 節(jié)點（行），可以擁有多個標簽，也就是這一行可能屬于多個表（暫時這樣理解，有好的理解方式在改正）。所以就牽扯出關系。

關系就可以理解為傳統(tǒng)的主外鍵之間的聯系，但不完全，這里僅僅有關系，沒有誰要服從誰的概念。

好吧我知道，說到這里，基本上腦子已經是亂亂的。

下面是一個不和任何傳統(tǒng)數據庫之間有聯想的方式對NEO4J 數據庫中的東西進行的總結。

• 節(jié)點，關系和屬性是圖數據庫重要組成部分

• 節(jié)點和關系都包含屬性

• 關系連接節(jié)點

• 屬性是鍵值對

• 節(jié)點用圓圈表示，關系用方向鍵表示。

• 關系具有方向：單向和雙向。

• 每個關系包含“開始節(jié)點”或“從節(jié)點”和“到節(jié)點”或“結束節(jié)點”

回到具體的工作，下面是一條語句，需要我們

MATCH (e1:Borrower{ApplicationNO_ID:"rt-996899991"}),(e2:borrower) where e1<>e2 and e1.Phone =e2.Phone Merge (e1)-[:`電話=`{Role:'9999999999'}]->(e2)

(數據已經脫敏，都不是真實數據)

大致意思是 E1節(jié)點的數據 和 E2 節(jié)點的數據去重，然后發(fā)現電話相同的情況下，建立一個E1到E2節(jié)點的關系，而我們都知道，E1 不等于E2的數據，是要進行 NESTLOOP的操作，必定快不了，而每次更新數據，這么來，必然很慢，實測數據（數據量較少） 在 700-900MS 左右。

NEO4J ，在數據類（表設計）和 查詢關系的建立比傳統(tǒng)數據庫要更燒腦，所以不良好的設計，也會造成問題。

以上已經添加索引了,在 E1 E2 節(jié)點中的 PHONE 屬性。 但實際上沒有幫助，問題在于數據的搜索是節(jié)點是所有的屬性進行比對，E1 和 E2 中只要有一個屬性不同就被挑選出來（這有點類似全行全表掃描），然后還要挑揀出數據中 電話號碼相同的情況。然后CREATE 一個關系。

以上這樣的邏輯，基本上在大部分數據庫中的邏輯查詢都是很難搞的。必然牽扯全表掃描。

所以目前兩種方法可行，  1  在傳統(tǒng)數據庫中進行數據的過濾，直接將這樣的數據過濾出來，直接插入到 NEO4J中。

2  可以嘗試REDIS 將兩個節(jié)點的數據上傳，進行REDIS 之間的KEY VALUE的比對，終究內存數據庫比所有數據庫的速度都快。

關于NEO4J 圖數據庫怎樣解決STEP BY STEP問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業(yè)資訊頻道了解更多相關知識。