Modelowanie danych grafu za pomocą usługi Azure Cosmos DB dla języka Apache Gremlin
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 w przypadku grafów na dużą skalę.
Wymagania
Proces opisany w tym przewodniku jest oparty na następujących założeniach:
- Jednostki w przestrzeni problemowej 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.
- Istnieją dynamicznie ewoluujące relacje między jednostkami. Ten wzorzec ma szczególnie zastosowanie do danych hierarchicznych lub ze strukturą drzewa z wieloma poziomami.
- Istnieją relacje wiele-do-wielu między jednostkami.
- 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 graf będzie używany do celów analitycznych lub transakcyjnych. Jeśli wykres ma być używany do dużych obciążeń obliczeniowych i przetwarzania danych, warto eksplorować łącznik Spark usługi Cosmos DB i bibliotekę GraphX.
Jak używać obiektów grafu
Standard grafu 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:
| Objekt | Właściwość | Type | Uwagi |
|---|---|---|---|
| Wierzchołek | IDENTYFIKATOR | String | Unikatowo wymuszane na partycję. Jeśli wartość nie jest dostarczana podczas wstawiania, jest przechowywany automatycznie wygenerowany identyfikator GUID. |
| Wierzchołek | Etykieta | String | Ta właściwość służy do definiowania typu jednostki reprezentowanej przez wierzchołek. Jeśli wartość nie zostanie podana, 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 | IDENTYFIKATOR | String | Unikatowo wymuszane na partycję. Domyślnie generowane automatycznie. Krawędzie zwykle nie muszą być unikatowo pobierane przez identyfikator. |
| Edge | Etykieta | String | 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ść na 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 partycjonowanego grafu w usłudze Azure Cosmos DB).
Wytyczne dotyczące modelowania jednostek i relacji
Poniższe wytyczne ułatwiają modelowanie danych dla bazy danych usługi Azure Cosmos DB dla 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. Należy ocenić i przetestować ostateczny model przed rozważeniem go jako gotowego do produkcji. 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 modelu danych grafu jest mapowania każdej zidentyfikowanej jednostki na obiekt wierzchołka. Mapowanie "jeden do jednego" wszystkich jednostek do wierzchołków powinno być krokiem początkowym i może ulec zmianie.
Jedną z typowych pułapek 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, aby opisać 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ść zapytań i koszt obliczeń. Ten model może również stanowić wyzwania związane z partycjonowaniem.
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 wydajnych przechodzenia.
Uwaga
Na powyższych diagramach przedstawiono uproszczony model grafu, który porównuje tylko dwa sposoby dzielenia właściwości jednostki.
Wzorzec osadzonych wierzchołków właściwości zwykle 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órych 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ć liczbę 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, po którym następuje przechodzenie podczas korzystania z out() funkcji lub outE() . Użycie tego naturalnego kierunku powoduje wydajną operację, ponieważ wszystkie wierzchołki są przechowywane z ich krawędzi wychodzących.
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 istnieje 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
Obiekty krawędzi domyślnie 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ą wierzchołka docelowego z nazwą relacji.
Bardziej szczegółowa etykieta, która jest używana przez przechodzenie do filtrowania krawędzi, tym lepiej. 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
- Zapoznaj się z listą obsługiwanych kroków języka Gremlin.
- Dowiedz się więcej na temat partycjonowania bazy danych grafów w celu obsługi grafów na dużą skalę.
- Oceń zapytania języka Gremlin przy użyciu kroku profilu wykonywania.
- Model danych projektu grafu innej firmy.