0

I'm using AWS DocumentDB with MongoDB 4.0 compatibility, so I'm using MongoDB on a docker container (single instance, not a cluster) for localhost development and AWS DocumentDB (cluster) for production. In some part of application I need to do a bulk upsert and noticed a behavior difference.

My document has an index called CrossId that is used to search the document and upsert. Running on MongoDB (docker container) the index is used and the upsert is very fast. As we can see in the print, for each upsert the index is used.

enter image description here

On the other hand, when running in AWS DocumentDB (cluster), the index insn't used. Because of this, the upsert is very slow.

enter image description here

This is my code in C#. I need to update more properties, but it can be used as example:

public async Task CreateOrUpdateCustomersAsync(IEnumerable<CustomerModel> customers, CancellationToken cancellationToken)
{
    var updateModels = new List<UpdateOneModel<CustomerModel>>();

    foreach (var customer in customers)
    {
        var filter = Builders<CustomerModel>.Filter
            .Eq(x => x.CrossId, customer.CrossId);
            
        var updateDefinition = Builders<CustomerModel>.Update
            .Set(x => x.CrossId, customer.CrossId)
            .Set(x => x.Phone, customer.Phone);
            
        var updateModel = new UpdateOneModel<CustomerModel>(filter, updateDefinition);
        updateModel.IsUpsert = true;

        updateModels.Add(updateModel);
    }

    await _customersCollection.BulkWriteAsync(updateModels, options: _bulkWriteOptions, cancellationToken);
}

I believe that the right behavior should be use the index to search the document before de update/insert. How to make the process behave the same in both services?

I tried several alternatives and nothing worked. Running the upsert via CLI in DocumentDB had the same behavior.

  • Maybe hint the index specifically in the update query. The query planner in DocumentDB behaves differently than MongoDB. – Mihai A Jul 05 '23 at 13:48

0 Answers0