/
distributed-queries.txt
94 lines (68 loc) · 3.21 KB
/
distributed-queries.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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
.. index:: read operation; architecture
.. _read-operations-architecture:
===================
Distributed Queries
===================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
.. might make sense to break this in half and move it to
replication/sharding and cross reference here?
Read Operations to Sharded Clusters
-----------------------------------
:term:`Sharded clusters <sharded cluster>` allow you to partition a data
set among a cluster of :binary:`~bin.mongod` instances in a way that is
nearly transparent to the application. For an overview of sharded
clusters, see the :doc:`/sharding` section of this manual.
For a sharded cluster, applications issue operations to one of the
:binary:`~bin.mongos` instances associated with the cluster.
.. include:: /images/sharded-cluster.rst
Read operations on sharded clusters are most efficient when directed to
a specific shard. Queries to sharded collections should include the
collection's :ref:`shard key <sharding-shard-key>`. When a query
includes a shard key, the :binary:`~bin.mongos` can use cluster metadata
from the :ref:`config database <sharding-config-server>` to route the
queries to shards.
.. include:: /images/sharded-cluster-targeted-query.rst
If a query does not include the shard key, the :binary:`~bin.mongos` must
direct the query to *all* shards in the cluster. These *scatter
gather* queries can be inefficient. On larger clusters, scatter gather
queries are unfeasible for routine operations.
.. include:: /images/sharded-cluster-scatter-gather-query.rst
For more information on read operations in sharded clusters, see the
:doc:`/core/sharded-cluster-query-router` and :ref:`sharding-shard-key`
sections.
.. index:: read operation; connection pooling
.. index:: connection pooling; read operations
.. _read-operations-connection-pooling:
Read Operations to Replica Sets
-------------------------------
:term:`Replica sets <replica set>` use :term:`read preferences <read
preference>` to determine where and how to route read operations to
members of the replica set. By default, MongoDB always reads data from
a replica set's :term:`primary`. You can modify that behavior by
changing the :ref:`read preference mode
<replica-set-read-preference-modes>`.
You can configure the :ref:`read preference mode
<replica-set-read-preference-modes>` on a per-connection or
per-operation basis to allow reads from :term:`secondaries
<secondary>` to:
- reduce latency in multi-data-center deployments,
- improve read throughput by distributing high read-volumes (relative
to write volume),
- for backup operations, and/or
- to allow reads during :ref:`failover <replica-set-failover>`
situations.
.. include:: /images/replica-set-read-preference.rst
Read operations from secondary members of replica sets are not
guaranteed to reflect the current state of the primary, and the state
of secondaries trails the primary by some amount of time.
[#edge-cases-2-primaries]_
For more information on read preference or on the read preference
modes, see :doc:`/core/read-preference` and
:ref:`replica-set-read-preference-modes`.
.. [#edge-cases-2-primaries]
.. include:: /includes/footnote-two-primaries-edge-cases.rst