Modelowanie danych grafu za pomocą usługi Azure Cosmos DB dla języka Apache Gremlin

  • Artykuł

DOTYCZY: Gremlin

Ten artykuł zawiera zalecenia dotyczące korzystania z modeli danych grafu. Te najlepsze rozwiązania są niezbędne do zapewnienia skalowalności i wydajności systemu grafowej bazy danych w miarę rozwoju danych. Wydajny model danych jest szczególnie ważny dla grafów na dużą skalę.

Wymagania

Proces opisany w tym przewodniku opiera się na następujących założeniach:

  • Jednostki w obszarze problemu są identyfikowane. Te jednostki mają być używane niepodziealnie dla każdego żądania. Innymi słowy, system bazy danych nie jest przeznaczony do pobierania danych pojedynczej jednostki w wielu żądaniach zapytań.
  • Istnieje wiedza na temat wymagań dotyczących odczytu i zapisu dla systemu bazy danych. Te wymagania prowadzą do optymalizacji wymaganych dla modelu danych grafu.
  • Zasady standardu grafu właściwości Apache Tinkerpop są dobrze zrozumiałe.

Kiedy potrzebuję grafowej bazy danych?

Rozwiązanie grafowej bazy danych może być optymalnie używane, jeśli jednostki i relacje w domenie danych mają dowolną z następujących cech:

  • Jednostki są bardzo połączone za pośrednictwem relacji opisowych. Korzyścią w tym scenariuszu jest to, że relacje są utrwalane w magazynie.
  • Istnieją cykliczne relacje lub jednostki odwołujące się do siebie. Ten wzorzec jest często wyzwaniem podczas korzystania z relacyjnych lub dokumentów baz danych.
  • Między jednostkami dynamicznie ewoluują relacje . Ten wzorzec jest szczególnie stosowany do danych hierarchicznych lub drzewa ze strukturą wielu poziomów.
  • Między jednostkami istnieje relacje wiele-do-wielu .
  • Istnieją wymagania dotyczące zapisu i odczytu zarówno dla jednostek, jak i relacji.

Jeśli powyższe kryteria są spełnione, podejście do grafowej bazy danych prawdopodobnie zapewnia zalety złożoności zapytań, skalowalności modelu danych i wydajności zapytań.

Następnym krokiem jest ustalenie, czy wykres będzie używany do celów analitycznych lub transakcyjnych. Jeśli graf ma być używany do dużych obciążeń obliczeniowych i przetwarzania danych, warto zbadać łącznik Spark usługi Cosmos DB i bibliotekę GraphX.

Jak używać obiektów grafu

Standard wykresu właściwości Apache Tinkerpop definiuje dwa typy obiektów: wierzchołki i krawędzie.

Poniżej przedstawiono najlepsze rozwiązania dotyczące właściwości w obiektach grafu:

Obiekt Właściwość Typ Uwagi
Wierzchołek ID (Identyfikator) Ciąg Unikatowo wymuszone na partycję. Jeśli wartość nie jest dostarczana podczas wstawiania, jest przechowywany automatycznie wygenerowany identyfikator GUID.
Wierzchołek Etykieta Ciąg Ta właściwość służy do definiowania typu jednostki reprezentowanej przez wierzchołek. Jeśli wartość nie zostanie dostarczona, zostanie użyty wierzchołek wartości domyślnej.
Wierzchołek Właściwości Ciąg, wartość logiczna, numeryczna Lista oddzielnych właściwości przechowywanych jako pary klucz-wartość w każdym wierzchołku.
Wierzchołek Klucz partycji Ciąg, wartość logiczna, numeryczna Ta właściwość definiuje miejsce przechowywania wierzchołka i jego krawędzi wychodzących. Przeczytaj więcej na temat partycjonowania grafu.
Edge ID (Identyfikator) Ciąg Unikatowo wymuszone na partycję. Domyślnie generowane automatycznie. Krawędzie zwykle nie muszą być unikatowo pobierane przez identyfikator.
Edge Etykieta Ciąg Ta właściwość służy do definiowania typu relacji, którą mają dwa wierzchołki.
Edge Właściwości Ciąg, wartość logiczna, numeryczna Lista oddzielnych właściwości przechowywanych jako pary klucz-wartość w każdej krawędzi.

Uwaga

Krawędzie nie wymagają wartości klucza partycji, ponieważ wartość jest przypisywana automatycznie na podstawie ich wierzchołka źródłowego. Dowiedz się więcej w temacie Using a partitioned graph in Azure Cosmos DB (Korzystanie z wykresu partycjonowanego w usłudze Azure Cosmos DB).

Wytyczne dotyczące modelowania jednostek i relacji

Poniższe wskazówki ułatwiają podejście do modelowania danych dla bazy danych usługi Azure Cosmos DB dla bazy danych grafów Apache Gremlin . W tych wytycznych przyjęto założenie, że istnieje istniejąca definicja domeny danych i zapytania dotyczące tej domeny.

Uwaga

Poniższe kroki są prezentowane jako zalecenia. Przed rozważeniem go jako gotowego do produkcji należy ocenić i przetestować ostateczny model. Ponadto zalecenia są specyficzne dla implementacji interfejsu API języka Gremlin usługi Azure Cosmos DB.

Modelowanie wierzchołków i właściwości

Pierwszym krokiem dla modelu danych grafu jest mapowania każdej zidentyfikowanej jednostki na obiekt wierzchołka. Jedno-jedno mapowanie wszystkich jednostek na wierzchołki powinno być krokiem początkowym i może ulec zmianie.

Jedną z typowych pułapki jest mapowania właściwości pojedynczej jednostki jako oddzielnych wierzchołków. Rozważmy następujący przykład, w którym ta sama jednostka jest reprezentowana na dwa różne sposoby:

  • Właściwości oparte na wierzchołku: W tym podejściu jednostka używa trzech oddzielnych wierzchołków i dwóch krawędzi do opisywania jej właściwości. Chociaż takie podejście może zmniejszyć nadmiarowość, zwiększa złożoność modelu. Zwiększenie złożoności modelu może spowodować dodatkowe opóźnienie, złożoność zapytania i koszt obliczeń. Ten model może również stanowić wyzwania związane z partycjonowaniem.

    Diagram modelu jednostki z wierzchołkami właściwości.

  • Wierzchołki osadzone właściwości: to podejście wykorzystuje listę par klucz-wartość do reprezentowania wszystkich właściwości jednostki wewnątrz wierzchołka. Takie podejście zmniejsza złożoność modelu, co prowadzi do prostszych zapytań i bardziej ekonomicznego przechodzenia.

    Diagram wierzchołka usługi Luis z poprzedniego diagramu z identyfikatorem, etykietą i właściwościami.

Uwaga

Na powyższych diagramach przedstawiono uproszczony model grafu, który porównuje tylko dwa sposoby dzielenia właściwości jednostki.

Wzorzec wierzchołków osadzonych właściwości zazwyczaj zapewnia bardziej wydajne i skalowalne podejście. Domyślne podejście do nowego modelu danych grafu powinno być grawitacyjne w kierunku tego wzorca.

Istnieją jednak scenariusze, w których odwoływanie się do właściwości może zapewnić korzyści. Jeśli na przykład właściwość, do której odwołuje się odwołanie, jest często aktualizowana. Użyj oddzielnego wierzchołka, aby reprezentować właściwość, która stale się zmienia, aby zminimalizować ilość operacji zapisu, których wymaga aktualizacja.

Modele relacji z kierunkami krawędzi

Po modelowaniu wierzchołków można dodać krawędzie, aby oznaczyć relacje między nimi. Pierwszym aspektem, który należy ocenić, jest kierunek relacji.

Obiekty krawędzi mają domyślny kierunek przechodzenia podczas korzystania z out() funkcji lub outE() . Użycie tego naturalnego kierunku powoduje wydajną operację, ponieważ wszystkie wierzchołki są przechowywane z ich krawędziami wychodzącymi.

Jednak przechodzenie w przeciwnym kierunku krawędzi przy użyciu in() funkcji zawsze powoduje zapytanie obejmujące wiele partycji. Dowiedz się więcej o partycjonowaniu grafu. Jeśli zachodzi potrzeba ciągłego przechodzenia przy użyciu in() funkcji, zaleca się dodanie krawędzi w obu kierunkach.

Kierunek krawędzi można określić przy użyciu .to() predykatów lub .from() w .addE() kroku Języka Gremlin. Lub przy użyciu biblioteki funkcji wykonawczej operacji zbiorczych dla interfejsu API języka Gremlin.

Uwaga

Domyślnie obiekty brzegowe mają kierunek.

Etykiety relacji

Używanie opisowych etykiet relacji może zwiększyć wydajność operacji rozpoznawania krawędzi. Ten wzorzec można zastosować w następujący sposób:

  • Użyj terminów innych niż ogólne, aby oznaczyć relację.
  • Skojarz etykietę wierzchołka źródłowego z etykietą docelowego wierzchołka z nazwą relacji.

Diagram przykładów etykietowania relacji.

Bardziej szczegółowa etykieta używana przez przechodzenie do filtrowania krawędzi jest tym lepsza. Ta decyzja może również mieć znaczący wpływ na koszt zapytania. Koszt zapytania można ocenić w dowolnym momencie przy użyciu kroku executionProfile.

Następne kroki