Frequently asked questions about Azure Cosmos DB for Apache Gremlin

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. For example, you can add the step to the end of a g.V('example').out('relationship') query resulting in g.V('example').out('relationship').executionProfile().

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's 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 is based on all the graph objects that it takes 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, an 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 uses the open-source drivers as the main connectors for the service. So the recommended option is to use drivers supported by Apache.

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://<account-name>.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 seen when you run a query that obtains all vertices:

// Query example:
g.V()

This query attempts 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.

Related content

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

Next step