This may be more an advice than anything else, but I'm designing an app that stores in a table objects that have a 2dsphere index and they also have a date (+time), both of them being part of queries that I'm doing to retrieve some of these objects.

This database will have to be sharded, so sharding according to the spatial key sounds like the first step. It's basically a given that this index will be part of the sharded key. The other key should be time, and I'm pretty sure that hashing the time will not be adequate, as the queries are looking for date interval for the objects. So hashed will make force accessing all chunks (with the proper spatial constraints), which I don't want.

So my question is to know if this is feasible and also if mongodb will be clever enough not to split according to the spatial key unless I manually ask for it?


my question is to know if this is feasible

A shard key index cannot be multi key, text, or geospatial, so part of your theoretical approach is definitely infeasible. You also mention considering hashed sharding on a datetime field, which could provide better data distribution for otherwise monotonically increasing values like a timestamp. However, a tradeoff is that hashed sharding does not support range queries since adjacent source values will now have distributed shard key values.

also if mongodb will be clever enough not to split according to the spatial key unless I manually ask for it?

Since a shard key cannot be an array or geospatial value this specific question doesn't really apply.

The default behaviour of MongoDB sharding is to allow shard key range splits (aka "chunk splits") to happen automatically so that the sharded cluster balancer will redistribute data between shards based on chunk imbalances. It is possible to adjust the default behaviour (for example, disabling autosplits for a cluster or balancing for a collection), but you should only do this with careful consideration. Micromanaging a sharded cluster can be counter-productive.

| improve this answer | |
  • That's a big bummer, I didn't notice this problem, which means that you can split a database in datacenters based on their location, which means that I don't see the point on having multi-region shared databases. Anyway, that's another question! I guess, I will shard according to date only, as anything else will have other drawbacks! – Matthieu Brucher Jul 24 '19 at 13:59
  • Utter madness, you need to specify a custom text entry for this! docs.mongodb.com/manual/tutorial/… But then, a geospatial request would never go through this key, meaning that it's useless to shard this way for me. – Matthieu Brucher Jul 24 '19 at 14:56
  • You can distribute a sharded database geographically and potentially use Zone Sharding to control the location of data based on shard key ranges, but as you note this won't help to target geospatial queries. As an example of geo sharding, MongoDB Atlas Global Clusters use a compound shard key including a coarse location (ISO country code) and custom secondary field to support common search queries. – Stennie Jul 24 '19 at 20:53
  • @MatthieuBrucher Perhaps you could post a question describing your use case in more detail (with some example documents and queries) as there may be a better approach or schema to consider. Geo coordinates aren't suitable for naive range sharding as adjacent coordinates in numerical value aren't necessarily near using geospatial search contexts like distance. This article includes some helpful background on how MongoDB's $geoNear search works: Geospatial Performance Improvements in MongoDB 3.2. – Stennie Jul 24 '19 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.