| 失效链接处理 |
|
MongoDB-Performance-Best-Practices PDF 下载
本站整理下载：
提取码：oy41
相关截图：
主要内容：
Test every query in your application with explain().
MongoDB provides an explain plan capability that shows
information about how a query will be, or was, resolved,
including:
• The number of documents returned
4
Figure 1: MongoDB Compass visual query plan for performance optimization across distributed clusters
• The number of documents read
• Which indexes were used
• Whether the query was covered, meaning no documents
needed to be read to return results
• Whether an in-memory sort was performed, which
indicates an index would be beneficial
• The number of index entries scanned
• How long the query took to resolve in milliseconds
(when using the executionStats mode)
• Which alternative query plans were rejected (when
using the allPlansExecution mode)
The explain plan will show 0 milliseconds if the query was
resolved in less than 1 ms, which is typical in well-tuned
systems. When the explain plan is called, prior cached
query plans are abandoned, and the process of testing
multiple indexes is repeated to ensure the best possible
plan is used. The query plan can be calculated and
returned without first having to run the query. This enables
DBAs to review which plan will be used to execute the
query, without having to wait for the query to run to
completion.
MongoDB Compass provides the ability to visualize explain
plans, presenting key information on how a query
performed – for example the number of documents
returned, execution time, index usage, and more. Each
stage of the execution pipeline is represented as a node in
a tree, making it simple to view explain plans from queries
distributed across multiple nodes.
Avoid scatter-gather queries. In sharded systems,
queries that cannot be routed to a single shard must be
broadcast to multiple shards for evaluation. Because these
queries involve multiple shards for each request they do
not scale well as more shards are added.
Choose the appropriate write guarantees. MongoDB
allows administrators to specify the level of persistence
guarantee when issuing writes to the database, which is
called the write concern. The following options can be
configured on a per connection, per database, per
5
collection, or even per operation basis. The options are as
follows:
• Write Acknowledged: This is the default write concern.
The mongod will confirm the execution of the write
operation, allowing the client to catch network, duplicate
key, Document Validation, and other exceptions.
• Journal Acknowledged: The mongod will confirm the
write operation only after it has flushed the operation to
the journal on the primary. This confirms that the write
operation can survive a mongod crash and ensures that
the write operation is durable on disk.
• Replica Acknowledged: It is also possible to wait for
acknowledgment of writes to other replica set members.
MongoDB supports writing to a specific number of
replicas. This also ensures that the write is written to the
journal on the secondaries. Because replicas can be
deployed across racks within data centers and across
multiple data centers, ensuring writes propagate to
additional replicas can provide extremely robust
durability. • Majority: This write concern waits for the write to be
applied to a majority of replica set members. This also
ensures that the write is recorded in the journal on
these replicas – including on the primary. • Data Center Awareness: Using tag sets, sophisticated
policies can be created to ensure data is written to
specific combinations of replicas prior to
acknowledgment of success. For example, you can
create a policy that requires writes to be written to at
least three data centers on two continents, or two
servers across two racks in a specific data center. For
more information see the MongoDB Documentation on
Data Center Awareness.
Only read from primaries unless you can tolerate
eventual consistency. Updates are typically replicated to
secondaries quickly, depending on network latency.
However, reads on the secondaries will not be consistent
with reads on the primary. Note that the secondaries are
not idle as they must process all writes replicated from the
primary. To increase read capacity in your operational
system consider sharding. Secondary reads can be useful
for analytics and ETL applications as this approach will
isolate traffic from operational workloads. You may choose
to read from secondaries if your application can tolerate
eventual consistency.
Choose the right read-concern. To ensure isolation and
consistency, the readConcern can be set to majority to
indicate that data should only be returned to the
application if it has been replicated to a majority of the
nodes in the replica set, and so cannot be rolled back in
the event of a failure.
MongoDB 3.4 adds a new readConcern level of
“Linearizable”. The linearizable read concern ensures that a
node is still the primary member of the replica set at the
time of the read, and that the data it returns will not be
rolled back if another node is subsequently elected as the
new primary member. Configuring this read concern level
can have a significant impact on latency, therefore a
maxTimeMS value should be supplied in order to timeout
long running operations.
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
