摘要：大數據時代下，實時推薦引擎成為個性化廣告背後的助力，而資料庫更是提供了推薦依據。本文作者指出，在如今這
個數據增長速度十分迅猛的環境下，關係資料庫已經比不上圖資料庫的高效了。
鏈
接：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 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)<-[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.idRETURN pB;
在圖中搜索節點的過程稱為圖遍歷，圖遍歷的複雜度為 O(K)，其中 K 代表一個節點與其他節點的連接數。高度優化是無索引鄰接概念的結果，這是圖資料庫最重要的概念之一。在查找圖中的相鄰節點時，圖資料庫會執行指針跳躍，即直接遍歷內存，這是最快的查看關係的方式。為了直接遍歷內存，關係會以物理 RAM 地址的形式存儲起來。最重要的是，關係是在創建數據時創建的，而不是查詢時。
圖資料庫不必使用任何其他數據結構或索引，即可從任意節點跳至相鄰節點。在設計推薦引擎時，用戶和他們購買的產品之間的連接會作為固定的物理 RAM 地址保存起來。而將相關節點存儲在相鄰的內存地址內，可以進一步提升性能，從而最大限度地提高數據緩存到 CPU 的概率。
研究表明，使用圖資料庫向相距三個連接的用戶推薦產品的速度，比使用關係資料庫快 180 倍以上。
靈活性
關係資料庫依賴於之前所創建的預定模式，一旦出現意外或計劃外的狀況，關係資料庫的模式就無法靈活應對。但在推薦引擎起著關鍵作用的零售業務中，我們很難預測市場和平台的發展與變化。
舉個例子，假設有一家銷售船隻的公司，在現有數據之上構建了一個推薦引擎。有一天，你想擴大業務，開始銷售捕魚設備。如果你使用的是關係資料庫，則需要重新考慮整個資料庫，因為你必須嚴格遵守已有的數據模式。否則，任何不匹配模式的數據都無法存儲。因此，如果原有模式不具有釣魚線一個非常重要的屬性——粗細（不是船隻屬性），則需要重新設計模式。
為了降低工作量，你可以添加可應用到所有產品的所有屬性，但其中一些屬性將是 值，因為捕魚設備沒有發動機功率或船型等屬性，而船隻通常沒有粗細等屬性。但這樣做的問題在於，首先會造成內存浪費，其次你還需要添加一個過濾器來過濾掉船隻，或者要通過額外的檢查來避免由 屬性引起的問題，這勢必會加劇代碼的複雜性。
如果你選擇忽略這些問題，直接顯示所有屬性，生成的推薦就會顯得很愚蠢且不專業。看看如下這個真實的例子，由於零售商的主要業務是銷售服裝，並沒有調整資料庫中的家居用品銷售，因此「性別」屬性為「男女皆宜」的架子就出現在了推薦列表中。
更好的解決方案是，更新數據模式，通過一個表來存儲船隻，另一個表來存儲捕魚設備。但是，你還需要向 USER 表添加一個附加屬性，以存儲捕魚設備的唯一鍵以及船隻的唯一鍵。如果沒有唯一鍵的信息，你將無法連接兩個表。
隨著業務進一步擴展，每次添加一種新型產品，你都將面臨同一個問題。也就是說，你需要新建一個表，並添加一個屬性列。當然，這只是一個示例，你可以更好地改進資料庫模式。但是，正如你所見，使用關係資料庫時，我們需要解決很多技術細節和問題。
反之，如果使用圖資料庫，我們就可以將這些繁瑣的變更減到最小，並將由於未涵蓋某些場景而導致系統突然崩潰可能性降到最低。
圖資料庫不需要預先定義模式，這意味著，你可以使用資料庫中不存在的標籤和屬性創建節點，還可以將它們連接到現有節點，而無需破壞現有節點或對現有數據進行任何更改。
使用圖資料庫，你可以隨時輸入新的變更，而不會破壞現有的功能。
下面，我們試試看利用圖資料庫處理上述新的業務需求：銷售和推薦釣魚設備。如果你的平台決定開始銷售釣魚設備，那麼在創建新節點 PRODUCT 時，你需要添加另一個標籤：FISHING_EQUIPMENT 。
如此，用戶就可以開始購買釣魚設備，推薦引擎也可以將這項新業務納入算法中。用戶在購買釣魚設備時，就會創建一個二者之間的關係，而你無需對 CUSTOMER 節點或 FISHING_EQUPIMENT 節點進行任何修改。
總結
嘗試新技術絕非易事，但如果不緊跟前沿技術，就有可能被競爭對手搶先。
推薦引擎使用的數據正在以秒為單位增長，市場需要真正有意義的推薦。為了提供高價值的推薦，引擎需要考慮到市場趨勢以及用戶在平台上執行的所有操作（瀏覽、評論、添加到購物車或願望清單、刪除、分享或購買）。
推薦引擎不僅需要與目標用戶的購物習慣保持一致，而且還需要考慮到相似購物者的習慣。由於市場的變化，我們很難預測業務需求，從而導致業務模型也會發生變化。圖資料庫可以輕鬆適應任何必要的變更。
最後，如果由於數據過多而導致推薦引擎無法正常運轉，公司的業務發展也因此受到了阻礙，那麼從關係資料庫遷移到圖資料庫將是一個明智的選擇。