Оптимизация барьера Нептуна ()

#amazon-neptune

Вопрос:

https://docs.aws.amazon.com/neptune/latest/userguide/gremlin-traversal-tuning.html

В этой документации упоминается важная оптимизация, влияющая на движок Neptune версии 1.0.5.0, в которой рекомендуется barrier() выполнить шаг во время определенной последовательности обхода:

 g.V().hasLabel('airport').
  order().
    by(out().count(),desc).
  limit(10).
  out()
 

Относится ли это строго только к order().by().limit() последовательности или это также повлияет order().by().range() ?

Будет ли достаточно размещения в barrier() качестве самого последнего шага обхода или это должно произойти сразу после limit() ?

Если обход содержит несколько order().by().limit() последовательностей, будет barrier() ли достаточно одной или каждому экземпляру нужна своя собственная barrier() ? Обратите внимание, что я использую их внутри project(...).by(__.order().by().limit()).by(__.order().by().limit()) .

Комментарии:

1. Привет. Это изменение влияет на любой шаг заказа. Размещения одного барьера в любом месте запроса, например, в самом конце, как вы предлагаете, должно быть достаточно. Можете ли вы опубликовать конкретный пример того, как вы используете project order ? Это поможет мне убедиться, что ответ применим и там.

2. @KelvinLawrence Вот пример g.V() .hasLabel("user") .order() .by("postStreakRecord", order.desc) .by( __.out("post") .order() .by("createdDate", order.desc) .limit(1) .values("createdDate"), order.desc ) .by("postCount", order.desc) .by("createdDate", order.asc);

3. @KelvinLawrence Вот пример, в котором используются вложенные project и order из моего кода. g.V().hasLabel("alert").order().by("createdDate").limit(10).project("id", "users").by(__.id()).by( __.out("alert").hasLabel("user").order().by("createdDate").limit(10).project("id").by(__.id()) ) . Хватит ли одного barrier() в конце?