大規模知識圖譜的存儲

來自專欄 知識圖譜實踐

（1）存儲系統架構

目前大規模的知識圖譜一般採用圖資料庫做為最基本的存儲引擎。圖資料庫的優點在於其天然的能表示知識圖譜結構，圖中的節點表示知識圖譜的對象，圖中的邊表示知識圖譜的對象關係；但是其缺點是圖資料庫的更新比較複雜，對於複雜查詢的支持不夠。所以我們使用以圖資料庫為主，結合其他系統的方式來存儲知識圖譜。

由於我們圖譜每天數據都會有變化，使用hadoop這種適合批量離線處理的系統做為離線更新系統，為了效率我們在hadoop上只計算增量變化；另外我們的圖譜支持用戶編輯，會將用戶的編輯操作記錄在mysql里，並且實時更新到圖資料庫里；圖資料庫做為存儲知識圖譜數據的系統，用的是自己公司自己的分散式圖資料庫，對於開源的話一般是用neo4j或者titan；為了支持模糊和分詞查詢，還將數據同步到了elastic search。

（2）圖資料庫存儲結構

在選擇圖資料庫做為存儲引擎之後，如何設計我們的存儲數據結構呢？

首先需要明確選用的圖資料庫是否支持schema free的。像我們的圖資料庫不是schema free的，每次節點增加屬性如果都需要清除數據重新導入，肯定是無法接受的。因此我們抽取了所有節點的公有屬性做為節點基本屬性，比如「節點id」，「節點名稱」，「創建時間」等，這樣的節點基本屬性一旦固定下來就需要不變化了。

其次對於節點的非基本屬性，我們全部做為圖中的邊來處理。比如音樂節點的「發行年份」屬性，我們鏈出一條邊指向String類型節點，邊上有邊名和邊屬性，邊名就是「發行年份」，邊屬性就是具體年份。但是後來我們發現會有海量節點都指向String，Double這種節點，造成查詢效率問題。為了解決這個問題，我們將所有這種類型的邊指向節點本身，這樣解決了海量節點問題。

最後是對於節點和節點之間的關係，使用邊來表示。比如姚明和葉莉之間有一條「丈夫」的邊，有一條「妻子」邊。另外我們的節點類型，也是用邊關係表示，例如姚明和籃球運動員之間，有一條「類型」的邊。

（3）總結

知識圖譜的存儲結構設計沒有統一的標準，我有看到對於數據量不是很大且結構固定的圖譜就是使用傳統資料庫+關係表來存儲的，也有按照學術定義的rdf存儲的。還是需要根據自己的應用場景，數據情況來具體設計，適合自己應用場景的才是最好的。