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社群版來如魚得水。
來自 “ 廠商動態 ”, 原文作者:廠商動態;原文連結:廠商動態,如有侵權,請聯絡管理員刪除。
相關文章
- KGB知識圖譜技術能夠解決哪些行業痛點?行業
- 知識圖譜01:知識圖譜的定義
- 知識圖譜|知識圖譜的典型應用
- KGB知識圖譜,利用科技解決傳統知識圖譜問題
- 企業級知識圖譜的案例分享
- 【知識圖譜】知識圖譜資料構建的“硬骨頭”,阿里工程師如何拿下?深度學習在知識圖譜構建中的應用。阿里工程師深度學習
- 知識圖譜的器與用(一):百萬級知識圖譜實時視覺化引擎視覺化
- 大資料架構師知識圖譜大資料架構
- 知識圖譜學習記錄--知識圖譜概述
- 知識圖譜技術的新成果—KGB知識圖譜介紹
- 【知識圖譜】 一個有效的知識圖譜是如何構建的?
- 一文打盡知識圖譜(超級乾貨,建議收藏!)
- 知識圖譜之知識表示
- 知識圖譜資料開發是做什麼的
- 知識圖譜中的資料服務是什麼?
- go 知識圖譜Go
- OI知識圖譜
- CRM系統的痛點,如何解決?
- 為知識的海洋繪製地圖 —— 利用CirroData-Graph圖資料庫構建知識圖譜地圖資料庫
- 圖資料和知識圖譜,數字化轉型的新引擎
- 知識圖譜與知識發現領域的頂級期刊與會議
- 知識點,如何應用“安全知識圖譜”識別內部威脅?
- 百分點科技:《資料科學技術: 文字分析和知識圖譜》資料科學
- 知識圖譜學習
- Http/2知識圖譜HTTP
- 知識圖譜入門——知識表示與知識建模
- 更強的RAG:向量資料庫和知識圖譜的結合資料庫
- 使用圖資料庫 Nebula Graph 資料匯入快速體驗知識圖譜 OwnThink資料庫
- 【科普】知識圖譜 Neoj4圖形資料庫 Cypher語言資料庫R語言
- 【知識圖譜】知識圖譜實體連結無監督學習框架框架
- 知識圖譜丨知識圖譜賦能企業數字化轉型
- 高階NumPy知識圖譜-《利用Python進行資料分析》Python
- 時間序列知識圖譜-《利用Python進行資料分析》Python
- KGB知識圖譜的應用之路-增強大資料分析能力大資料
- 知識圖譜和行業領域的結合產物-KGB知識圖譜介紹行業
- 事理圖譜,下一代知識圖譜
- 知識圖譜入門2
- NumPy基礎知識圖譜