Frequently asked questions about the API for Gremlin in Azure Cosmos DB

The executionProfile() preview step can be used to provide an analysis of the query execution plan. This step needs to be added to the end of any Gremlin query as illustrated by the following example:

Query example

g.V('mary').out('knows').executionProfile()

Example output

[
  {
    "gremlin": "g.V('mary').out('knows').executionProfile()",
    "totalTime": 8,
    "metrics": [
      {
        "name": "GetVertices",
        "time": 3,
        "annotations": {
          "percentTime": 37.5
        },
        "counts": {
          "resultCount": 1
        }
      },
      {
        "name": "GetEdges",
        "time": 5,
        "annotations": {
          "percentTime": 62.5
        },
        "counts": {
          "resultCount": 0
        },
        "storeOps": [
          {
            "count": 0,
            "size": 0,
            "time": 0.6
          }
        ]
      },
      {
        "name": "GetNeighborVertices",
        "time": 0,
        "annotations": {
          "percentTime": 0
        },
        "counts": {
          "resultCount": 0
        }
      },
      {
        "name": "ProjectOperator",
        "time": 0,
        "annotations": {
          "percentTime": 0
        },
        "counts": {
          "resultCount": 0
        }
      }
    ]
  }
]

The output of the above profile shows how much time is spent obtaining the vertex objects, the edge objects, and the size of the working data set. This is related to the standard cost measurements for Azure Cosmos DB queries.

All graph objects, vertices, and edges, are shown as JSON documents in the backend. Since one Gremlin query can modify one or many graph objects at a time, the cost associated with it is directly related to the objects, edges that are processed by the query. This is the same process that Azure Cosmos DB uses for all other APIs. For more information, see Request Units in Azure Cosmos DB.

The RU charge is based on the working data set of the traversal, and not the result set. For example, if a query aims to obtain a single vertex as a result but needs to traverse more than one other object on the way, then the cost will be based on all the graph objects that it will take to compute the one result vertex.

Azure Cosmos DB makes use of horizontal partitioning to automatically address increase in storage and throughput requirements. The maximum throughput and storage capacity of a workload is determined by the number of partitions that are associated with a given container. However, a API for Gremlin container has a specific set of guidelines to ensure a proper performance experience at scale. For more information about partitioning, and best practices, see partitioning in Azure Cosmos DB article.

Azure Cosmos DB for Gremlin leverages the open-source drivers as the main connectors for the service. So the recommended option is to use drivers that are supported by Apache Tinkerpop.

Most native Apache Tinkerpop Gremlin drivers allow the option to provide a dictionary of parameters for query execution. This is an example of how to do it in Gremlin.Net and in Gremlin-Javascript.

Azure Cosmos DB for Gremlin implements a subset of the functionality defined in the Gremlin surface area. For supported steps and more information, see Gremlin support article.

The best workaround is to rewrite the required Gremlin steps with the supported functionality, since all essential Gremlin steps are supported by Azure Cosmos DB.

This error is likely thrown when the wrong endpoint is being used. The endpoint that generates this error has the following pattern:

https:// YOUR_DATABASE_ACCOUNT.documents.azure.com:443/

This is the documents endpoint for your graph database. The correct endpoint to use is the Gremlin Endpoint, which has the following format:

https://YOUR_DATABASE_ACCOUNT.gremlin.cosmosdb.azure.com:443/

This error means that the allocated Request Units per second aren't enough to serve the query. This error is usually seen when you run a query that obtains all vertices:

// Query example:
g.V()

This query will attempt to retrieve all vertices from the graph. So, the cost of this query will be equal to at least the number of vertices in terms of RUs. The RU/s setting should be adjusted to address this query.

A Gremlin connection is made through a WebSocket connection. Although WebSocket connections don't have a specific time to live, Azure Cosmos DB for Gremlin will terminate idle connections after 30 minutes of inactivity.

Fluent API calls aren't yet supported by the Azure Cosmos DB for Gremlin. Fluent API calls require an internal formatting feature known as bytecode support that currently isn't supported by Azure Cosmos DB for Gremlin. Due to the same reason, the latest Gremlin-JavaScript driver is also currently not supported.

Next steps

• Azure Cosmos DB for Gremlin wire protocol support
• Create, query, and traverse an Azure Cosmos DB graph database using the Gremlin console