Общие сведения о fold () и его влиянии на стоимость запросов gremlin в Azure Cosmos DB - PullRequest
2 голосов
/ 09 мая 2019

Я пытаюсь понять стоимость запросов в Azure Cosmos DB

Я не могу понять, в чем разница в следующих примерах и почему использование fold () снижает стоимость:

g.V().hasLabel('item').project('itemId', 'id').by('itemId').by('id')

который производит следующий вывод:

[
  {
    "itemId": 14,
    "id": "186de1fb-eaaf-4cc2-b32b-de8d7be289bb"
  },
  {
    "itemId": 5,
    "id": "361753f5-7d18-4a43-bb1d-cea21c489f2e"
  },
  {
    "itemId": 6,
    "id": "1c0840ee-07eb-4a1e-86f3-abba28998cd1"
  },           
....    
  {
    "itemId": 5088,
    "id": "2ed1871d-c0e1-4b38-b5e0-78087a5a75fc"
  }
]

Стоимость составляет 15642 RU x 0,00008 $ / RU = 1,25 $

g.V().hasLabel('item').project('itemId', 'id').by('itemId').by('id').fold()

, который производит следующий вывод:

[
  [
    {
      "itemId": 14,
      "id": "186de1fb-eaaf-4cc2-b32b-de8d7be289bb"
    },
    {
      "itemId": 5,
      "id": "361753f5-7d18-4a43-bb1d-cea21c489f2e"
    },
    {
      "itemId": 6,
      "id": "1c0840ee-07eb-4a1e-86f3-abba28998cd1"
    },
...
    {
      "itemId": 5088,
      "id": "2ed1871d-c0e1-4b38-b5e0-78087a5a75fc"
    }
  ]
]

Стоимость составляет 787 RU x 0,00008 $ / RU = 0,06 $

g.V().hasLabel('item').values('id', 'itemId')

со следующим выводом:

[
  "186de1fb-eaaf-4cc2-b32b-de8d7be289bb",
  14,
  "361753f5-7d18-4a43-bb1d-cea21c489f2e",
  5,
  "1c0840ee-07eb-4a1e-86f3-abba28998cd1",
  6,
...
  "2ed1871d-c0e1-4b38-b5e0-78087a5a75fc",
  5088
]

стоимость: 10639 RU x 0,00008 $ / RU = 0,85$

g.V().hasLabel('item').values('id', 'itemId').fold()

со следующим выводом:

[
  [
    "186de1fb-eaaf-4cc2-b32b-de8d7be289bb",
    14,
    "361753f5-7d18-4a43-bb1d-cea21c489f2e",
    5,
    "1c0840ee-07eb-4a1e-86f3-abba28998cd1",
    6,
...
    "2ed1871d-c0e1-4b38-b5e0-78087a5a75fc",
    5088
  ]
]

Стоимость составляет 724,27 RU x 0,00008 $ / RU = 0,057 $

Как видите, влияние настоимость огромна.Это только на ок.3200 узлов с несколькими свойствами.

Я хотел бы понять, почему добавление сгиба так сильно меняется.

1 Ответ

0 голосов
/ 07 июля 2019

Я пытался воспроизвести ваш пример, но, к сожалению, имел противоположные результаты (500 вершин в Космосе):

g.V().hasLabel('test').values('id')

или

g.V().hasLabel('test').project('id').by('id') 

дали соответственно 86,08 и 91,44 RU, тогда какте же запросы, за которыми следовал fold () step, привели к 585.06 и 590.43 RU.

Этот результат, который я получил, кажется нормальным, согласно документации TinkerPop :

Существуют ситуации, когда потоку обхода необходим «барьер» для агрегации всех объектов и создания вычислений, являющихся функцией агрегата.Сгиб () - шаг (карта) является одним конкретным примером этого.

Зная, что Космос взимает RU как для количества объектов, к которым осуществляется доступ, так и для вычислений, которые выполняются на этих полученных объектах ( сгиб (в данном конкретном случае), более высокие затраты на фолд ожидаются.

Вы можете попробовать выполнить executeProfile () шаг для обхода, который может помочь вам исследовать ваш случай,Когда я попытался:

g.V().hasLabel('test').values('id').executionProfile()

я получил 2 дополнительных шага для fold () (те же самые части вывода опущены для краткости), и это ProjectAggregation , гденабор результатов был сопоставлен с 500 до 1:

 ...
      {
        "name": "ProjectAggregation",
        "time": 165,
        "annotations": {
          "percentTime": 8.2
        },
        "counts": {
          "resultCount": 1
        }
      },
      {
        "name": "QueryDerivedTableOperator",
        "time": 1,
        "annotations": {
          "percentTime": 0.05
        },
        "counts": {
          "resultCount": 1
        }
      }
...
...