mongodb use _id field as shard key for time seires collection

Question

I've successfully created and deployed a self-managed MongoDB cluster that consists of 3 shards,1 router(mongos), and 1 config-server replica set, using this tutorial.

I want to create a shareded collection, with the next requirements:

1. documents should distribute evenly across all shards(in respect to total size, not docs count).
2. documents in this collection can contain any field, and the only field that is guaranteed to exists is the _id field.
3. the collection should be a time-series collection.
4. MongoDB version 5.0.9

What I tried :

1. It is ok to use the _id field exists in any doc in mongodb as your shard key for a sharded collection (not necessary time-series one)?
   I've tested it(because could not find answers online), configuring the the sharded collection with an hashed index created from the _id field:

sh.shardCollection("shardedDb.shardedCollection", { _id : "hashed" } 
)

and streamed a lot of dumy data.
for 4.5TB and 460 Millions records, the distribution was even and each of the 3 shard contained 1.5TB. Worked like charm. yet I need to ask, is it ok? why I don't see this solution proposed as quick solution anywhere else?

2. When dealing with time-series collections in MongoDB, you can only create indexes from the timeField and the metaField (this is true, for Mongo V5, in V6 there is no limitation, but I can't upgrade my cluster version). in other words, you cannot create index from _id. so I tried using my timeField as the key shard but the data was not distributed evenly across the shards.

so what can I do? I can I reliably choose a shard key on time series predection collection on MongoDB V5 that would distribute the docs across all shards in a sized-even way? I can not guarantee a specific field and I can not create index from _id field on Time-series collection...

Answer 1

In your case, it's OK to use _id as the sharding field, because there is no other field that exists in all documents.

The reason why _id is not recommended is that it will distribute documents way that you cannot predict where they go. So, when the client makes a query, that query must be sent to all shards, always. The idea of sharding is to make a situation where the query is sent to only one (or a few) shards at time.

That time field is problematic, because you cannot "hook" insert/update operation and add time field there. However, you have there insert time in the document. The first four bytes of your _id are timestamp of creating time of the document.