MongoDB best practices-Billing System

MongoDB best practices-Billing System

Author: chszs, reprinted with note. Blog homepage: http://blog.csdn.net/chszs

MongoDB best practices: You should use MongoDB in the following situations.

1) scenarios with high write Load

By default, MongoDB is more suitable for high writing than transaction security. If you need to load massive and low-value data for each client, MongoDB is suitable. If you need to load millions of transaction records, this requires additional security measures, which is not suitable for MongoDB.

2) High Availability scenarios are required in unreliable environments

It is easy and fast to set up a replica set (the master node of the server is from the cluster. In addition, fault recovery from a node (or data center) is real-time, secure, and automatic.

3) scenarios where data grows dramatically and data can be sharded

Scaling databases is very difficult (a single MySQL table has 5 GB ~ 10 Gb, its performance will be significantly reduced ). If you need to partition and shard the database, MongoDB has built these mechanisms, which is easy to do.

4) data is location-based.

MongoDB has built-in spatial functions, so it is very fast and accurate to search for relevant data from a specified location.

5) scenarios with large datasets (starting from 1 GB) and unstable Data Models

To add new column fields to some relational databases, the database locks the entire table or degrades the load and performance of the primary database server. Generally, when the size of a data table exceeds 1 GB, the performance is worse. MongoDB has no mode. Adding new fields does not affect existing rows (called documents. Second, when the application changes, MongoDB does not need DBA to modify the data mode.

6) scenarios without DBA

If your company does not have a full-time DBA and you do not need to associate or standardize the data, you can consider MongoDB. MongoDB performs well in persistence, and class data can be serialized into JSON data and stored.

Note: follow the best practices of MongoDB to avoid some traps.

Real case: Billing

The foreign owner Cohen released a next-generation open-source billing solution, which uses MongoDB as its back-end storage. This billing system is already running in the product environment of Israel's fastest-growing mobile operator. It can process call data records of over MB each month. OVL Cohen introduced how it took advantage of MongoDB:

1) Non-Pattern Design

The stateless design allows you to quickly add new call data record types to the system. It enables BillRun to maintain the versatility of data storage.

2) scalable

The product website of BillRun has managed several terabytes of data in a single data table. w/o can be restricted by adding new fields.

3) Fast replica set

The replica set can meet the rules that make it easy to build DRP and HA solutions for multiple data centers.

4) fragment

Slice makes linear resizing clear and controllable, so as not to exceed the budget.

5) The number of call data records inserted per second exceeds 2,000. The MongoDB architecture is very suitable for high write scenarios. You can also ensure the processing of transactions with findAndModify (usually slow) and two-phase commit.

6) developers can perform query-oriented queries to write elegant queries.

7) location-based

Location-based analysis can be used to analyze user usage to determine where to continue building cellular infrastructure.

Finally, MongoDB is a great database. You must use it in a suitable scenario to ensure that you are competitive in the market.