Optimization strategies for high-concurrency writes

Analysis of High-Concurrency Write Scenarios

As a document-oriented database, MongoDB may face performance bottlenecks in high-concurrency write scenarios. Typical scenarios include:

• High-frequency data reporting from IoT devices
• Order creation during e-commerce flash sales
• Real-time interaction data on social media
• Player state updates in game servers

The common characteristics of these scenarios are intensive write operations and sensitivity to latency. When QPS reaches thousands or even higher, targeted optimizations are required.

Bulk Insert Optimization

Bulk insert is the most straightforward write optimization technique. Compared to single-document inserts, bulk operations significantly reduce network round trips and transaction overhead.

// Inefficient single-document insert
for (let i = 0; i < 1000; i++) {
  await db.collection('logs').insertOne({ 
    timestamp: new Date(),
    value: Math.random() 
  });
}

// Efficient bulk insert
const bulkOps = [];
for (let i = 0; i < 1000; i++) {
  bulkOps.push({
    insertOne: {
      document: {
        timestamp: new Date(),
        value: Math.random()
      }
    }
  });
}
await db.collection('logs').bulkWrite(bulkOps);

Tests show that bulk insert can achieve 10-50 times the performance of single-document inserts. It is recommended to keep the batch size between 100-1,000 documents, as excessively large batches may cause memory pressure.

Write Concern Level Adjustment

MongoDB provides multiple write concern levels:

• {w: 0}: Unacknowledged (fastest but least reliable)
• {w: 1}: Primary node acknowledgment (default)
• {w: "majority"}: Majority node acknowledgment (most reliable)

In high-concurrency scenarios, you can appropriately lower the write concern level to improve throughput:

// Log data can use unacknowledged writes
db.collection('logs').insertOne(
  { message: 'debug info' },
  { w: 0 }
);

// Critical business data should maintain majority acknowledgment
db.collection('orders').insertOne(
  { product: 'phone', qty: 1 },
  { w: 'majority' }
);

Index Optimization Strategy

Improper indexing can significantly slow down write performance:

1. Reduce redundant indexes: Each index adds B-tree maintenance overhead during writes.
2. Avoid indexing random fields: Indexing random values like UUIDs can lead to frequent page splits.
3. Use sparse indexes: Apply sparse: true to fields that may be empty.

// Create optimized indexes
db.collection('users').createIndexes([
  { key: { email: 1 }, unique: true },
  { key: { lastLogin: 1 }, sparse: true }
]);

Regularly analyze index size and usage with db.collection.stats() and remove unused indexes.

Sharded Cluster Deployment

When a single node cannot handle write pressure, sharding is the ultimate solution:

1. Choose an appropriate shard key:

   • Avoid monotonically increasing shard keys (e.g., auto-incrementing IDs).
   • Ideal shard keys should have high cardinality and high frequency dispersion.
   • Consider compound shard keys like {region:1, timestamp:1}.

2. Sharding strategy example:

sh.enableSharding("iot_db");
sh.shardCollection("iot_db.sensor_data", 
  { sensor_id: 1, timestamp: -1 },
  { numInitialChunks: 8 }
);

3. Pre-split chunks: For scenarios with known data distribution, pre-splitting chunks can avoid hotspots.

Write Buffering and Batching

Implementing write buffering at the application layer can effectively smooth write peaks:

class WriteBuffer {
  constructor(collection, { maxSize = 100, flushInterval = 1000 }) {
    this.collection = collection;
    this.buffer = [];
    this.maxSize = maxSize;
    setInterval(() => this.flush(), flushInterval);
  }

  async insert(doc) {
    this.buffer.push(doc);
    if (this.buffer.length >= this.maxSize) {
      await this.flush();
    }
  }

  async flush() {
    if (this.buffer.length === 0) return;
    
    const bulkOps = this.buffer.map(doc => ({
      insertOne: { document: doc }
    }));
    
    await this.collection.bulkWrite(bulkOps);
    this.buffer = [];
  }
}

// Usage example
const buffer = new WriteBuffer(db.collection('metrics'), {
  maxSize: 500,
  flushInterval: 2000
});

// High-concurrency writes will be buffered
for (let i = 0; i < 10000; i++) {
  buffer.insert({ value: i, ts: new Date() });
}

Hardware and Configuration Tuning

Server-level optimizations are equally important:

1. Storage engine selection:

   • WiredTiger: Suitable for most scenarios, supports compression.
   • In-Memory: For extreme low-latency scenarios.

2. Key configuration parameters:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8  # Recommended 50-70% of RAM
      journalCompressor: snappy
    collectionConfig:
      blockCompressor: zstd

3. Hardware recommendations:
   • Use SSD or NVMe storage.
   • Ensure sufficient RAM to accommodate the working set.
   • Multi-core CPUs are beneficial for concurrent processing.

Monitoring and Capacity Planning

Establish a comprehensive monitoring system:

1. Key metrics:

   • Write queue length (globalLock.currentQueue.writers).
   • Page fault rate (wiredTiger.cache.pages read into cache).
   • Write latency (db.serverStatus().opLatencies.write).

2. Capacity planning formula:

Required OPs = Peak write QPS × Safety factor (1.5-2)
Number of shards = ceil(Required OPs / Single shard capacity)

3. Use tools like Atlas or Ops Manager for automatic scaling.