I've decided to shard a collection with 500M+ documents into 24 shards. All shards are on the same machine without replicas as was advised in this title (core sharding). The shard key is {"_id":1}. I encountered, that chunk migration is extremely slow. It have been processing 2 days and progress is about 30%. I tried to move chunks manually. I stopped the balancer and executed commands from this title But it seems to me that nothing happened. I started the balancer again and it continue to migrate chunks in the same way. Is there any method to make it faster?
1
-
First, I think you have misunderstood the intention of the MongoHQ article - they are talking about how they scale for multi-tenant hosting of MongoDB, not for scaling out generally with a data set - you should have replica sets. Second, unless you are using a custom _id field it is usually a bad choice for a shard key. Third, you should probably have looked at pre-splitting your data to avoid the migrations you are now doing. Finally, 24 shards is probably too many, unless you have very large documents. You don't need to speed up balancing, you need to rethink your whole approach.– Adam CCommented Jun 6, 2014 at 19:37
Add a comment
|
1 Answer
Math first: you moved 150M documents in 2 days, which is roughly 860 documents per second including metadata and indices, where reading and writing all occurs on the same machine. That is not what I would call slow. The description coming to my mind is "lightning fast". ;)
Since there is no real distribution of the write load, an easy way to speed things up is to add two or more machines.
A few notes: sharding production data on non-replica shards is dangerous, to say the least. If one of the shards fails, the data contained is permanently unavailable until you get the shard up and running again. Plus, since there was no server to write to for a specific key range, values of that range can not be written. If the shard was a replica set, the failure would lead to the election of a new primary, to which all writes and (depending on the configuration) most or even all reads would go.
_id can be used as a shard key, however it should be hashed.
answered Jun 25, 2014 at 17:05
-
Thanks, Markus. It's not in production yet, we just play :-) Yes, we've tried two shards on two machines and really speeded up data access. Our _id isn't a standard ObjectId — it's our own _id where first bytes is analogue of user and last bytes is time of user's actions. Commented Jun 25, 2014 at 21:08
-
Which is still monotonocally increasing, which is a bad idea. Have a look at the shard key docs. Commented Jun 25, 2014 at 23:11
-
It does not monotonically increasing, I think. User's ID is stored in first bytes of _id, as I mentioned above, so near documents almost never have the same first part. Am I right that it's not a monotonically increasing? Commented Jun 26, 2014 at 12:30
-
Even if the first part is a user id, here is what happens: if there are consecutive actions for a user, they will all be written to the same shard, as most likely the key range for a specific user will not span shards. And the question is how the user id is created. It may well be that even the userid is monotonically increasing. Commented Aug 31, 2014 at 5:48
-
What's wrong with situation, when all user actions is written to the same shard? There are a lot of other users, who act at the same time, so I think load is distributed uniformly. Furthermore all read requests for user actions will be on the same shard. It's good, isn't it? Commented Sep 16, 2014 at 12:10