Skip to content

Commit f4a5d75

Browse files
committed
edited bounds
1 parent 6e380bf commit f4a5d75

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

source/tutorial/inserting-documents-into-a-sharded-collection.txt

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -31,15 +31,15 @@ keys of the data being inserted aren't evenly distributed, you may need to pre-s
3131
data before doing high volume inserts. As an example, consider a collection sharded by last
3232
name with the following key distribution:
3333

34-
[-∞, "Henri")
34+
(-∞, "Henri")
3535
["Henri", "Peters")
3636
["Peters",+∞)
3737

3838
Although the chunk ranges may be split evenly, inserting lots of users with with a common
3939
last name such as "Smith" will potentially hammer a single shard. Making the chunk range
4040
more granular in this portion of the alphabet may improve write performance.
4141

42-
[-∞, "Henri")
42+
(-∞, "Henri")
4343
["Henri", "Peters")
4444
["Peters", "Smith"]
4545
["Smith", "Tyler"]
@@ -54,7 +54,7 @@ Documents with monotonically increasing shard keys, such as the BSON ObjectID, w
5454
be inserted into the last chunk in a collection. To illustrate why, consider a sharded
5555
collection with two chunks, the second of which has an unbounded upper limit.
5656

57-
[-∞, 100)
57+
(-∞, 100)
5858
[100,+∞)
5959

6060
If the data being inserted has an increasing key, at any given time writes will always hit
@@ -157,5 +157,5 @@ use a dedicated mongos for the export and the import.
157157

158158
https://jira.mongodb.org/browse/SERVER-4000
159159

160-
Incremental Inserts
161-
~~~~~~~~~~~~~~~~~~~
160+
Pre-allocating Documents
161+
~~~~~~~~~~~~~~~~~~~~~~~~

0 commit comments

Comments
 (0)