You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/cosmos-db/mongodb/vcore/background-indexing.md
+23-18Lines changed: 23 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,9 @@
1
1
---
2
2
title: Background Indexing
3
3
titleSuffix: Background Indexing on Azure Cosmos DB for MongoDB vCore
4
-
description: background indexing to enable non-blocking operation during index creation
5
-
author: avijitkgupta
6
-
ms.author: avijitkgupta
4
+
description: Background indexing to enable non-blocking operation during index creation
5
+
author: avijitgupta
6
+
ms.author: avijitgupta
7
7
ms.reviewer: gahllevy
8
8
ms.service: cosmos-db
9
9
ms.subservice: mongodb-vcore
@@ -13,12 +13,21 @@ ms.date: 06/27/2024
13
13
14
14
# Background indexing (Preview)
15
15
16
-
Background indexing is a technique that enables a database system to perform indexing operations on a collection without blocking other queries or updates. Azure CosmosDB for Mongo vcore accepts the indexing request and asynchronously performs it in background.
Azure Cosmos DB for Mongo vcore allows indexing in background with property `enableIndexBuildBackground` set to true”. All indexes would be created in background except the unique indexes, post enabling the property.
18
+
Background indexing is a technique that enables a database system to perform indexing operations on a collection without blocking other queries or updates. Azure Cosmos DB for Mongo vcore accepts the background indexing request and asynchronously performs it in background.
19
+
20
+
Background indexing can be enabled using the property `enableIndexBuildBackground` set to `true`. All indexes would be created in background except the unique indexes, post enabling the property.
21
+
22
+
If working with smaller SKUs or workloads with higher I/O needs, it becomes necessary to predefine indexes on empty collections and avoid relying on background indexing.
19
23
20
24
> [!NOTE]
21
-
> If anticipated data size is large enough for a collection, then it might be sensible to create index on an empty collection.
25
+
> Enabling feature requires raising a support request.
26
+
27
+
> [!IMPORTANT]
28
+
> Ensure creating unique indexes on an empty collection as those are created in foreground.
29
+
>
30
+
> It is vital to create indexes based on query predicates beforehand, while the collection is still empty. It prevents resource contention if pushed on read-write heavy large collection.
We can observe the build status with values depicted in table.
92
+
## Limitations
84
93
85
-
| Status_Value | Status | Description |
86
-
|--------------|-------------|-------------|
87
-
| 1 | Queued | Request is queued |
88
-
| 2 | In progress | Request is picked |
89
-
| 3 | Failed | Request is already failed, 3 more retries will be attempted |
90
-
| 4 | Skippable | It should not be picked for processing. This should be deleted after 20 mins |
94
+
- Unique indexes can't be created in the background, it's best to create them on an empty collection and then load the data.
95
+
- Background indexing is performed sequentially within a single collection. However, background indexing can run concurrently across multiple collections.
91
96
92
-
## Limitations
97
+
## Next Steps
93
98
94
-
- Unique indexes cannot be created as background index. We recommend user to create unique index on empty collection first and then load the data into it.
95
-
- Background index are performed in sequence over a single collection. Though background indexes on multiple collections can run in parallel.
Indexes are structures that improve data retrieval speed by providing quick access to rows in a table. They work by creating an ordered set of pointers to data, often based on key columns. MongoDB vcore utilizes indexes in multiple contexts, including query push down, unique constraints and sharding.
19
19
20
+
> [!IMPORTANT]
21
+
> The "_id" field is the **only** field indexed by default. It is recommended to add additional indexes based on query filters & predicates to optimize performance.
22
+
20
23
## Index types
21
24
25
+
For simplicity, let us consider an example of a blog application with the following setup:
26
+
27
+
-**Database name**: `cosmicworks`
28
+
-**Collection name**: `products`
29
+
30
+
This example application stores articles as documents with the following structure. All the example quoted further utilizes the structure of this collection.
31
+
32
+
```json
33
+
{
34
+
"_id": ObjectId("617a34e7a867530bff1b2346"),
35
+
"title": "Azure Cosmos DB - A Game Changer",
36
+
"content": "Azure Cosmos DB is a globally distributed, multi-model database service.",
Single field indexes store information from a single field in a collection. The sort order of the single field index doesn't matter. _id field remains indexed by default.
@@ -29,13 +51,13 @@ MongoDB vcore supports creating index at following
29
51
- Embedded document.
30
52
- Fields within embedded document.
31
53
32
-
The following command creates a single field index on the field `name` and the following command creates it on an embedded field `firstName`.
54
+
The following command creates a single field index on the field `author` and the following command creates it on an embedded field `firstName`.
33
55
34
56
```javascript
35
-
db.coll.createIndex({"name":1})
57
+
db.coll.createIndex({"author":1})
36
58
37
59
// indexing embedded property
38
-
db.coll.createIndex({"name.firstName":-1})
60
+
db.coll.createIndex({"author.firstName":-1})
39
61
```
40
62
41
63
One query can use multiple single field indexes where available.
@@ -47,16 +69,16 @@ One query can use multiple single field indexes where available.
47
69
48
70
Compound indexes are required if your query needs the ability to **query or sort** data from two or more fields in each document in a collection.
49
71
50
-
The following command creates a compound index on the fields `name` and `age` in opposite sort order.
72
+
The following command creates a compound index on the fields `author` and `launchDate` in opposite sort order.
Compounded indexes on nested fields aren't supported by default due to limitations with arrays. If your nested field doesn't contain an array, the index works as intended. If your nested field contains an array (anywhere on the path), that value is ignored in the index.
@@ -65,33 +87,23 @@ As an example, a compound index containing `people.dylan.age` works in this case
Text indexes are special data structures that optimize text-based queries, making them faster and more efficient.
121
133
122
-
For simplicity, let us consider an example of a blog application with the following setup:
123
-
124
-
-**Database name**: `cosmicworks`
125
-
-**Collection name**: `products`
126
-
127
-
This example application stores articles as documents with the following structure.
128
-
129
-
```json
130
-
{
131
-
"_id": ObjectId("617a34e7a867530bff1b2346"),
132
-
"title": "Azure Cosmos DB - A Game Changer",
133
-
"content": "Azure Cosmos DB is a globally distributed, multi-model database service.",
134
-
"author": "John Doe",
135
-
"category": "Technology",
136
-
"published": true
137
-
}
138
-
```
139
-
140
134
Use the `createIndex` method with the `text` option to create a text index on the `title` field.
141
135
142
136
```javascript
@@ -198,7 +192,7 @@ db.products.find(
198
192
Index on single field, indexes all paths beneath the `field` , excluding other fields that are on the same level. For example, for the following sample document
0 commit comments