Update how-to-create-indexes.md

Author: abinav2307

articles/cosmos-db/mongodb/vcore/how-to-create-indexes.md

@@ -16,29 +16,29 @@ ms.date: 6/24/2024
 [!INCLUDE[MongoDB vCore](~/reusable-content/ce-skilling/azure/includes/cosmos-db/includes/appliesto-mongodb-vcore.md)]
 
 ## Queryable fields should always have indexes created
-Read operations based on predicates and aggregates will first consult the index for the corresponding filters. In the absence of indexes, the database engine will perform a document scan to retrieve the matching documents. Scans will always be expensive and will get progressively more expensive as the volume of data in a collection continues to grow. For optimal queri performance, indexes should always be created for all queryable fields.
+Read operations based on predicates and aggregates consult the index for the corresponding filters. In the absence of indexes, the database engine performs a document scan to retrieve the matching documents. Scans are always expensive and get progressively more expensive as the volume of data in a collection grows. For optimal queri performance, indexes should always be created for all queryable fields.
 
 ## Avoid unnecessary indexes and indexing all fields by default
-While indexes should be created for all queryable fields, other fields within the document structure in a collection should not be indexed (either individually or through wildcard indexing) if they are not going to be part of query predicates or filters.
+While indexes should be created for all queryable fields, other fields within the document structure in a collection should not be indexed (either individually or through wildcard indexing) if they are not part of query predicates or filters.
 
 > [!TIP]
-> Azure Cosmos DB for MongoDB vCore only indexes the _id field by default. All other fields are not indexed by default. The fields to be indexed should be planned ahead of time to maximize query performance while minimizing impact on write throughput from indexing too many fields.
+> Azure Cosmos DB for MongoDB vCore only indexes the _id field by default. All other fields are not indexed by default. The fields to be indexed should be planned ahead of time to maximize query performance, while minimizing impact on writes from indexing too many fields.
 
-When a new document is inserted for the first time or an existing document is updated or deleted, each of the specified fields in the index also needs to be updated. If the indexing policy contains a large number of fields (or all the fields in the document), additional resources will be consumed by the server in updating the corresponding indexes. When running at scale, only the queryable fields should be indexed while all other fields not used in query predicates should be excluded from the index. 
+When a new document is inserted for the first time or an existing document is updated or deleted, each of the specified fields in the index is also updated. If the indexing policy contains a large number of fields (or all the fields in the document), additional resources are consumed by the server in updating the corresponding indexes. When running at scale, only the queryable fields should be indexed while all remaining fields not used in query predicates should remain excluded from the index. 
 
 ## Create the necessary indexes prior to data ingestion
-For optimal performance, indexes should be created upfront before data is loaded. This ensures all documents that are inserted for the first time or subsequently updated or deleted will have the corresponding indexes updated synchronously as part of the write operation. If indexes are created after data has been ingested, additional server resources will be consumed to index historical data. Depending on the size of the historical data, this can be time consuming and could impact steady state read and write performance.
+For optimal performance, indexes should be created upfront before data is loaded. This ensures all documents inserted for the first time or subsequently updated or deleted will have corresponding indexes updated synchronously. If indexes are created after data is ingested, additional server resources are consumed to index historical data. Depending on the size of the historical data, this operation is time consuming and impacts steady state read and write performance.
 
 > [!NOTE]
-For scenarios where indexes need to be added at a later time due to changes in read patterns, background indexing needs to be enabled on the cluster which can be done through a support ticket.
+For scenarios where read patterns change and indexes need to be added, background indexing should be enabled, which can be done through a support ticket.
 
 ## For multiple indexes created on historical data, issue non-blocking createIndex commands for each field
 It is not always possible to plan for all query patterns upfront, particularly as application requirements evolve. Changing business and application needs will inevitably require fields to be added to the index on a cluster with a large amount of historical data. 
 
 In such scenarios, each createIndex command should be issued asynchronously without waiting on a response from the server.
 
 > [!NOTE]
-By default, Azure Cosmos DB for MongoDB vCore responds to a createIndex operation only after the index has been fully built on the historical data. Depending on the size of the cluster and the volume of data already ingested, this can take time and may appear as though the server is not responding to the createIndex command. 
+By default, Azure Cosmos DB for MongoDB vCore responds to a createIndex operation only after the index is fully built on historical data. Depending on the size of the cluster and the volume of data ingested, this can take time and appear as though the server is not responding to the createIndex command. 
 
 If the createIndex commands are being issued through the Mongo Shell, use Ctrl + C to interrupt the command to stop waiting on a response and issue the next set of operations.