摘要：大資料時代下，實時推薦引擎成為個性化廣告背後的助力，而資料庫更是提供了推薦依據。本文作者指出，在如今這
個資料增長速度十分迅猛的環境下，關系資料庫已經比不上圖資料庫的高效了。
鍊
接：https://memgraph.com/blog/faster-recommendations-with-graph-databases?continueFlag=7773e661db7a5655443a7c4ae921524d
聲明：本文為 CSDN 翻譯，未經允許禁止轉載。
作者 | Niko Krvavica
譯者 | 彎月 責編 | 鄭麗媛
出品 | CSDN（ID：CSDNnews）
推薦引擎中的資料增長速度十分快，而且會變得非常複雜。例如亞馬遜等網站每月的使用者通路量超過 1.97 億次，每隔幾分鐘就有 4000 件商品被購買。
對于關系資料庫來說，存儲這些資料并不成問題，但查詢有用的資訊并生成推薦可能成為一個緩慢而痛苦的 SQL 噩。
隻清楚某些使用者、評論和産品之間存在的聯系遠遠不夠。想擁有一個十分準确且适應性非常強的推薦引擎，我們就需要剖析這些關系，提取它們的重要性、影響力和權重。就算姑且不論分析，隻發現這些關系就需要大量（遞歸的）JOIN 操作，最終給關系資料庫帶來壓力——幸運的是，圖資料庫不需要識别連接配接，因為實體及其關系是圖資料庫的基本子產品。
無論何時，即便業務模型以某種沒有意料到的方式發生變化，圖資料庫也可以輕松處理，它具有非常靈活的資料模組化。
由于圖資料庫的重心是關系，是以與關系資料庫相比，查找圖資料庫并生成推薦資訊會更加容易，速度也更快。你無需考慮如何編寫 JOIN 語句，隻需要考慮客戶實際想要購買什麼。
資料模組化更容易
在關系資料庫中，資料是通過建立多個表來存儲的，其中每一列代表實體的一個屬性，包括唯一的鍵，每個表都可以使用 JOIN 與資料庫中的其他表連接配接。在白闆上繪制關系資料模型以及關聯的表非常有難度，但任何熟悉業務需求的人都可以使用圖資料模型，即使他們并不精通資料科學。
圖資料庫包含兩個主要實體：節點（頂點）和節點之間的關系（邊）。每個節點的資訊都作為屬性儲存起來。舉個例子，假設資料由産品、使用者和評論組成，這些都是具有不同标簽和屬性的節點，比如産品包含名稱、品牌、尺寸和價格等資訊。使用者檢視這些産品，并将它們放入購物車、購買、評價或退貨，這樣使用者和産品之間就會形成不同類型的關系。
如果想在零售領域實作一個推薦系統，關系型資料庫需要定義資料庫模式并建立各種表：使用者表、商品表、評分表等等。表中的每一行都有一個唯一的鍵，該鍵可作為屬性存儲在另一個表中，以表示兩個表之間的連接配接。這裡的資料模式繪制成圖形，大緻如下：
這個示例非常簡單，相較而言現實生活中系統包含的資料量和表遠不止這麼多，了解表之間連接配接的本質是一項非常艱巨的工作。如果模型發生任何變化，我們還需要重審模式以及内部的關系，然後更新所有表和流程。
在圖資料庫中，節點之間的互動模組化與資料的存儲和查詢方式一緻，可以為推薦引擎提供最佳結果。圖資料庫提供了一種比關系資料庫更好的方式來表達實體之間的聯系，是以有利于開發準确的業務模型。此外，它們還為系統提供了非常必要的靈活性。
在大多數圖資料庫中，資料庫模式不是必需的，是以導入資料和更新資料的難度更小。節點和關系是在資料存儲到資料庫時建立的。
使用者建立個人賬号時，系統會建立一個帶有标簽 USER 的節點以及定義特定使用者的屬性。使用者可以建立他們銷售的産品，圖模型會更新所有帶有 PRODUCT 标簽的節點。節點 USER 和 PRODUCT 之間通過關系連接配接：SELLING。使用者還可以購買産品，并對其進行評分。這時，節點 USER 和 PRODUCT 之間就形成了另外兩種關系，分别為 BOUGHT（購買）或 RATED（評分）。圖資料庫的模式如下所示：
如你所見，實體與它們之間的關系清晰了然。
與關系資料庫相比，通過圖資料庫檢查和深入了解資料的難度更低，速度更快，正是因為不同節點之間建立的這種關系網。
推薦産品：SQL 查詢與 Cypher 查詢
下面，我們根據上述資料模型建立一個查詢，向某個使用者推薦某個産品。我們的推薦基于以下資訊：使用者給予最高評分的産品，以及浏覽相同産品後同樣給出最高評分的其他使用者。這也是推薦引擎可以使用的最簡單查詢之一，因為這個查詢可以通過社群檢測、計算皮爾遜相關系數和機器學習進行更深入的挖掘。
這個 SQL 查詢需要使用複雜的 JOIN 操作連接配接表，如下所示：
select B.* from user User1 join rating Rating1 on User1.user_id = Rating1.id and Rating1.value = 5 join product A on A.id = Rating1.product_id join rating Rating2 on Rating2.product_id = A.id and Rating2.value = 5 join user User2 on User2.id = Rating2.user_id and User2.id <> User1.id join rating RatingB on RatingB.user_id = User2.id and RatingB.value =5 join product B on B.id = RatingB.product_id WHERE User1.id = 1; JOIN 操作很容易出錯，而且速度很慢，計算量大。每個 JOIN 操作的時間複雜度為 O(M * log(N))，其中 M 代表一個表中的記錄數，N 代表另一個表中的記錄數，這意味着我們需要掃描兩個表中的所有行，并嘗試通過唯一的鍵連接配接二者。随着推薦引擎中資料的增長，需要連接配接多個表的查詢和分析将越來越複雜，關系資料庫的速度也會越來越慢。
每個圖資料庫都使用自己的查詢語言，而在圖資料庫的世界中，最常用的語言是 Cypher。擷取相同結果的 Cypher 查詢如下所示：
MATCH (pA:PRODUCT)<-[r1:Rated {"rating":5}]-(n1:USER)-[r2:Rated {"rating":5}]->(pB:PRODUCT) MATCH (n2:USER {id:1})-[r3:Rated {"rating":5}]->(pb) WHERE n1.id != n2.id RETURN pB; 在圖中搜尋節點的過程稱為圖周遊，圖周遊的複雜度為 O(K)，其中 K 代表一個節點與其他節點的連接配接數。高度優化是無索引鄰接概念的結果，這是圖資料庫最重要的概念之一。在查找圖中的相鄰節點時，圖資料庫會執行指針跳躍，即直接周遊記憶體，這是最快的檢視關系的方式。為了直接周遊記憶體，關系會以實體 RAM 位址的形式存儲起來。最重要的是，關系是在建立資料時建立的，而不是查詢時。
圖資料庫不必使用任何其他資料結構或索引，即可從任意節點跳至相鄰節點。在設計推薦引擎時，使用者和他們購買的産品之間的連接配接會作為固定的實體 RAM 位址儲存起來。而将相關節點存儲在相鄰的記憶體位址内，可以進一步提升性能，進而最大限度地提高資料緩存到 CPU 的機率。
研究表明，使用圖資料庫向相距三個連接配接的使用者推薦産品的速度，比使用關系資料庫快 180 倍以上。
靈活性
關系資料庫依賴于之前所建立的預定模式，一旦出現意外或計劃外的狀況，關系資料庫的模式就無法靈活應對。但在推薦引擎起着關鍵作用的零售業務中，我們很難預測市場和平台的發展與變化。
舉個例子，假設有一家銷售船隻的公司，在現有資料之上建構了一個推薦引擎。有一天，你想擴大業務，開始銷售捕魚裝置。如果你使用的是關系資料庫，則需要重新考慮整個資料庫，因為你必須嚴格遵守已有的資料模式。否則，任何不比對模式的資料都無法存儲。是以，如果原有模式不具有釣魚線一個非常重要的屬性——粗細（不是船隻屬性），則需要重新設計模式。
為了降低工作量，你可以添加可應用到所有産品的所有屬性，但其中一些屬性将是 值，因為捕魚裝置沒有發動機功率或船型等屬性，而船隻通常沒有粗細等屬性。但這樣做的問題在于，首先會造成記憶體浪費，其次你還需要添加一個過濾器來過濾掉船隻，或者要通過額外的檢查來避免由 屬性引起的問題，這勢必會加劇代碼的複雜性。
如果你選擇忽略這些問題，直接顯示所有屬性，生成的推薦就會顯得很愚蠢且不專業。看看如下這個真實的例子，由于零售商的主要業務是銷售服裝，并沒有調整資料庫中的家居用品銷售，是以“性别”屬性為“男女皆宜”的架子就出現在了推薦清單中。
更好的解決方案是，更新資料模式，通過一個表來存儲船隻，另一個表來存儲捕魚裝置。但是，你還需要向 USER 表添加一個附加屬性，以存儲捕魚裝置的唯一鍵以及船隻的唯一鍵。如果沒有唯一鍵的資訊，你将無法連接配接兩個表。
随着業務進一步擴充，每次添加一種新型産品，你都将面臨同一個問題。也就是說，你需要建立一個表，并添加一個屬性列。當然，這隻是一個示例，你可以更好地改進資料庫模式。但是，正如你所見，使用關系資料庫時，我們需要解決很多技術細節和問題。
反之，如果使用圖資料庫，我們就可以将這些繁瑣的變更減到最小，并将由于未涵蓋某些場景而導緻系統突然崩潰可能性降到最低。
圖資料庫不需要預先定義模式，這意味着，你可以使用資料庫中不存在的标簽和屬性建立節點，還可以将它們連接配接到現有節點，而無需破壞現有節點或對現有資料進行任何更改。
使用圖資料庫，你可以随時輸入新的變更，而不會破壞現有的功能。
下面，我們試試看利用圖資料庫處理上述新的業務需求：銷售和推薦釣魚裝置。如果你的平台決定開始銷售釣魚裝置，那麼在建立新節點 PRODUCT 時，你需要添加另一個标簽：FISHING_EQUIPMENT 。
如此，使用者就可以開始購買釣魚裝置，推薦引擎也可以将這項新業務納入算法中。使用者在購買釣魚裝置時，就會建立一個二者之間的關系，而你無需對 CUSTOMER 節點或 FISHING_EQUPIMENT 節點進行任何修改。
總結
嘗試新技術絕非易事，但如果不緊跟前沿技術，就有可能被競争對手搶先。
推薦引擎使用的資料正在以秒為機關增長，市場需要真正有意義的推薦。為了提供高價值的推薦，引擎需要考慮到市場趨勢以及使用者在平台上執行的所有操作（浏覽、評論、添加到購物車或願望清單、删除、分享或購買）。
推薦引擎不僅需要與目标使用者的購物習慣保持一緻，而且還需要考慮到相似購物者的習慣。由于市場的變化，我們很難預測業務需求，進而導緻業務模型也會發生變化。圖資料庫可以輕松适應任何必要的變更。
最後，如果由于資料過多而導緻推薦引擎無法正常運轉，公司的業務發展也是以受到了阻礙，那麼從關系資料庫遷移到圖資料庫将是一個明智的選擇。