-
Notifications
You must be signed in to change notification settings - Fork 1.7k
/
shard-gridfs-data.txt
64 lines (45 loc) · 2 KB
/
shard-gridfs-data.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
=======================
Shard GridFS Data Store
=======================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
When sharding a :term:`GridFS` store, consider the following:
``files`` Collection
--------------------
Most deployments will not need to shard the ``files``
collection. The ``files`` collection is typically small, and only
contains metadata. None of the required keys for GridFS lend
themselves to an even distribution in a sharded situation. If you
*must* shard the ``files`` collection, use the ``_id`` field
possibly in combination with an application field.
Leaving ``files`` unsharded means that all the file metadata
documents live on one shard. For production GridFS stores you *must*
store the ``files`` collection on a replica set.
``chunks`` Collection
---------------------
To shard the ``chunks`` collection by ``{ files_id : 1 , n : 1 }``,
issue commands similar to the following:
.. code-block:: javascript
db.fs.chunks.ensureIndex( { files_id : 1 , n : 1 } )
db.runCommand( { shardCollection : "test.fs.chunks" , key : { files_id : 1 , n : 1 } } )
You may also want to shard using just the ``file_id`` field, as in
the following operation:
.. code-block:: javascript
db.runCommand( { shardCollection : "test.fs.chunks" , key : { files_id : 1 } } )
.. important:: ``{ files_id : 1 , n : 1 }`` and ``{ files_id : 1 }``
are the **only** supported shard keys for the ``chunks`` collection
of a GridFS store.
.. note::
.. versionchanged:: 2.2
Before 2.2, you had to create an additional index on ``files_id``
to shard using *only* this field.
The default ``files_id`` value is an :term:`ObjectId`, as a result
the values of ``files_id`` are always ascending, and applications
will insert all new GridFS data to a single chunk and shard. If
your write load is too high for a single server to handle, consider
a different shard key or use a different value
for ``_id`` in the ``files`` collection.