{
"_id" : "test.users-username_\"user114978\"age_119.0",
"min" : {
"username" : "user114978",
"age" : 119
},
"max" : {
"username" : "user122468",
"age" : 68
}
}
Thus, mongos can easily find on which chunk someone with a given username (or a
given username and age) lives. However, given just an age, mongos would have to check
all, or almost all, chunks. If we wanted to be able to target queries on age to the right
chunk, we’d have to use the “opposite” shard key: {"age" : 1, "username" : 1}. This
is often a point of confusion: a range over the second half of a shard key will cut across
multiple chunks.
Splitting Chunks
mongos tracks how much data it inserts per chunk and, once that reaches a certain
threshold, checks if the chunk needs to be split, as shown in Figure 14-1 and
Figure 14-2. If the chunk does need to be split, mongos will update the chunk’s metadata
on the config servers. Chunk splits are just a metadata change (no data is moved). New
chunk documents are created on the config servers and the old chunk’s range ("max")
is modified. Once that process is complete, the mongos resets its tracking for the original
chunk and creates new trackers for the new chunks.
When mongos asks a shard if a chunk needs to be split, the shard makes a rough calcu‐
lation of the chunk size. If it finds that the chunk is getting large, it finds split points and
sends those to the mongos (as shown in Figure 14-3).
A shard may not be able to find any split points though, even for a large chunk, as there
are a limited number of ways to legally split a chunk. Any two documents with the same
shard key must live in the same chunk so chunks can only be split between documents
where the shard key’s value changes. For example, if the shard key was "age", the fol‐
lowing chunk could be split at the points where the shard key changed, as indicated:
{"age" : 13, "username" : "ian"}
{"age" : 13, "username" : "randolph"}
------------ // split point
{"age" : 14, "username" : "randolph"}
{"age" : 14, "username" : "eric"}
{"age" : 14, "username" : "hari"}
{"age" : 14, "username" : "mathias"}
------------ // split point
How MongoDB Tracks Cluster Data | 249
Append pdf files reader - Merge, append PDF files in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Provide C# Demo Codes for Merging and Appending PDF Document
best pdf merger; pdf mail merge
Append pdf files reader - VB.NET PDF File Merge Library: Merge, append PDF files in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
VB.NET Guide and Sample Codes to Merge PDF Documents in .NET Project
pdf merger online; pdf split and merge
{"age" : 15, "username" : "greg"}
{"age" : 15, "username" : "andrew"}
mongos will not necessarily split a chunk at every split point available, but those are the
possibilities it has to choose from.
For example, if the chunk contained the following documents, it could not be split
(unless the application started inserting fractional ages):
{"age" : 12, "username" : "kevin"}
{"age" : 12, "username" : "spencer"}
{"age" : 12, "username" : "alberto"}
{"age" : 12, "username" : "tad"}
Thus, having a variety of values for your shard key is important. Other important prop‐
erties will be covered in the next chapter.
If one of the config servers is down when a mongos tries to do a split, the mongos won’t
be able to update the metadata (as shown in Figure 14-4). All config servers must be up
and reachable for splits to happen. If the mongos continues to receive write requests for
the chunk, it will keep trying to split the chunk and fail. As long as the config servers
are not healthy, splits will continue not to work and all the split attempts can slow down
the mongos and shard involved (which repeats the process shown in Figure 14-1 through
Figure 14-4 for each incoming write). This process of mongos repeatedly attempting to
split a chunk and being unable to is called a split storm. The only way to prevent split
storms is to ensure that your config servers are up and healthy as much of the time as
possible. You can also restart a mongos to reset its write counter (so that it is no longer
at the split threshold).
Figure 14-1. When a client writes to a chunk, mongos will check its split threshold for
the chunk
250 | Chapter 14: Configuring Sharding
.NET PDF SDK | Read & Processing PDF files
editing and clean-up features provided by this .NET Imaging PDF Reader Add-on Simple to convert PDF files to raster images (color or grayscale) in .NET Imaging
pdf combine files online; combine pdf files
C# TIFF: C#.NET Code to Merge and Append TIFF Files
Merge and Append Tiff Files. How to Merge and Append TIFF Files in C# by Using RasterEdge XDoc.Tiff for .NET SDK. Merge and Append TIFF Files in C#.NET Overview.
reader merge pdf; batch pdf merger
Figure 14-2. If the split threshold has been reached, mongos will send a request for split
points to the shard
Figure 14-3. The shard calculates split points for the chunk and sends them to the
mongos
Figure 14-4. The mongos chooses a split point and attempts to inform the config server
but cannot reach it. Thus, it is still over its split threshold for the chunk and any subse‐
quent writes will trigger this process again.
Another issue is that mongos might never realize that it needs to split a large chunk.
There is no global counter of how big each chunk is. Each mongos simply calculates
How MongoDB Tracks Cluster Data | 251
VB.NET PDF Convert to HTML SDK: Convert PDF to html files in vb.
' Convert PDF file to HTML5 files DocumentConverter.ConvertToHtml5("..\1.pdf", "..output\", RelativeType.SVG). Copyright © <2000-2016> by <RasterEdge.com>.
adding pdf pages together; c# merge pdf pages
C# PDF Convert to HTML SDK: Convert PDF to html files in C#.net
How to Use C#.NET Demo Code to Convert PDF Document to HTML5 Files in C#.NET Class. Add necessary references: RasterEdge.Imaging.Basic.dll.
split pdf into multiple files; c# combine pdf
whether the writes it has received have reached a certain threshold (as shown in
Figure 14-5). This means that if your mongos processes go up and down frequently a
mongos might never receive enough writes to hit the split threshold before it is shut
down again and your chunks will get larger and larger (as shown in Figure 14-6).
Figure 14-5. As mongos processes perform writes, their counters increase toward the
split threshold
252 | Chapter 14: Configuring Sharding
C# PDF File Split Library: Split, seperate PDF into multiple files
Also able to combine generated split PDF document files with other PDF files to form a new PDF file. Split PDF Document into Multiple PDF Files in C#.
c# pdf merge; combine pdf online
VB.NET PDF File Split Library: Split, seperate PDF into multiple
splitter control provides VB.NET developers an easy to use solution that they can split target multi-page PDF document file to one-page PDF files or they can
add multiple pdf files into one online; how to combine pdf files
Figure 14-6. If mongos processes are regularly restarted their counters may never hit the
threshold, making chunks grow without bound
The first way to prevent this is to have fewer mongos churn. Leave mongos processes up,
when possible, instead of spinning them up when they are needed and then turning
them off when they are not. However, some deployments may find it too expensive to
run mongos processes that aren’t being used. If you are in this situation, another way of
getting more splits is to make the chunk size smaller than you actually want it to be.
This will prompt splits to happen at a lower threshold.
You can turn off chunk splitting by starting every mongos with --nosplit.
The Balancer
The balancer is responsible for migrating data. It regularly checks for imbalances be‐
tween shards and, if it finds an imbalance, will begin migrating chunks. Although the
balancer is often referred to as a single entity, each mongos plays the part of “the balancer”
occasionally.
The Balancer | 253
C# PDF Convert to SVG SDK: Convert PDF to SVG files in C#.net, ASP
file using C#. Instantly convert all PDF document pages to SVG image files in C#.NET class application. Perform high-fidelity PDF
pdf merge; add pdf pages together
VB.NET PDF Convert to SVG SDK: Convert PDF to SVG files in vb.net
Barcoding. XImage.Barcode Reader. XImage.Barcode Generator. Others. Images. File & Page Process. File: Merge, Append PDF Files. File: Split PDF Document.
attach pdf to mail merge in word; append pdf
Every few seconds, a mongos will attempt to become the balancer. If there are no other
balancers active, the mongos will take a cluster-wide lock from the config servers and
do a balancing round. Balancing doesn’t affect a mongos’s normal routing operations,
so clients using that mongos should be unaffected.
You can see which mongos is the balancer by looking at the the config.locks collection:
> db.locks.findOne({"_id" : "balancer"})
{
"_id" : "balancer",
"process" : "router-23:27017:1355763351:1804289383",
"state" : 0,
"ts" : ObjectId("50cf939c051fcdb8139fc72c"),
"when" : ISODate("2012-12-17T21:50:20.023Z"),
"who" : "router-23:27017:1355763351:1804289383:Balancer:846930886",
"why" : "doing balance round"
}
The config.locks collection keeps track of all cluster-wide locks. The balancer is the
document with the "_id" of "balancer". The lock’s "who" field tells you which mon
gos is—or was—balancing: router-23:27017 in this case. The "state" field indicates
whether the balancer is running; 0 means it is no longer active, 2 means it’s still balancing.
(1 means that the mongos is attempting to take the lock but has not yet acquired it—
you won’t usually see 1.)
Once a mongos has become the balancer, it checks its table of chunks for each collection
to see if any shards have hit the balancing threshold. This is when one shard has signif‐
icantly more chunks than the other shards (the exact threshold varies: larger collections
tolerate larger imbalances than smaller ones). If an imbalance is detected, the balancer
will redistribute chunks until all shards are within one chunk of one another. If no
collections have hit the balancing threshold. The mongos stops being the balancer.
Assuming that some collections have hit the threshold, the balancer will begin migrating
chunks. It chooses a chunk from the overloaded shard and asks the shard if it should
split the chunk before migrating. Once it does any necessary splits, it migrates the chunk
to a machine with fewer chunks.
An application using the cluster does not need be aware that the data is moving: all reads
and writes are routed to the old chunk until the move is complete. Once the metadata
is updated, all mongos processes attempting to access the data in the old location will
get an error. These errors should not be visible to the client: the mongos will silently
handle the error and retry the operation on the new shard.
This is a common cause of errors you might see in mongos logs that are about being
“unable to setShardVersion.” When mongos gets this type of error, it looks up the new
location of the data from the config servers, updates its chunk table, and attempts the
request again. If it successfully retrieves the data from the new location, it will return it
254 | Chapter 14: Configuring Sharding
to the client as though nothing went wrong (but it will print a message in the log that
the error occurred).
If the mongos is unable to retrieve the new chunk location because the config servers
are unavailable, it will return an error to the client. This is another reason why it is
important to always have config servers up and healthy.
The Balancer | 255
CHAPTER 15
Choosing a Shard Key
The most important and difficult task when using sharding is choosing how your data
will be distributed. To make intelligent choices about this, you have to understand how
MongoDB distributes data. This chapter helps you make a good choice of shard key by
covering:
• How to decide among multiple possible shard keys
• Shard keys for several use cases
• What you can’t use as a shard key
• Some alternative strategies if you want to customize how data is distributed
• How to manually shard your data
This chapter assumes that you understand the basic components of sharding as covered
in the previous chapters.
Taking Stock of Your Usage
When you shard a collection you choose a field or two to use to split up the data. This
key (or keys) is called a shard key. Once you have more than a few shards, it’s almost
impossible to change your shard key, so it is important to choose correctly (or at least
notice any issues quickly).
To choose a good shard key, you need to understand your workload and how your shard
key is going to distribute your application’s requests. This can be difficult to picture, so
try to work out some examples or, even better, try it out on a backup data set with sample
traffic. This section has lots of diagrams and explanations, but there is no substitute for
trying it on your own data set.
257
For each collection that you’re planning to shard, start by answering the following
questions:
• How many shards are you planning to grow to? A three-shard cluster has a great
deal more flexibility than a thousand-shard cluster. As a cluster gets larger, you
should not plan to fire off queries that can hit all shards, so almost all queries must
include the shard key.
• Are you sharding to decrease read or write latency? (Latency refers to how long
something takes, e.g., a write takes 20 ms, but we need it to take 10 ms.) Decreasing
write latency usually involves sending requests to geographically closer or more
powerful machines.
• Are you sharding to increase read or write throughput? (Throughput refers to how
many requests the cluster can handle at the same time: the cluster can do 1,000
writes in 20 ms, but we need it to do 5,000 writes in 20 ms.) Increasing throughput
usually involves adding more parallelization and making sure that requests are dis‐
tributed evenly across the cluster.
• Are you sharding to increase system resources (e.g., give MongoDB more RAM per
GB of data)? If so, you want to keep working set size as small possible.
Use these answers to evaluate the following shard key descriptions and decide whether
the shard key you choose would work well in your situation. Does it give you the targeted
queries that you need? Does it change the throughput or latency of your system in the
ways you need? If you need a compact working set, does it provide that?
Picturing Distributions
There are three basic distributions that are the most common ways people choose to
split their data: ascending key, random, and location-based. There are other types of
keys that could be used, but most use cases fall into one of these categories. Each is
discussed in the following sections.
Ascending Shard Keys
Ascending shard keys are generally something like a "date" field or ObjectId—any‐
thing that steadily increases over time. An autoincrementing primary key is another
example of an ascending field, albeit one that doesn’t show up in MongoDB much (unless
you’re importing from another database).
Suppose that we shard on an ascending field, like "_id" on a collection using ObjectIds.
If we shard on "_id", then this will be split into chunks of "_id" ranges, as in
Figure 15-1. These chunks will be distributed across our sharded cluster of, let’s say,
three shards, as shown in Figure 15-2.
258 | Chapter 15: Choosing a Shard Key
Documents you may be interested
Documents you may be interested