Tuning consistency vs performance in MongoDB - Interactive Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to set the read concern level to 'majority' for stronger consistency.

MongoDB

db.collection.find().readConcern('[1]')

Drag options to blanks, or click blank then click option'

Amajority

Blinearizable

Cavailable

Dlocal

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'local' which reads from the primary only and may not be fully consistent.

Using 'available' which is weaker consistency.

Setting readConcern to 'majority' ensures the query reads data acknowledged by a majority of nodes, improving consistency.

2fill in blank

medium

Complete the code to set the write concern to acknowledge writes by 3 nodes.

MongoDB

db.collection.insertOne(doc, { writeConcern: { w: [1] } })

Drag options to blanks, or click blank then click option'

A1

Bmajority

C3

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using w: 1 which only waits for primary acknowledgment.

Using w: 0 which does not wait for any acknowledgment.

Setting writeConcern w to 3 means the write must be acknowledged by 3 nodes, increasing durability but possibly reducing performance.

3fill in blank

hard

Fix the error in the code to set read preference to nearest for better performance.

MongoDB

db.collection.find().readPreference('[1]')

Drag options to blanks, or click blank then click option'

AprimaryPreferred

Bprimary

CsecondaryPreferred

Dnearest

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'primary' which always reads from the primary node, possibly slower.

Using 'secondaryPreferred' which prefers secondary but falls back to primary.

Using 'nearest' read preference allows reading from the closest node, improving read performance but possibly reducing consistency.

4fill in blank

hard

Fill both blanks to set a transaction with read concern 'snapshot' and write concern 'majority'.

MongoDB

session.startTransaction({ readConcern: { level: '[1]' }, writeConcern: { w: '[2]' } })

Drag options to blanks, or click blank then click option'

Asnapshot

Blocal

Cmajority

Dlinearizable

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'local' read concern which is weaker for transactions.

Using write concern less than 'majority' which risks data loss.

Transactions use 'snapshot' read concern for consistent reads and 'majority' write concern for durability.

5fill in blank

hard

Fill both blanks to create a read operation with read preference 'secondary', read concern 'local'.

MongoDB

db.collection.find().readPreference('[1]').readConcern('[2]')

Drag options to blanks, or click blank then click option'

Aprimary

Bsecondary

Clocal

D1

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'primary' read preference which reads only from primary.

Using read concern 'majority' which provides stronger consistency but may impact performance.

This configuration reads from secondary nodes with local consistency.

Practice

1. What does the readConcern option control in MongoDB?

easy

A. The number of indexes on a collection

B. The speed of write operations

C. The size of the database

D. The freshness of data returned by read operations

Solution

1. Step 1: Understand the role of readConcern

   readConcern controls how up-to-date or fresh the data returned by a read operation is.

2. Step 2: Differentiate from other concerns

   It does not affect write speed, database size, or indexes, which are unrelated to data freshness.

3. Final Answer:

   The freshness of data returned by read operations -> Option D

4. Quick Check:

   readConcern = data freshness [OK]

Hint: readConcern controls data freshness on reads [OK]

Common Mistakes:

• Confusing readConcern with writeConcern
• Thinking it controls write speed
• Assuming it changes database size

2. Which of the following is the correct way to specify a writeConcern for majority acknowledgement in a MongoDB write operation?

easy

A. { writeConcern: { w: 0 } }

B. { writeConcern: { w: 1 } }

C. { writeConcern: { w: 'majority' } }

D. { writeConcern: { w: 'none' } }

Solution

1. Step 1: Recall the syntax for majority writeConcern

   To require acknowledgement from the majority of replica set members, use w: 'majority'.

2. Step 2: Check other options

   w: 1 means acknowledgement from primary only, w: 0 means no acknowledgement, and w: 'none' is invalid.

3. Final Answer:

   { writeConcern: { w: 'majority' } } -> Option C

4. Quick Check:

   writeConcern majority = w: 'majority' [OK]

Hint: Use w: 'majority' for majority writeConcern [OK]

Common Mistakes:

• Using numeric 1 instead of 'majority'
• Setting w to 0 expecting acknowledgement
• Using invalid string 'none'

3. Given the following MongoDB read operation with readConcern: 'local', what can you expect about the data freshness?

db.collection.find({}, { readConcern: { level: 'local' } })

medium

A. Data may be stale and not reflect the latest writes

B. Data is guaranteed to be the most recent committed data

C. Data is read from a secondary only

D. Data is read with majority acknowledgement

Solution

1. Step 1: Understand 'local' readConcern level

   The 'local' level returns the data from the node without waiting for replication or majority acknowledgement, so it may be stale.

2. Step 2: Compare with other levels

   'majority' ensures fresh data, reading from secondary is controlled by read preference, not readConcern.

3. Final Answer:

   Data may be stale and not reflect the latest writes -> Option A

4. Quick Check:

   readConcern 'local' = possible stale data [OK]

Hint: 'local' readConcern may return stale data [OK]

Common Mistakes:

• Assuming 'local' means freshest data
• Confusing readConcern with read preference
• Thinking 'local' reads from secondary only

4. You set writeConcern: { w: 3, j: true } on a MongoDB write operation but receive a timeout error. What is the most likely cause?

medium

A. The write is waiting for acknowledgement from 3 nodes and journaling, but not enough nodes are available

B. The writeConcern option is invalid syntax

C. The writeConcern level is too low for durability

D. The write operation is ignoring writeConcern settings

Solution

1. Step 1: Understand writeConcern with w:3 and j:true

   This setting requires acknowledgement from 3 nodes and confirmation that data is written to the journal.

2. Step 2: Analyze timeout cause

   If fewer than 3 nodes are available or journaling is delayed, the write will timeout waiting for acknowledgements.

3. Final Answer:

   The write is waiting for acknowledgement from 3 nodes and journaling, but not enough nodes are available -> Option A

4. Quick Check:

   High writeConcern with unavailable nodes causes timeout [OK]

Hint: High writeConcern needs enough nodes online [OK]

Common Mistakes:

• Thinking syntax is invalid
• Assuming low writeConcern causes timeout
• Believing write ignores writeConcern

5. You want to optimize a MongoDB application for maximum read performance but still ensure data is not stale beyond the last majority commit. Which readConcern level should you choose?

hard

A. 'local' to read from the primary quickly

B. 'majority' to read only data acknowledged by majority

C. 'linearizable' to ensure strict consistency

D. 'available' to read from any node without guarantees

Solution

1. Step 1: Define the requirement

   We want fast reads but data must not be stale beyond the last majority commit.

2. Step 2: Evaluate readConcern levels

   'local' may return stale data, 'available' has no guarantees, 'linearizable' is strict but slower. 'majority' balances freshness and performance by reading data acknowledged by majority.

3. Final Answer:

   'majority' to read only data acknowledged by majority -> Option B

4. Quick Check:

   readConcern 'majority' = fresh and performant [OK]

Hint: Use readConcern 'majority' for fresh and fast reads [OK]

Common Mistakes:

• Choosing 'local' and getting stale data
• Picking 'linearizable' and hurting performance
• Using 'available' with no consistency guarantees