How Migrating from Elasticsearch to MongoDB Cut Costs 10‑Fold and Boosted Latency

Business Background

The smart‑product service stored ~2.5 billion records in Elasticsearch, consuming about 30 TB of disk per single‑replica cluster. Severe latency and high operational cost motivated a partial migration to MongoDB, which immediately reduced costs by an order of magnitude and eliminated service jitter.

Source Elasticsearch Cluster Resources

Two active‑active data‑center clusters were deployed, each with 26 containerized nodes (32 CPU, 64 GB RAM, 2 TB SSD). Per‑cluster resource consumption was 832 CPU cores, 2 048 GB RAM, and 64 TB disk; both clusters together used 1 664 CPU, 4 096 GB RAM, and 128 TB disk. Pain points included duplicated cost, dual‑write complexity, data‑consistency gaps after failover, and query patterns that favored MongoDB.

MongoDB Cluster Architecture and Resource Planning

A sharded MongoDB cluster was designed for the workload (exact‑match queries on a unique _id, low write throughput, active‑active deployment). The design uses 2 shards, each replicated 4 times. Each mongod container is sized at 16 CPU, 64 GB RAM, and 5 TB SSD. A single container also hosts a mongos proxy and a config server (8 CPU, 8 GB RAM, 50 GB SSD). This provides headroom for future growth to ~5 TB per shard (≈10 TB total).

Performance Optimization Process

Three phases were executed: pre‑migration preparation, migration‑time bottleneck tuning, and post‑migration performance tweaks.

Pre‑migration: All documents contain a unique _id. Hash‑based sharding was chosen to evenly distribute data across the two shards, and pre‑splitting was performed to avoid chunk migrations during load.

sh.shardCollection("user_xxx.user_xxx", { _id: "hashed" }, false, { numInitialChunks: 8192 })

Enabled nearest read preference so clients read from the closest replica.

Deployed two mongos proxies per data‑center for high availability.

Disabled enableMajorityReadConcern because the workload does not require majority reads.

Increased WiredTiger cache size to 42 GB (later to 55 GB) to keep hot data in memory and avoid OOM.

db.adminCommand({ setParameter: 1, "wiredTigerEngineRuntimeConfig": "eviction=(threads_min=4, threads_max=20)" })

Reference for readConcern analysis: https://developer.aliyun.com/article/60553. Source code reference: https://github.com/y123456yz/reading-and-annotate-mongodb-3.6.

Performance Comparison After Migration

Monitoring showed MongoDB query latency around 1.5 ms, far better than the previous second‑level latency of Elasticsearch. The MongoDB cluster also handled higher overall traffic because it stored additional business data beyond the migrated tables.

Cost Comparison

CPU and memory usage were comparable (both clusters were under‑utilized), but disk consumption differed dramatically. Elasticsearch required roughly six times more disk than MongoDB for the same data set (≈30 TB vs ≈5 TB). The cost ratio for disk was therefore about 6:1.

Suitability Summary for Elasticsearch vs MongoDB

Elasticsearch excels at fuzzy matching, full‑text search, and complex multi‑field queries.

MongoDB performs best for exact‑match queries on fixed fields, high‑throughput writes, and scenarios where WiredTiger compression reduces storage cost.

No database is universally superior; selection must match the specific query patterns and cost constraints of the workload.

Key Technical Details

Sharding strategy: hashed on _id with numInitialChunks: 8192 to pre‑split data.

Read preference: nearest to achieve locality in a multi‑data‑center deployment.

ReadConcern: disabled enableMajorityReadConcern to avoid majority‑read overhead.

WiredTiger cache: initially 42 GB, later increased to 55 GB; eviction threads tuned via eviction=(threads_min=4, threads_max=20).

Container specs: mongod – 16 CPU, 64 GB RAM, 5 TB SSD; mongos + config server – 8 CPU, 8 GB RAM, 50 GB SSD.