Skip to content

Commit 519db06

Browse files
Merge pull request #271101 from AbhinavTrips/main
Python Code addition
2 parents 861ad4f + b87f190 commit 519db06

File tree

3 files changed

+100
-7
lines changed

3 files changed

+100
-7
lines changed

articles/cosmos-db/hierarchical-partition-keys.md

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -65,6 +65,7 @@ Find the latest preview version of each supported SDK:
6565
| .NET SDK v3 | >= 3.33.0 | <https://www.nuget.org/packages/Microsoft.Azure.Cosmos/3.33.0/> |
6666
| Java SDK v4 | >= 4.42.0 | <https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-cosmos/CHANGELOG.md#4420-2023-03-17/> |
6767
| JavaScript SDK v4 | 4.0.0 | <https://www.npmjs.com/package/@azure/cosmos/> |
68+
| Python SDK | >= 4.6.0 | <https://pypi.org/project/azure-cosmos/4.6.0/> |
6869

6970
## Create a container by using hierarchical partition keys
7071

@@ -172,6 +173,14 @@ console.log(container.id);
172173

173174
```
174175

176+
#### [Python SDK](#tab/python)
177+
178+
```python
179+
container = database.create_container(
180+
id=container_name, partition_key=PartitionKey(path=["/tenantId", "/userId", "/sessionId"], kind="MultiHash")
181+
)
182+
```
183+
175184
---
176185

177186
### Azure Resource Manager templates
@@ -300,6 +309,18 @@ const item: UserSession = {
300309
// Pass in the object, and the SDK automatically extracts the full partition key path
301310
const { resource: document } = await = container.items.create(item);
302311

312+
```
313+
314+
#### [Python SDK](#tab/python)
315+
316+
```python
317+
# specify values for all fields on partition key path
318+
item_definition = {'id': 'f7da01b0-090b-41d2-8416-dacae09fbb4a',
319+
'tenantId': 'Microsoft',
320+
'userId': '8411f20f-be3e-416a-a3e7-dcd5a3c1f28b',
321+
'sessionId': '0000-11-0000-1111'}
322+
323+
item = container.create_item(body=item_definition)
303324
```
304325
---
305326

@@ -374,6 +395,20 @@ const partitionKey: PartitionKey = new PartitionKeyBuilder()
374395
// Create the item in the container
375396
const { resource: document } = await container.items.create(item, partitionKey);
376397
```
398+
399+
#### [Python SDK](#tab/python)
400+
401+
For python, just make sure that values for all the fields in the partition key path are specified in the item definition.
402+
403+
```python
404+
# specify values for all fields on partition key path
405+
item_definition = {'id': 'f7da01b0-090b-41d2-8416-dacae09fbb4a',
406+
'tenantId': 'Microsoft',
407+
'userId': '8411f20f-be3e-416a-a3e7-dcd5a3c1f28b',
408+
'sessionId': '0000-11-0000-1111'}
409+
410+
item = container.create_item(body=item_definition)
411+
```
377412
---
378413

379414
### Perform a key/value lookup (point read) of an item
@@ -432,6 +467,14 @@ const partitionKey: PartitionKey = new PartitionKeyBuilder()
432467
// Perform a point read
433468
const { resource: document } = await container.item(id, partitionKey).read();
434469
```
470+
471+
#### [Python SDK](#tab/python)
472+
473+
```python
474+
item_id = "f7da01b0-090b-41d2-8416-dacae09fbb4a"
475+
pk = ["Microsoft", "8411f20f-be3e-416a-a3e7-dcd5a3c1f28b", "0000-11-0000-1111"]
476+
container.read_item(item=item_id, partition_key=pk)
477+
```
435478
---
436479

437480
### Run a query
@@ -514,6 +557,20 @@ while (queryIterator.hasMoreResults()) {
514557
}
515558
```
516559

560+
#### [Python SDK](#tab/python)
561+
562+
```python
563+
pk = ["Microsoft", "8411f20f-be3e-416a-a3e7-dcd5a3c1f28b", "0000-11-0000-1111"]
564+
items = list(container.query_items(
565+
query="SELECT * FROM r WHERE r.tenantId=@tenant_id and r.userId=@user_id and r.sessionId=@session_id",
566+
parameters=[
567+
{"name": "@tenant_id", "value": pk[0]},
568+
{"name": "@user_id", "value": pk[1]},
569+
{"name": "@session_id", "value": pk[2]}
570+
]
571+
))
572+
```
573+
517574
---
518575

519576
#### Targeted multi-partition query on a subpartitioned container
@@ -575,6 +632,22 @@ while (queryIterator.hasMoreResults()) {
575632
const { resources: results } = await queryIterator.fetchNext();
576633
// Process result
577634
}
635+
```
636+
637+
#### [Python SDK](#tab/python)
638+
639+
```python
640+
pk = ["Microsoft", "8411f20f-be3e-416a-a3e7-dcd5a3c1f28b", "0000-11-0000-1111"]
641+
# enable_cross_partition_query should be set to True as the container is partitioned
642+
items = list(container.query_items(
643+
query="SELECT * FROM r WHERE r.tenantId=@tenant_id and r.userId=@user_id",
644+
parameters=[
645+
{"name": "@tenant_id", "value": pk[0]},
646+
{"name": "@user_id", "value": pk[1]}
647+
],
648+
enable_cross_partition_query=True
649+
))
650+
578651
```
579652
---
580653

articles/cosmos-db/nosql/index-metrics.md

Lines changed: 18 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -14,8 +14,13 @@ ms.reviewer: jucocchi
1414

1515
Azure Cosmos DB provides indexing metrics to show both utilized indexed paths and recommended indexed paths. You can use the indexing metrics to optimize query performance, especially in cases where you aren't sure how to modify the [indexing policy](../index-policy.md)).
1616

17-
> [!NOTE]
18-
> The indexing metrics are only supported in the .NET SDK (version 3.21.0 or later) and Java SDK (version 4.19.0 or later)
17+
## Supported SDK versions
18+
Indexing metrics are supported in the following SDK versions:
19+
| SDK | Supported versions |
20+
| --- | --- |
21+
| .NET SDK v3 | >= 3.21.0 |
22+
| Java SDK v4 | >= 4.19.0 |
23+
| Python SDK | >= 4.6.0 |
1924

2025
## Enable indexing metrics
2126

@@ -91,6 +96,17 @@ const { resources: resultsIndexMetrics, indexMetrics } = await container.items
9196
.fetchAll();
9297
console.log("IndexMetrics: ", indexMetrics);
9398
```
99+
100+
## [Python SDK](#tab/python)
101+
You can capture index metrics by passing in the populate_index_metrics keyword in query items and then reading the value for "x-ms-cosmos-index-utilization" header from the response. This header is returned only if the query returns some items.
102+
103+
```python
104+
query_items = container.query_items(query="Select * from c",
105+
enable_cross_partition_query=True,
106+
populate_index_metrics=True)
107+
108+
print(container.client_connection.last_response_headers['x-ms-cosmos-index-utilization'])
109+
```
94110
---
95111

96112
### Example output

articles/cosmos-db/nosql/materialized-views.md

Lines changed: 9 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: Materialized views (preview)
33
titleSuffix: Azure Cosmos DB for NoSQL
4-
description: Learn how to efficiently query a base container by using predefined filters in materialized views for Azure Cosmos DB for NoSQL. Use Materialized Views as Global Secondary Indexes.
4+
description: Learn how to efficiently query a base container by using predefined filters in materialized views for Azure Cosmos DB for NoSQL. Use materilaized views as global secondary indexes to avoid expensive cross-partition queries.
55
author: AbhinavTrips
66
ms.author: abtripathi
77
ms.reviewer: sidandrews
@@ -21,15 +21,18 @@ ms.date: 06/09/2023
2121
2222
Applications frequently are required to make queries that don't specify a partition key. In these cases, the queries might scan through all data for a small result set. The queries end up being expensive because they inadvertently run as a cross-partition query.
2323

24-
Materialized views, when defined, help provide a way to efficiently query a base container in Azure Cosmos DB by using filters that don't include the partition key. When users write to the base container, the materialized view is built automatically in the background. This view can have a different partition key for efficient lookups. The view also contains only fields that are explicitly projected from the base container. This view is a read-only table. The Azure Cosmos DB Materialized Views for NoSQL API, can be used as Global Secondary Indexes for your workloads.
24+
Materialized views, when defined, help provide a way to efficiently query a base container in Azure Cosmos DB by using filters that don't include the partition key. When users write to the base container, the materialized view is built automatically in the background. This view can have a different partition key for efficient lookups. The view also contains only fields that are explicitly projected from the base container. This view is a read-only table. The Azure Cosmos DB materialized views can be used as global secondary indexes to avoid expensive cross-partition queries.
2525

26-
With the Azure Cosmos DB Materialized Views (or the Global Secondary Index) for NoSQL API, you can:
26+
> [!IMPORTANT]
27+
> The materialized view feature of Azure Cosmos DB for NoSQL can be used as Global Secondary Indexes. Users can specify the fields that are projected from the base container to the materialized view and they can choose a different partition key for the materialized view. Choosing a different partition key based on the most common queries, helps in scoping the queries to a single logical partition and avoiding cross-partition queries..
28+
29+
With a materialized view, you can:
2730

28-
- Use the view as a lookup or mapping container to avoid cross-partition scans that would otherwise be expensive queries.
31+
- Use the view as a lookup or mapping container to persist cross-partition scans that would otherwise be expensive queries.
2932
- Provide a SQL-based predicate (without conditions) to populate only specific fields.
3033
- Use change feed triggers to create real-time views to simplify event-based scenarios that are commonly stored as separate containers.
3134

32-
The benefits of using materialized views include, but aren't limited to:
35+
The benefits of using Azure Cosmos DB Materiliazed Views include, but aren't limited to:
3336

3437
- You can implement server-side denormalization by using materialized views. With server-side denormalization, you can avoid multiple independent tables and computationally complex denormalization in client applications.
3538
- Materialized views automatically update views to keep views consistent with the base container. This automatic update abstracts the responsibilities of your client applications that would otherwise typically implement custom logic to perform dual writes to the base container and the view.
@@ -38,6 +41,7 @@ The benefits of using materialized views include, but aren't limited to:
3841
- You can configure a materialized view builder layer to map to your requirements to hydrate a view.
3942
- Materialized views improve write performance (compared to a multi-container-write strategy) because write operations need to be written only to the base container.
4043
- The Azure Cosmos DB implementation of materialized views is based on a pull model. This implementation doesn't affect write performance.
44+
- Azure Cosmos DB materialized views for NoSQL API caters to the Global Secondary Index use cases as well. Global Secondary Indexes are also used to maintain secondary data views and help in reducing cross-partition queries.
4145

4246
## Prerequisites
4347

0 commit comments

Comments
 (0)