Hashed indexes within non-sharded collections infer a performance penalty?

[eddy_turbox (Edgar H)]

Morning everyone,

Been recently playing around with MongoDB and its indexes within a sharded environment. Taking this into account I wanted to make some tests within my local DB and see how writes are affected by indexes.

I’ve got a collection with 2 indexes, one is used for the reading side of things and the other one was used in the sharded cluster.

Having a hashed index which was used for sharding in a single cluster environment infers a penalty when writing or any other kind of issue, should I remove it? It’s not an unused index, that’s for sure!

[Stennie]

Welcome to the community @eddy_turbox,

@eddy_turbox

Having a hashed index which was used for sharding in a single cluster environment infers a penalty when writing or any other kind of issue, should I remove it? It’s not an unused index, that’s for sure!

A hashed index will still be considered by the query planner for equality queries so may not be entirely unused, but if you already have an index on this field (for example, _id ) the additional index will not have any performance benefit.

In general you should remove unnecessary indexes to free up system resources (extra storage and RAM consumed). Assuming you are using the default WiredTiger storage engine, indexes only add write overhead when the value of the indexed field is added or modified.

Regards,
Stennie