對實時推薦引擎來說,關係資料庫已過時,圖資料庫才是王道!

摘要:大資料時代下,實時推薦引擎成為個性化廣告背後的助力,而資料庫更是提供了推薦依據。本文作者指出,在如今這個資料增長速度十分迅猛的環境下,關係資料庫已經比不上圖資料庫的高效了。

連結:https://memgraph.com/blog/faster-recommendations-with-graph-databases?continueFlag=7773e661db7a5655443a7c4ae921524d

作者 | Niko Krvavica

譯者 | 彎月 責編 | 鄭麗媛

推薦引擎中的資料增長速度十分快,而且會變得非常複雜。例如亞馬遜等網站每月的使用者訪問量超過 1.97 億次,每隔幾分鐘就有 4000 件商品被購買。

對於關係資料庫來說,儲存這些資料並不成問題,但查詢有用的資訊並生成推薦可能成為一個緩慢而痛苦的 SQL 噩。

只清楚某些使用者、評論和產品之間存在的聯繫遠遠不夠。想擁有一個十分準確且適應性非常強的推薦引擎,我們就需要剖析這些關係,提取它們的重要性、影響力和權重。就算姑且不論分析,只發現這些關係就需要大量(遞迴的)JOIN 操作,最終給關係資料庫帶來壓力——幸運的是,圖資料庫不需要識別連接,因為實體及其關係是圖資料庫的基本模組。

無論何時,即便業務模型以某種沒有意料到的方式發生變化,圖資料庫也可以輕鬆處理,它具有非常靈活的資料建模。

由於圖資料庫的重心是關係,因此與關係資料庫相比,查找圖資料庫並生成推薦資訊會更加容易,速度也更快。你無需考慮如何編寫 JOIN 語句,只需要考慮客戶實際想要購買什麼。

資料建模更容易

資料建模更容易

在關係資料庫中,資料是通過創建多個表來儲存的,其中每一列代表實體的一個屬性,包括唯一的鍵,每個表都可以使用 JOIN 與資料庫中的其他表連接。在白板上繪製關係資料模型以及關聯的表非常有難度,但任何熟悉業務需求的人都可以使用圖資料模型,即使他們並不精通資料科學。

圖資料庫包含兩個主要實體:節點(頂點)和節點之間的關係(邊)。每個節點的資訊都作為屬性保存起來。舉個例子,假設資料由產品、使用者和評論組成,這些都是具有不同標籤和屬性的節點,比如產品包含名稱、品牌、尺寸和價格等資訊。使用者查看這些產品,並將它們放入購物車、購買、評價或退貨,這樣使用者和產品之間就會形成不同類型的關係。

如果想在零售領域實現一個推薦系統,關係型資料庫需要定義資料庫模式並創建各種表:使用者表、商品表、評分表等等。表中的每一行都有一個唯一的鍵,該鍵可作為屬性儲存在另一個表中,以表示兩個表之間的連接。這裡的資料模式繪製成圖形,大致如下:

這個示例非常簡單,相較而言現實生活中系統包含的資料量和表遠不止這麼多,理解表之間連接的本質是一項非常艱鉅的工作。如果模型發生任何變化,我們還需要重審模式以及內部的關係,然後更新所有表和流程。

在圖資料庫中,節點之間的互動建模與資料的儲存和查詢方式一致,可以為推薦引擎提供最佳結果。圖資料庫提供了一種比關係資料庫更好的方式來表達實體之間的聯繫,因此有利於開發準確的業務模型。此外,它們還為系統提供了非常必要的靈活性。

在大多數圖資料庫中,資料庫模式不是必需的,因此匯入資料和更新資料的難度更小。節點和關係是在資料儲存到資料庫時創建的。

使用者創建個人賬號時,系統會創建一個帶有標籤 USER 的節點以及定義特定使用者的屬性。使用者可以創建他們銷售的產品,圖模型會更新所有帶有 PRODUCT 標籤的節點。節點 USER 和 PRODUCT 之間通過關係連接:SELLING。使用者還可以購買產品,並對其進行評分。這時,節點 USER 和 PRODUCT 之間就形成了另外兩種關係,分別為 BOUGHT(購買)或 RATED(評分)。圖資料庫的模式如下所示:

如你所見,實體與它們之間的關係清晰瞭然。

與關係資料庫相比,通過圖資料庫檢查和深入了解資料的難度更低,速度更快,正是因為不同節點之間建立的這種關係網。

推薦產品:SQL 查詢與 Cypher 查詢

下面,我們根據上述資料模型創建一個查詢,向某個使用者推薦某個產品。我們的推薦基於以下資訊:使用者給予最高評分的產品,以及瀏覽相同產品後同樣給出最高評分的其他使用者。這也是推薦引擎可以使用的最簡單查詢之一,因為這個查詢可以通過社區檢測、計算皮爾遜相關係數和機器學習進行更深入的挖掘。

這個 SQL 查詢需要使用複雜的 JOIN 操作連接表,如下所示:

select B.* from user User1join rating Rating1 on User1.user_id = Rating1.id and Rating1.value = 5join product A on A.id = Rating1.product_idjoin rating Rating2 on Rating2.product_id = A.id and Rating2.value = 5join user User2 on User2.id = Rating2.user_id and User2.id  User1.idjoin rating RatingB on RatingB.user_id = User2.id and RatingB.value =5join product B on B.id = RatingB.product_idWHERE User1.id = 1;

JOIN 操作很容易出錯,而且速度很慢,計算量大。每個 JOIN 操作的時間複雜度為 O(M * log(N)),其中 M 代表一個表中的記錄數,N 代表另一個表中的記錄數,這意味著我們需要掃描兩個表中的所有行,並嘗試通過唯一的鍵連接二者。隨著推薦引擎中資料的增長,需要連接多個表的查詢和分析將越來越複雜,關係資料庫的速度也會越來越慢。

每個圖資料庫都使用自己的查詢語言,而在圖資料庫的世界中,最常用的語言是 Cypher。獲取相同結果的 Cypher 查詢如下所示:

MATCH (pA:PRODUCT)(pB:PRODUCT)MATCH (n2:USER {id:1})-[r3:Rated {"rating":5}]->(pb)WHERE n1.id != n2.idRETURN pB;

在圖中搜尋節點的過程稱為圖遍歷,圖遍歷的複雜度為 O(K),其中 K 代表一個節點與其他節點的連接數。高度最佳化是無索引鄰接概念的結果,這是圖資料庫最重要的概念之一。在查找圖中的相鄰節點時,圖資料庫會執行指針跳躍,即直接遍歷記憶體,這是最快的查看關係的方式。為了直接遍歷記憶體,關係會以物理 RAM 地址的形式儲存起來。最重要的是,關係是在創建資料時創建的,而不是查詢時。

圖資料庫不必使用任何其他資料結構或索引,即可從任意節點跳至相鄰節點。在設計推薦引擎時,使用者和他們購買的產品之間的連接會作為固定的物理 RAM 地址保存起來。而將相關節點儲存在相鄰的記憶體地址內,可以進一步提升性能,從而最大限度地提高資料快取到 CPU 的概率。

研究表明,使用圖資料庫向相距三個連接的使用者推薦產品的速度,比使用關係資料庫快 180 倍以上。

靈活性

靈活性

關係資料庫依賴於之前所創建的預定模式,一旦出現意外或計劃外的狀況,關係資料庫的模式就無法靈活應對。但在推薦引擎起著關鍵作用的零售業務中,我們很難預測市場和平臺的發展與變化。

舉個例子,假設有一家銷售船隻的公司,在現有資料之上構建了一個推薦引擎。有一天,你想擴大業務,開始銷售捕魚設備。如果你使用的是關係資料庫,則需要重新考慮整個資料庫,因為你必須嚴格遵守已有的資料模式。否則,任何不匹配模式的資料都無法儲存。因此,如果原有模式不具有釣魚線一個非常重要的屬性——粗細(不是船隻屬性),則需要重新設計模式。

為了降低工作量,你可以添加可應用到所有產品的所有屬性,但其中一些屬性將是 NULL 值,因為捕魚設備沒有發動機功率或船型等屬性,而船隻通常沒有粗細等屬性。但這樣做的問題在於,首先會造成記憶體浪費,其次你還需要添加一個過濾器來過濾掉船隻,或者要通過額外的檢查來避免由 NULL 屬性引起的問題,這勢必會加劇程式碼的複雜性。

如果你選擇忽略這些問題,直接顯示所有屬性,生成的推薦就會顯得很愚蠢且不專業。看看如下這個真實的例子,由於零售商的主要業務是銷售服裝,並沒有調整資料庫中的家居用品銷售,因此「性別」屬性為「男女皆宜」的架子就出現在了推薦列表中。

更好的解決方案是,更新資料模式,通過一個表來儲存船隻,另一個表來儲存捕魚設備。但是,你還需要向 USER 表添加一個附加屬性,以儲存捕魚設備的唯一鍵以及船隻的唯一鍵。如果沒有唯一鍵的資訊,你將無法連接兩個表。

隨著業務進一步擴展,每次添加一種新型產品,你都將面臨同一個問題。也就是說,你需要新建一個表,並添加一個屬性列。當然,這只是一個示例,你可以更好地改進資料庫模式。但是,正如你所見,使用關係資料庫時,我們需要解決很多技術細節和問題。

反之,如果使用圖資料庫,我們就可以將這些繁瑣的變更減到最小,並將由於未涵蓋某些場景而導致系統突然崩潰可能性降到最低。

圖資料庫不需要預先定義模式,這意味著,你可以使用資料庫中不存在的標籤和屬性創建節點,還可以將它們連接到現有節點,而無需破壞現有節點或對現有資料進行任何更改。

使用圖資料庫,你可以隨時輸入新的變更,而不會破壞現有的功能。

下面,我們試試看利用圖資料庫處理上述新的業務需求:銷售和推薦釣魚設備。如果你的平臺決定開始銷售釣魚設備,那麼在創建新節點 PRODUCT 時,你需要添加另一個標籤:FISHING_EQUIPMENT 。

如此,使用者就可以開始購買釣魚設備,推薦引擎也可以將這項新業務納入演算法中。使用者在購買釣魚設備時,就會創建一個二者之間的關係,而你無需對 CUSTOMER 節點或 FISHING_EQUPIMENT 節點進行任何修改。

總結

總結

嘗試新技術絕非易事,但如果不緊跟前沿技術,就有可能被競爭對手搶先。

推薦引擎使用的資料正在以秒為單位增長,市場需要真正有意義的推薦。為了提供高價值的推薦,引擎需要考慮到市場趨勢以及使用者在平臺上執行的所有操作(瀏覽、評論、添加到購物車或願望清單、刪除、分享或購買)。

推薦引擎不僅需要與目標使用者的購物習慣保持一致,而且還需要考慮到相似購物者的習慣。由於市場的變化,我們很難預測業務需求,從而導致業務模型也會發生變化。圖資料庫可以輕鬆適應任何必要的變更。

最後,如果由於資料過多而導致推薦引擎無法正常運轉,公司的業務發展也因此受到了阻礙,那麼從關係資料庫遷移到圖資料庫將是一個明智的選擇。

相關文章

HavanaCrypt冒充 Google 更新程序

HavanaCrypt冒充 Google 更新程序

勒索軟體仍然是當今世界上最大的網路威脅之一。根據 Trend Micro的資料, 2022年第一季度通過電子郵件、URL和檔案層檢測並阻止了...

Docker 如何安全地進入到容器內部

Docker 如何安全地進入到容器內部

作者 | 飛向星的客機 來源 | CSDN部落格 🌟 前言 映象是構建容器的藍圖,Docker 以映象為模板,構建出容器。 容器在映象的基礎...

40 張圖 詳解 Docker 容器監控

40 張圖 詳解 Docker 容器監控

作者 | 飛向星的客機 來源 | CSDN部落格 前言 在企業中,通常業務是不允許隨意停止的,否則將給企業帶來巨大的經濟損失。 運維工程師要...

基於Jmeter的百萬級tps性能測試實踐

基於Jmeter的百萬級tps性能測試實踐

【CSDN 編者按】如何對系統的承載能力和響應時間做出準確的評估,為資源的合理配置及最佳化提供依據,性能測試就成了必不可少的測試手段,本文會...

宮敏把自由軟體和 Linux 帶回中國

宮敏把自由軟體和 Linux 帶回中國

對於宮敏,在中國的開源界以及技術圈內,大家所熟知的是「中國 Linux 第一人」的稱呼,因為他用手提肩背的方式將 Linux 帶回了中國,組...

Linux管道到底能有多快?

Linux管道到底能有多快?

【CSDN 編者按】本文作者通過一個示例程序,演示了通過Linux管道讀寫資料的性能最佳化過程,使吞吐量從最初的 3.5GiB/s,提高到最...

字節跳動埋點資料流建設與治理實踐

字節跳動埋點資料流建設與治理實踐

本文將介紹字節跳動在埋點資料流業務場景遇到的需求和挑戰以及具體實踐。 文 | 石偉 來自字節跳動資料平臺開發套件團隊 出品 | 字節跳動資料...

物件導向分析與設計的底層邏輯

物件導向分析與設計的底層邏輯

作者 | 不拔 來源 | 阿里巴巴中介軟體 物件導向是符合人認識事物的基本方法 01 人是怎麼認識事物的 在物件導向出現之前,已有程序導向的...