{"id":3681,"date":"2021-11-09T19:43:58","date_gmt":"2021-11-10T03:43:58","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cosmosdb\/?p=3681"},"modified":"2021-11-24T07:14:16","modified_gmt":"2021-11-24T15:14:16","slug":"improve-application-performance-with-java-v4-sdk-for-cosmos-db","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cosmosdb\/improve-application-performance-with-java-v4-sdk-for-cosmos-db\/","title":{"rendered":"Improve application performance with Java SDK v4 for Azure Cosmos DB"},"content":{"rendered":"

The Java SDK v4 for Azure Cosmos DB<\/a> has many improvements and new APIs to help increase the performance of your applications. In this blog post, I will highlight a few of these improvements that help improve application performance by reducing the number of network roundtrips and latency when using direct mode in the Java v4 SDK.<\/span><\/p>\n

Here is\u00a0<\/span>what\u00a0<\/span>the SDK does behind the scenes\u00a0<\/span>for a\u00a0<\/span>query:<\/span><\/span><\/p>\n

\"Image<\/a><\/p>\n

Image: How the SDK handles queries<\/figcaption><\/figure>\n

 <\/p>\n

In\u00a0direct mode<\/a>, every time a query is executed via the SDK the first step is a network call to retrieve the query plan before the query can be executed on the replicas. Query plan, which is used internally, has the execution information required to execute a query on the replicas. This query plan retrieval adds overhead for every query. With the Java SDK you now have options to either minimize the query plan calls or eliminate them. Let us look at the options.<\/span><\/p>\n

 <\/p>\n

Query plan caching<\/strong><\/span><\/p>\n

The query plan, for a query scoped to a single partition, is cached on the client. This eliminates the need to make a call to the gateway to retrieve the query plan after the first call. The key for the cached query plan is the SQL query string. You need to make sure the query is parametrized. If not, the query plan cache lookup will often be a cache miss as the query string is unlikely to be identical across calls. Query plan caching is enabled by default for version 4.20.0 or above. Let us look at a couple of query strings to better understand the concept.<\/span><\/p>\n

SELECT * FROM o WHERE o.category = @category and o.author= @author<\/pre>\n
Once cached, the query plan look-up for the above query string will be a cache hit irrespective of the actual parameter (@category and @author) values.<\/span><\/p>\n
SELECT * FROM o WHERE o.category =\u201cDatabases\u201d and o.author= \u201cRavi\u201d<\/pre>\n
Once cached, the query plan look-up for the above query string will be a cache hit, only for a query string with parameter values \u201cDatabase\u201d and \u201cRavi\u201d, because the query is not parameterized.<\/span><\/p>\n
\u201ccategory\u201d is the partition key for both the queries. As I have mentioned previously, query caching only works for queries scoped to a single partition. The partition key value must be set using \u201cCosmosQueryRequestOptions\u201d object for query plan caching to work.\u00a0<\/span><\/p>\n
Every time there is a cache hit for a query plan you will see the following message in the logs.<\/span><\/p>\n
\u201cSkipping query plan round trip by using the cached plan\u201d<\/pre>\n
Query plan caching currently works for queries with filters. This feature can also be leveraged from the Spring connector when using method derived queries. Currently, queries defined with \u201c@Query\u201d spring data annotation, do not take advantage of Query plan caching.<\/span><\/p>\n
 <\/p>\n
CosmosAsyncContainer#readAllItems<\/b>\u00a0<\/span><\/p>\n
This API allows you to retrieve all documents with the same partition key value. Behind the scenes, the SDK generates and executes a query on the replicas, but there will be no call made to the gateway for query plan. This API is available from SDK version 4.15.0 or above.\u00a0<\/span><\/p>\n
container.readAllItems(new PartitionKey(category), cosmosItemRequestOptions, Book.class)\r\n\r\n<\/pre>\n
 <\/p>\n
CosmosAsyncContainer#readMany<\/strong><\/span><\/p>\n
The ReadMany API does something similar for retrieving multiple documents by ID and partition Key. Simply put, if you want to retrieve multiple documents by ID and partition key, instead of calling “CosmosAsyncContainer#readItem” point read API, multiple times you can use this API to retrieve all the documents in parallel. Once again, the SDK behind the scenes will generate and execute the query on the replicas without making a call to the gateway for query plan. This API is available from SDK version 4.5.0 or above.<\/span><\/p>\n
CosmosItemIdentity itemIdentity1 = new CosmosItemIdentity(new PartitionKey(\"Programming Languages\"), \"4\");\r\nCosmosItemIdentity itemIdentity2 = new CosmosItemIdentity(new PartitionKey(\"Databases\"), \"6\");\r\nList<CosmosItemIdentity> itemIdentities = Lists.newArrayList(itemIdentity1,itemIdentity2);\r\ncontainer.readMany(itemIdentities,Book.class);<\/pre>\n
As always, we highly recommend upgrading to the latest version of the SDK for best results.<\/span><\/p>\n
Next Steps:<\/strong><\/span><\/p>\n