使用 Azure Cosmos DB for Apache Gremlin 進行圖形資料模型化
適用於：
Gremlin
本文提供使用圖形資料模型的建議。 在資料發展過程中，這些最佳做法是確保圖形資料庫系統的可擴縮性和效能的重要關鍵。 對大規模圖形而言，有效率的資料模型尤其重要。
需求
本指南中所述的程序是以下列假設為依據：
- 已識別問題空間中的實體。 這些實體是要讓每個要求以不可分割方式方式使用。 換句話說，也就是資料庫系統的設計目的，並不是為了使用多個問題要求來擷取單一實體的資料。
- 我們已經了解資料庫系統有讀取和寫入需求。 這些需求主導了圖形資料模型所需的最佳化作業。
- 我們已經充分瞭解 Apache Tinkerpop 屬性圖形標準 \(英文)\ 的原則。
需要圖形資料庫時機為何？
如果資料網域中的實體和關聯性具有以下任何特性，就非常適合使用圖形資料庫解決方案：
- 實體是透過敘述性的關聯性緊密連結的。 此案例的優點是關聯性會保存在儲存體中。
- 這具有循環關聯性或是自我參考的實體。 使用關聯式或文件資料庫時，此模式通常是一個挑戰。
- 實體之間具有動態發展的關聯性。 此模式特別適用於具有許多層級的階層式或樹狀結構資料。
- 實體之間有多對多關聯性。
- 其中有對實體與關聯性雙方的寫入和讀取需求。
如果符合上述準則，圖形資料庫方法可能就會提供查詢複雜度、資料模型可擴縮性，以及查詢效能等優點。
下一個步驟是決定圖形將要用於分析或交易用途。 如果該圖形要用於大量計算和資料處理工作負載，就值得探索 Cosmos DB Spark 連接器和 GraphX 程式庫。
如何使用圖形物件
Apache Tinkerpop 屬性圖形標準定義了兩種物件類型：[頂點] 和 [邊緣]。
以下是圖形物件中各屬性的最佳做法：
| Object | 屬性 | 類型 | 備註 |
|---|---|---|---|
| 端點 | 識別碼 | String | 每個分割區唯一強制執行。 如果插入時未提供值，就會儲存自動產生的 GUID。 |
| 端點 | 標籤 | String | 這個屬性是用來定義頂點所代表的實體類型。 如果未提供值，請使用預設值 [頂點]。 |
| 端點 | 屬性 | 字串、布林值、數值 | 個別屬性的清單會以索引鍵/值組的方式儲存在每個頂點中。 |
| 端點 | 分割區索引鍵 | 字串、布林值、數值 | 這個屬性定義了頂點和其傳出邊緣的儲存位置。 深入了解資料分割。 |
| Edge | 識別碼 | String | 每個分割區唯一強制執行。 預設會自動產生。 邊緣通常不需要透過 ID 進行唯一擷取。 |
| Edge | 標籤 | String | 這個屬性是用來定義兩個頂點之間的關聯性類型。 |
| Edge | 屬性 | 字串、布林值、數值 | 個別屬性的清單會以索引鍵/值組的方式儲存在每個邊緣中。 |
注意
邊緣不需要分割區索引鍵值，因為系統會根據其來源頂點自動指派該值。 若要深入了解，請參閱在 Azure Cosmos DB 中使用資料分割圖表。
實體和關聯性模型指導方針
以下指導方針可協助您對 Azure Cosmos DB for Apache Gremlin 圖形資料庫進行資料模型化。 這些指導方針會假設已有現有的資料網域定義和對資料庫的查詢。
注意
以下為建議步驟。 在考慮將最終模型投入生產前，您應該先評估並測試該模型。 此外，下列建議為 Azure Cosmos DB 的 Gremlin API 實作專屬。
建立頂點和屬性模型
圖形資料模型的第一個步驟是將每個已識別的實體對應至頂點物件。 所有實體到頂點的一對一對應應為初始步驟，因此很可能會有所變更。
一個常見的陷阱是將單一實體的多個屬性作為個別的頂點來對應。 請考量以下範例，範例中將同一個實體以兩種不同的方式表示：
以頂點為基礎的屬性：在這個方法中，實體使用了三個個別的頂點和兩個邊緣來描述其屬性。 雖然這種方法可能會減少冗餘，但會增加模型複雜度。 模型複雜度增加可能會導致增加延遲增加、提升查詢複雜度，以及增加計算成本。 此模型也代表在進行資料分割時將面臨挑戰。
屬性內嵌頂點：這個方法會利用索引鍵/值組清單來代表頂點內部實體的所有屬性。 這種方法降低了模型的複雜度，從而導致更簡單的查詢和更具經濟效益的遍訪。
注意
上圖顯示簡化的圖形模型，該模型僅比較分割實體屬性的兩種方式。
屬性內嵌頂點模式通常會提供效能更高且可調整的方法。 新圖形資料模型的預設方法應傾向採用此模式。
但在某些情況下，參考屬性可能會帶來優點。 例如，如果參考的屬性經常更新。 使用個別的頂點來代表不斷變更的屬性，將更新所需的寫入作業數量降到最低。
邊緣方向的關聯性模型
建立頂點的模型之後，可以新增邊緣來表示它們之間的關聯性。 需要評估的第一個層面是關聯性方向。
使用 out() 或 outE() 函式時，邊緣物件有後面接著周遊的預設方向。 使用這個原生方向可產生有效率的作業，因為所有頂點在儲存時都會包含它們的傳出邊緣。
但是，使用 in() 函式沿反方向周遊一律會導致跨分割區查詢。 深入了解圖表分割。 如果需要使用 in() 函式不斷地進行周遊，建議您新增兩個方向的邊緣。
您可以透過在 .addE() Gremlin 步驟中使用 .to() 或 .from() 述詞來判斷邊緣方向。 或使用適用於 Gremlin API 的大量執行程式文件庫。
注意
邊緣物件都有預設的方向。
關聯性標籤
使用描述性的關聯性標籤可以提升邊緣解析作業的效率。 您可以透過以下方式套用此模式：
- 使用非泛型詞彙來標記關聯性。
- 利用關聯性名稱建立來源頂點的標籤與目標頂點的標籤之間的關聯。
周遊程式用以篩選邊緣的標籤越具體越好。 此決策也會對查詢成本產生重大影響。 您隨時都可以使用 executionProfile 步驟來評估查詢成本。
下一步
- 請查看支援的 Gremlin 步驟清單。
- 深入了解圖形資料庫資料分割以處理大規模圖形。
- 使用執行設定檔步驟來評估您的 Gremlin 查詢。
- 協力廠商圖形設計資料模型。