Tuning consistency vs performance in MongoDB - Hands-On Comparison

Tuning Consistency vs Performance in MongoDB

📖 Scenario: You are managing a MongoDB database for an online store. You want to understand how to balance data consistency and performance by tuning write concerns and read preferences.

🎯 Goal: Build a MongoDB setup where you create a collection, configure write concern and read preference settings, and perform queries to see how these settings affect consistency and performance.

📋 What You'll Learn

Create a MongoDB collection named orders with sample documents

Set a write concern variable with w: 'majority' and wtimeout: 5000

Use a read preference variable set to secondaryPreferred

Perform an insert operation with the write concern and a find query with the read preference

💡 Why This Matters

🌍 Real World

Online stores and many applications use MongoDB replica sets where tuning consistency and performance is critical for user experience and data safety.

💼 Career

Database administrators and backend developers often tune write concern and read preference settings to optimize MongoDB deployments for their specific application needs.

1

Create the orders collection with sample data

Create a MongoDB collection called orders and insert these exact documents: { orderId: 1, item: 'Book', quantity: 3 } and { orderId: 2, item: 'Pen', quantity: 10 }.

MongoDB

// Insert the sample documents into the orders collection
// Your code here

Hint

Use insertMany on db.orders with an array of the two documents.

2

Set the write concern configuration

Create a variable called writeConcern and set it to an object with w: 'majority' and wtimeout: 5000.

MongoDB

db.orders.insertMany([
  { orderId: 1, item: 'Book', quantity: 3 },
  { orderId: 2, item: 'Pen', quantity: 10 }
])

// Define the writeConcern variable
// Your code here

Hint

Use const writeConcern = { w: 'majority', wtimeout: 5000 } to set the variable.

3

Set the read preference configuration

Create a variable called readPreference and set it to the string 'secondaryPreferred'.

MongoDB

db.orders.insertMany([
  { orderId: 1, item: 'Book', quantity: 3 },
  { orderId: 2, item: 'Pen', quantity: 10 }
])

const writeConcern = { w: 'majority', wtimeout: 5000 }

// Define the readPreference variable
// Your code here

Hint

Set readPreference to the string 'secondaryPreferred'.

4

Perform insert and find operations with the configurations

Insert a new document { orderId: 3, item: 'Notebook', quantity: 5 } into orders using the writeConcern variable. Then, perform a find query on orders using the readPreference variable.

MongoDB

db.orders.insertMany([
  { orderId: 1, item: 'Book', quantity: 3 },
  { orderId: 2, item: 'Pen', quantity: 10 }
])

const writeConcern = { w: 'majority', wtimeout: 5000 }

const readPreference = 'secondaryPreferred'

// Insert a new document with writeConcern and find with readPreference
// Your code here

Hint

Use insertOne with the writeConcern option and find().readPref(readPreference).

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