Używanie grafu podzielonego na partycje w usłudze Azure Cosmos DB

  • Artykuł

DOTYCZY: Gremlin

Jedną z kluczowych funkcji interfejsu API dla języka Gremlin w usłudze Azure Cosmos DB jest możliwość obsługi grafów na dużą skalę przez skalowanie w poziomie. Kontenery mogą być skalowane niezależnie pod względem magazynu i przepływności. Kontenery można tworzyć w usłudze Azure Cosmos DB, które można automatycznie skalować w celu przechowywania danych grafu. Dane są automatycznie zrównoważone na podstawie określonego klucza partycji.

Partycjonowanie odbywa się wewnętrznie, jeśli kontener ma przechowywać więcej niż 20 GB rozmiaru lub jeśli chcesz przydzielić więcej niż 10 000 jednostek żądań na sekundę (RU). Dane są automatycznie partycjonowane na podstawie określonego klucza partycji. Klucz partycji jest wymagany, jeśli tworzysz kontenery grafu na podstawie Azure Portal lub 3.x lub nowszych wersji sterowników języka Gremlin. Klucz partycji nie jest wymagany, jeśli używasz sterowników Języka Gremlin w wersji 2.x lub niższej.

Te same ogólne zasady mechanizmu partycjonowania usługi Azure Cosmos DB mają zastosowanie z kilkoma optymalizacjami specyficznymi dla grafu opisanymi poniżej.

Partycjonowanie grafu.

Mechanizm partycjonowania grafu

W poniższych wytycznych opisano sposób działania strategii partycjonowania w usłudze Azure Cosmos DB:

  • Zarówno wierzchołki, jak i krawędzie są przechowywane jako dokumenty JSON.

  • Wierzchołki wymagają klucza partycji. Ten klucz określi, w której partycji będzie przechowywany wierzchołek za pomocą algorytmu wyznaczania wartości skrótu. Nazwa właściwości klucza partycji jest definiowana podczas tworzenia nowego kontenera i ma format: /partitioning-key-name.

  • Krawędzie będą przechowywane z ich wierzchołkiem źródłowym. Innymi słowy, dla każdego wierzchołka klucz partycji definiuje, gdzie są przechowywane wraz z krawędziami wychodzącymi. Ta optymalizacja jest wykonywana w celu uniknięcia zapytań między partycjami podczas korzystania z out() kardynalności zapytań grafu.

  • Krawędzie zawierają odwołania do wierzchołków, do których wskazują. Wszystkie krawędzie są przechowywane przy użyciu kluczy partycji i identyfikatorów wierzchołków, do których wskazują. To obliczenie sprawia, że wszystkie out() zapytania kierunkowe są zawsze zapytaniem podzielonym na partycje o określonym zakresie, a nie ślepym zapytaniem między partycjami.

  • Zapytania programu Graph muszą określać klucz partycji. Aby w pełni wykorzystać partycjonowanie poziome w usłudze Azure Cosmos DB, klucz partycji należy określić po wybraniu pojedynczego wierzchołka, gdy jest to możliwe. Poniżej przedstawiono zapytania dotyczące wybierania jednego lub wielu wierzchołków na wykresie podzielonym na partycje:

    • /id i /label nie są obsługiwane jako klucze partycji dla kontenera w interfejsie API dla języka Gremlin.

    • Wybranie wierzchołka według identyfikatora, a następnie użycie .has() kroku w celu określenia właściwości klucza partycji:

      g.V('vertex_id').has('partitionKey', 'partitionKey_value')

    • Wybranie wierzchołka przez określenie krotki zawierającej wartość klucza partycji i identyfikator:

      g.V(['partitionKey_value', 'vertex_id'])

    • Wybranie zestawu wierzchołków przy użyciu identyfikatorów i określenie listy wartości klucza partycji:

      g.V('vertex_id0', 'vertex_id1', 'vertex_id2', …).has('partitionKey', within('partitionKey_value0', 'partitionKey_value01', 'partitionKey_value02', …)

    • Użycie strategii partycjonowania na początku zapytania i określenie partycji dla zakresu pozostałej części zapytania Gremlin:

      g.withStrategies(PartitionStrategy.build().partitionKey('partitionKey').readPartitions('partitionKey_value').create()).V()

Najlepsze rozwiązania dotyczące korzystania z partycjonowanego grafu

Skorzystaj z poniższych wskazówek, aby zapewnić wydajność i skalowalność podczas korzystania z partycjonowanych grafów z nieograniczonymi kontenerami:

  • Zawsze należy określić wartość klucza partycji podczas wykonywania zapytań względem wierzchołka. Uzyskiwanie wierzchołka ze znanej partycji jest sposobem osiągnięcia wydajności. Wszystkie kolejne operacje sąsiedztwa będą zawsze ograniczone do partycji, ponieważ krawędzie zawierają identyfikator odwołania i klucz partycji do ich wierzchołków docelowych.

  • Użyj kierunku wychodzącego podczas wykonywania zapytań o krawędzie, gdy jest to możliwe. Jak wspomniano powyżej, krawędzie są przechowywane ze swoimi wierzchołkami źródłowymi w kierunku wychodzącym. Dlatego szanse na uciekanie się do zapytań obejmujących wiele partycji są zminimalizowane, gdy dane i zapytania są zaprojektowane z uwzględnieniem tego wzorca. W przeciwieństwie do tego in() zapytanie zawsze będzie kosztowną kwerendą fan-out.

  • Wybierz klucz partycji, który będzie równomiernie dystrybuować dane między partycjami. Ta decyzja w dużym stopniu zależy od modelu danych rozwiązania. Przeczytaj więcej na temat tworzenia odpowiedniego klucza partycji w temacie Partycjonowanie i skalowanie w usłudze Azure Cosmos DB.

  • Optymalizowanie zapytań w celu uzyskania danych w granicach partycji. Optymalna strategia partycjonowania zostanie dopasowana do wzorców wykonywania zapytań. Zapytania, które uzyskują dane z jednej partycji, zapewniają najlepszą możliwą wydajność.

Następne kroki

Następnie możesz przejść do przeczytania następujących artykułów: