30億資料的知識圖譜如何解決“超級痛點”

微瀾作為一款用於查詢技術、行業、企業、科研機構、學科及其關係的知識圖譜應用，具有十億級實體以及百億級關係。

而知識圖譜作為一項系統性工程，很多場景需要向使用者展示經過分頁的一度關係，同時我們的資料中存在一些超級節點，但根據我們的業務場景，超級節點一定會是使用者訪問可能性最高的節點，所以這不能被簡單歸類到長尾問題上;又因為我們的使用者量並不大，所以快取必然不會經常被撞到， 我們需要一套解決方案來使使用者的查詢延遲更小。

為了解決上述的業務痛點，微瀾透過在知識圖譜中引入 OceanBase社群版，突破了技術挑戰，完美地在新聞資訊體系中搭建起了自己獨有的體系優勢，有效保證了資訊的速度以及資訊的可溯源與真實可靠。

超級節點引發的"超級痛點"

在微瀾的知識圖譜業務中，很多場景需要展示覆雜的關係。

比如，某個機構在某領域的排名特別高，但在全域性或者其他領域一般。在這種場景下，微瀾必須顯示排序屬性，並且對於全域性排序項，進行擬合標準化，使每個維度的資料方差都為1，均值都為0，以便使用者進行區域性排序，方便使用者查詢。

在技術上我們遇到了一個很嚴重的問題，我們選擇圖資料庫作為知識圖譜的資料載體，同時我們希望透過排序的方式展示使用者查詢到的前一千條結果，但是由於我們的知識圖譜業務涉及到的資料極為龐雜，所以會出現很多鄰接邊超過十萬的超級節點。

在知識圖譜領域中，鄰接邊越多基本上就等同於此實體有越大的機率被搜尋，當搜尋此超級節點實體時，若需要展示排序後的結果，圖資料庫目前是不能勝任的(除非此圖資料庫已經全面做到了資料端的排序下推)。

一個十萬鄰接邊的節點以 path 的方式進行一度查詢需要近4秒，無法滿足我們的業務需求。

空間換時間，知識圖譜擁抱NewSQL

為了解決此問題，我們考慮加入其他資料庫到我們的業務中，以空間換時間，透過資料冗餘儲存來實現業務延遲的降低。

微瀾在知識圖譜中加入 NewSQL ，把一度關係問題轉化為傳統 RDBMS 中的聯合主鍵即可解決圖資料庫中海量資料排序下推的問題。

為什麼是 NewSQL?

對於初創企業而言，在資料量極大但是併發量不大的情況下，NewSQL 不論是運維成本還是硬體成本都很低，我們的叢集規模只有3臺，但是總資料量卻接近百億，而且單表資料量極大，最大的一張表超過八億資料，MySQL 之類的傳統 rdbms 的分庫分表方案對於我們運維人員很少的公司而言不友好。

傳統的 DBMS 容錯方案的重點是保障資料的更新不會丟失，而 NewSQL DBMS 除了這點以外，還能最小化停機時間，使其一直保持應用線上。這對於我們而言很重要，因為我們做的是商業場景，而且叢集數量小，最小化停機時間對於我們來說非常重要。

效能PK，“30億records”的選型之路

微瀾有30億的 records 資料，但沒有複雜分庫分表的運維能力。而 ScyllaDB 無法適應新業務的查詢要求，所以微瀾需要一個能實現傳統 RDBMS 的 query 功能的資料庫。

由於我們需要採用冗餘儲存的方式去以空間換時間，所以索引效能與索引形態是我們考慮的最關鍵的一點。

01索引效能對比

目前市面上的分散式資料庫中，從使用體驗的角度看主流有兩種形態：

以 TiDB、CockroachDB 等為代表的純透明的用法

從表現上來看，該種型別的資料庫所有表都是分散式表，並且不需要指定分割槽鍵，其核心邏輯是使用分散式事務來維護全域性索引，並使用全域性索引完全替代單機資料庫中的二級索引。優點是其易用性決定了分散式資料庫的使用下限，但效能上是有更高的成本代價。

以 OceanBase 等為代表的純手動的用法

從表現上看，資料庫在不指定分割槽鍵的情況下，是以單表的形式存在的，不具備擴充套件性;建立分散式表需要使用分割槽表語法。此型別的資料庫也提供全域性索引的能力。但與第一類不同，它們一般會將全域性索引作為一個可選項，由使用者手動指定與建立。此外，還會提供基於單機事務實現的本地索引。優點是手動建立能夠提供最優的效能，但同時使用門檻會有所增加。

對於追求效能的業務來講，第二種索引顯然更適合我們。

除此之外，微瀾需要進行週期性的大量寫入，每兩週就要淘汰掉30億資料並且重寫入等量資料，在這種情況下需要評估帶索引的資料寫入速度。

02資料寫入速度對比

CockroachDB 是 PG 型資料庫，團隊之前接觸的比較少，對於單表的資料量支援一般，不符合業務需求。

TiKV 採用 Range 的方式分割槽，但微瀾更需要 hash 的分割槽方式，因為微瀾的業務更偏向於單點查詢而非範圍查詢，寫入速度比較慢，無法適應微瀾週期性的大量寫入的業務場景。

OceanBase 有優秀的寫入能力，支援 hash 分割槽策略。對於單表大資料量的支撐強而有力，有良好的社群支援，支援 B tree 索引策略複合業務。對於 Paxos 的極致應用使得任務的並行粒度很細，可以把效能儘可能發揮出來。

經過測試，在有一個索引，資料量1億左右的本地表中，OceanBase的寫入速度整體比TiDB要好，而且TiDB在有索引的寫入中比較容易造成oom，無法適應微瀾週期性的大量寫入的業務場景。

經過綜合考慮，微瀾最終選擇使用 OceanBase社群版 。

全新CP，OceanBase 助力微瀾突破技術挑戰

在微瀾的所有業務中，微瀾選擇使用 OceanBase 來儲存圖譜中所有的一度關係。查詢效能相比之前的接近4秒，已經提升到100ms的水平，圖資料庫無法覆蓋的海量關係查詢排序已經被完美解決。

對比之前使用的 ScyllaDB ，作為 NewSQL 的 OceanBase ，自然比 NoSQL 資料庫能實現很多擴充套件，覆蓋更多的業務場景，比如多個條件的篩選並排序。現在微瀾兩週一次30億 records 的資料更新已經在 OceanBase 上被驗證了很多次，可以適配微瀾的業務需求。

令人倍感驚喜的是，除了開發起來難度大大下降，和 MySQL Client 的相容還有與MySQL 一致的 sql 語法，也讓我們使用起 OceanBase社群版來如魚得水。