Field names - Field names are part of each JSON/BSON documents so in this case to reduce the amount of data sent and stored, you may want to use user and team rather than username and teamnumber.
Interesting. That’s good to know.
The field hash - If the hash field is only present to be able to use an hash shard key, you could remove it and let the system hash user and team. Like I mentioned earlier, I think you incur the cost of computing the hash even if you supply a field that is a hash value.
How is hashing user and team together accomplished? I thought that a command like
db.collection.createIndex( { "userName" : "hashed", "teamNumber" : 1 } )
hashes only on userName and leaves teamNumber unhashed. How can I create a hash based on userName+teamNumber?
Day to day use-cases - Loading the data in the system is one use-case. Before throwing out your shard setup you should consider your day to day use-cases, which are probably more important to optimize. Would your typical queries better served on a monolithic server or shard server? This shard key also has impact on you day to day use-cases. With a hash shard key you end with most queries being a scatter/gather.
The day to day operation of this collection is a daily add of a single batch of 2.3 million additional documents, with constant end-user read query requests being performed throughout the day. The most common query will be SELECT * FROM collection WHERE userName=? AND teamNumber=? ORDER BY stamp
So a hash key on username, teamnumber will ensure that the most common query by far will be accessing specific data located on a single shard.