Performance of indexing quickly changing fields

[Calvin French-Owen]

Is there any significant performance downside to indexing fields which might change frequently? I plan on performing many updates to the documents in my collections, but not to the extent that they need to be resized (think mostly $inc and $set). However, I'm less sure about how the index referencing is actually implemented.

I plan to update things like stat counters, or the last isodate a user was seen on every request, and I'd like to query them efficiently as well. Alternatively, I could lower the granularity of the values for these fields, but I was hoping the B-tree structure would take care of that for me.

Thanks for the help!

[Scott Hernandez]

Index entries point to offsets in the database files, basically.
Everytime you update the value in a document for an indexed field you
must move the index entry while updating the document. The more
indexes you affect the more IO load and operations you will require on
your storage system.

It is basic btree updates when you change an indexed value.

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mongodb-user/-/5KsGt0pCjhQJ.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mongodb-user?hl=en.