I am struggling to understand why one would choose anything except a monolithic field as the shard key.
Initially as one starts to think about the pros of having a collection sharded you go: ‘wow amazing’. A decent example is provided in one of the lectures showing a case like lastnames.
Now at my place of work our existing databases are large tables of client information and a very common way of searching our DB is by email or name. Later on when we start to touch on targeted searches and you think back on a example like lastnames the takeaway is again: Great! additional improvements to real world issues for employees aka TIME.
But then we get a lecture explicitly stating that shard key values become immutable… It’s at this point my dream of amazingly fast database queries shattered. I’ll explain, currently in my real world example of our client database of about 200k records, there exists 0 fields that we could realistically make immutable. Names, Surnames, emails, tell numbers, addresses, countries, the list goes one, at some point in time these have required an some form of update, because of very obvious reasons. People move, get married, make spelling errors on sign up, get new phones etc. etc.
Thus, if I understood correctly, in the real world no optimal candidate for “shard key” would be viable and you will be forced to use something like a client ID or the likes that numerically increases and are unique. To avoid hotspotting it will be hashed and any hope of targeted searches will forever be lost.
If I misunderstood the entire point of shard keys in this manner, and anyone could provide clarity. It would be appreciated.