Modelování dat grafů s využitím služby Azure Cosmos DB pro Apache Gremlin

  • Článek

PLATÍ PRO: Gremlin

Tento článek obsahuje doporučení pro použití grafových datových modelů. Tyto osvědčené postupy jsou nezbytné pro zajištění škálovatelnosti a výkonu systému grafových databází při vývoji dat. Efektivní datový model je zvlášť důležitý pro rozsáhlé grafy.

Požadavky

Proces popsaný v této příručce vychází z následujících předpokladů:

  • Entity v problémovém prostoru jsou identifikovány. Tyto entity jsou určené k atomovému využití pro každý požadavek. Jinými slovy, databázový systém není navržený tak, aby načítal data jedné entity ve více dotazech.
  • Existuje znalost požadavků na čtení a zápis pro databázový systém. Tyto požadavky jsou vodítkem pro optimalizace potřebné pro datový model grafu.
  • Principy standardu grafu vlastností Apache Tinkerpop jsou dobře pochopitelné.

Kdy potřebuji grafovou databázi?

Řešení grafové databáze je možné optimálně použít, pokud entity a relace v datové doméně mají některou z následujících charakteristik:

  • Entity jsou vysoce propojené prostřednictvím popisných vztahů. Výhodou v tomto scénáři je, že vztahy zůstávají v úložišti.
  • Existují cyklické vztahy nebo entity odkazované na sebe. Tento model je často výzvou při použití relačních databází nebo databází dokumentů.
  • Mezi entitami se dynamicky vyvíjejí vztahy . Tento model se vztahuje zejména na hierarchická data nebo data strukturovaná ve stromové struktuře s mnoha úrovněmi.
  • Mezi entitami existují relace M:N .
  • Pro entity i relace platí požadavky na zápis a čtení.

Pokud jsou výše uvedená kritéria splněna, bude mít přístup k grafové databázi pravděpodobně výhody z hlediska složitosti dotazů, škálovatelnosti datového modelu a výkonu dotazů.

Dalším krokem je určení, jestli se graf použije k analytickým nebo transakčním účelům. Pokud je graf určený k použití pro úlohy náročných na výpočty a zpracování dat, stojí za to prozkoumat konektor Spark služby Cosmos DB a knihovnu GraphX.

Jak používat objekty grafu

Standard grafu vlastností Apache Tinkerpop definuje dva typy objektů: vrcholy a hrany.

Níže jsou uvedené osvědčené postupy pro vlastnosti v objektech grafu:

Objekt Vlastnost Typ Poznámky
Vrchol ID Řetězec Jedinečně vynucené na oddíl. Pokud se hodnota při vložení nezadá, uloží se automaticky vygenerovaný identifikátor GUID.
Vrchol Popisek Řetězec Tato vlastnost se používá k definování typu entity, kterou vrchol představuje. Pokud se nezadá hodnota, použije se výchozí vrchol hodnoty.
Vrchol Vlastnosti Řetězec, logická hodnota, číselná hodnota Seznam samostatných vlastností uložených jako páry klíč-hodnota v každém vrcholu.
Vrchol Klíč oddílu Řetězec, logická hodnota, číselná hodnota Tato vlastnost definuje, kde je uložen vrchol a jeho odchozí hrany. Přečtěte si další informace o dělení grafů.
Edge ID Řetězec Jedinečně vynucené na oddíl. Automaticky se generuje ve výchozím nastavení. Hrany obvykle nemusí být jedinečným způsobem načítány pomocí ID.
Edge Popisek Řetězec Tato vlastnost se používá k definování typu relace, kterou mají dva vrcholy.
Edge Vlastnosti Řetězec, logická hodnota, číselná hodnota Seznam samostatných vlastností uložených jako páry klíč-hodnota v jednotlivých hranách.

Poznámka

Hrany nevyžadují hodnotu klíče oddílu, protože hodnota se automaticky přiřadí na základě jejich zdrojového vrcholu. Další informace najdete v tématu Použití děleného grafu ve službě Azure Cosmos DB.

Pokyny k modelování entit a relací

Následující pokyny vám pomůžou při modelování dat pro grafovou databázi Azure Cosmos DB for Apache Gremlin . Tyto pokyny předpokládají, že existuje definice datové domény a dotazuje se na ni.

Poznámka

Následující kroky jsou prezentovány jako doporučení. Než ho budete považovat za připravený pro produkční prostředí, měli byste konečný model vyhodnotit a otestovat. Doporučení jsou navíc specifická pro implementaci rozhraní Gremlin API služby Azure Cosmos DB.

Modelování vrcholů a vlastností

Prvním krokem datového modelu grafu je namapování každé identifikované entity na objekt vrcholu. Mapování všech entit na vrcholy 1:1 by mělo být počátečním krokem a mělo by se měnit.

Jedním z běžných úskalí je mapování vlastností jedné entity jako samostatných vrcholů. Představte si následující příklad, kde je stejná entita reprezentovaná dvěma různými způsoby:

  • Vlastnosti založené na vrcholech: V tomto přístupu používá entita k popisu svých vlastností tři samostatné vrcholy a dvě hrany. I když tento přístup může snížit redundanci, zvyšuje složitost modelu. Zvýšení složitosti modelu může mít za následek zvýšení latence, složitosti dotazů a nákladů na výpočet. Tento model může také představovat problémy při dělení.

    Diagram modelu entit s vrcholy pro vlastnosti

  • Vrcholy vložené do vlastností: Tento přístup využívá seznam párů klíč-hodnota k reprezentaci všech vlastností entity uvnitř vrcholu. Tento přístup snižuje složitost modelu, což vede k jednodušším dotazům a nákladově efektivnějšímu procházení.

    Diagram vrcholu Luis z předchozího diagramu s ID, popiskem a vlastnostmi

Poznámka

Předchozí diagramy znázorňují zjednodušený grafový model, který porovnává pouze dva způsoby dělení vlastností entity.

Vzor vložených vrcholů s vlastnostmi obecně poskytuje výkonnější a škálovatelný přístup. Výchozí přístup k novému datovému modelu grafu by se měl přiklánět k tomuto vzoru.

Existují však scénáře, ve kterých může odkazování na vlastnost přinést výhody. Například pokud je odkazovaná vlastnost často aktualizována. Použijte samostatný vrchol, který představuje vlastnost, která se neustále mění, aby se minimalizovalo množství operací zápisu, které aktualizace vyžaduje.

Modely relací se směry okrajů

Po modelování vrcholů je možné přidat hrany, které označují vztahy mezi nimi. Prvním aspektem, který je potřeba vyhodnotit, je směr relace.

Objekty Edge mají výchozí směr, po kterém následuje procházení při použití out() funkcí nebo outE() . Použití tohoto přirozeného směru má za následek efektivní operaci, protože všechny vrcholy jsou uloženy s jejich odchozími okraji.

Při procházení opačným směrem od okraje s použitím in() funkce však vždy vznikne dotaz mezi oddíly. Přečtěte si další informace o dělení grafů. Pokud je potřeba neustále procházet pomocí in() funkce, doporučujeme přidat hrany v obou směrech.

Směr okraje můžete určit pomocí .to() predikátů nebo .from() s .addE() krokem Gremlin. Nebo pomocí knihovny bulk executor pro rozhraní Gremlin API.

Poznámka

Objekty Edge mají ve výchozím nastavení směr.

Popisky relací

Použití popisků relací může zlepšit efektivitu operací překladu hraničních zařízení. Tento vzor můžete použít následujícími způsoby:

  • Použijte k označení relace jiné než obecné termíny.
  • Přidružte popisek zdrojového vrcholu k popisku cílového vrcholu s názvem relace.

Diagram příkladů popisků relací

Čím konkrétnější popisek používá procházení k filtrování okrajů, tím lépe. Toto rozhodnutí může mít významný vliv i na náklady na dotazy. Náklady na dotaz můžete kdykoli vyhodnotit pomocí kroku executionProfile.

Další kroky