MongoDB Architecture and Practical Usage at the MamaBang Platform

At the MongoDB Hangzhou user exchange on March 12, 2017, Hu Xingbang, Development Director of the MamaBang platform, presented the platform's technical architecture and MongoDB usage practices, comparing MongoDB with traditional relational databases and highlighting advantages, drawbacks, and operational considerations.

The presentation covered four main topics: the experience of selecting and using MongoDB, a comparison with relational databases, the impact of MongoDB on development and architecture, and data‑model design.

Early MySQL usage : Before 2012 the system used MySQL, employing sharding, master‑slave replication, and middleware such as amoeba and mysql‑proxy to address data volume and access pressure, but operational costs remained high due to limited cloud services and self‑managed IDC infrastructure.

Current MongoDB cluster architecture : The current deployment consists of two availability zones. Zone B supports migration to the cloud, while Zone A is the primary production zone using a "one primary, four secondaries" configuration, with one secondary dedicated to analytics, another as a delayed node, and shared physical machines to reduce cost.

History of MongoDB usage : The evolution includes four stages – single‑machine deployment, master‑slave replication, multiple replica sets to mitigate lock‑related performance issues, and finally sharding (implemented at the end of 2015) with five replica sets, where only the reply collection is sharded.

Reasons for preferring MongoDB : Non‑relational nature is appealing, it aligns well with internet‑scale applications, and its design inherently supports distributed architectures, potentially lowering later operational costs.

MongoDB vs. MySQL comparison :

Schema: MongoDB is schemaless, whereas MySQL has strong schema support.

Transactions: MongoDB offers limited transaction guarantees compared to MySQL.

Stability: Early MongoDB versions were less stable than mature MySQL.

Distributed: MongoDB was built for distribution from the start; MySQL required additional effort.

Operations: MongoDB is generally easier to deploy and manage than MySQL on IDC.

Schema‑lessness as a double‑edged sword : While adding fields, databases, or collections is easy, uncontrolled growth can lead to maintenance challenges, data‑model inconsistency, operational risk, and confusion over data‑structure choices.

Transaction challenges : Real‑world cases (e.g., posting a reply) may span multiple replica sets, making atomicity hard. Solutions explored include background correction, queuing, and two‑phase commit; the team primarily uses background correction for simplicity.

Remaining shortcomings include high coupling with business logic, poor code reuse, and increased complexity and bug risk.

Stability and upgrade issues : Memory pressure caused performance instability in versions before 3.0. Upgrading from 2.6 to 3.2 introduced significant changes, especially the WiredTiger engine, requiring careful data migration and extended downtime.

Distributed environment summary : Replication eliminates single points of failure and provides automatic primary election; sharding addresses massive data volumes (e.g., >200 million replies) with satisfactory performance.

Shard key selection importance : A good shard key must match business query patterns, ensure balanced load, avoid sparse hashes, and follow official recommendations to prevent mongos overload.

Operational improvements :

Enhanced permission control using a customized RockMongo interface.

Implemented monitoring for database and collection growth to detect anomalies early.

Adopted rolling index creation for large tables to minimize impact on live services.

Addressed compatibility issues across client versions.

Scaled hardware by adding replica‑set nodes, typically in groups of three to meet memory demands.

Data‑model design insights :

Prefer a single document per logical entity to simplify transactions.

Choose between regular collections and rolling collections based on data retention needs.

Leverage arrays and dictionaries to handle complex data structures effectively.

Final recommendations :

Use MongoDB cautiously for workloads with strict transaction requirements; consider relational databases or cloud RDS for such cases.

Plan schema constraints early to avoid later data‑model chaos.

Read official documentation and keep the database upgraded (e.g., moving to WiredTiger) to benefit from performance and stability improvements.

Source: Cloudy Community (© original author).