Database Reference
In-Depth Information
Using this shard key, or any hashed value as a key, presents the following downsides:
▪ The shard key, and the index on the key, will consume additional space in the database.
▪ Queries, unless they include the shard key itself, must run in parallel on all shards, which
may lead to degraded performance.
This might be an acceptable trade-off in some situations. The workload of event logging sys-
tems tends to be heavily skewed toward writing; read performance may not be as critical as
perfectly balanced write performance.
Option 3: Shard by an evenly distributed key in the data set
If a field in your documents has values that are evenly distributed among the documents, you
should strongly consider using this key as a shard key.
Continuing the previous example, you might consider using the path field. This has a couple
of advantages:
▪ Writes will tend to balance evenly among shards.
▪ Reads will tend to be selective and local to a single shard if the query selects on the path
field.
The biggest potential drawback to this approach is that all hits to a particular path must go
to the same chunk, and that chunk cannot be split by MongoDB, since all the documents in
it have the same shard key. This might not be a problem if you have fairly even load on your
website, but if one page gets a disproportionate number of hits, you can end up with a large
chunk that is completely unsplittable that causes an unbalanced load on one shard.
NOTE
Test using your existing data to ensure that the distribution is truly even, and that there is a
sufficient quantity of distinct values for the shard key.
Search WWH ::




Custom Search