Compared with MySQL, in which scenario is MongoDB more applicable?

Original link:  http://page.factj.com/blog/p/4078

 

MongoDB has been popular for a long time. Compared with MySQL, what scenarios need to use MongoDB more? Below are some summaries.

higher write load

By default, MongoDB focuses more on high data write performance than transaction security. MongoDB is well suited for scenarios where there is a large amount of "low-value" data in business systems. However, you should avoid using MongoDB in systems with high transaction safety unless transaction safety can be guaranteed by architectural design.

high availability

MongoDB's master-slave configuration is very simple and convenient. In addition, MongoDB can quickly respond to single node failures and complete failover automatically and safely. These features enable MongoDB to maintain high availability in a relatively unstable (such as cloud hosting) environment.

The amount of data is very large or will become very large in the future

Relying on the characteristics of the database (MySQL) itself, it is difficult to complete the expansion of data. In MySQL, when a single expression table reaches 5-10GB, there will be obvious performance degradation. At this time, it is necessary to split the data horizontally and vertically. The split of the database and the library completes the expansion. The use of MySQL usually requires the help of the driver layer or the proxy layer to complete such requirements. MongoDB has built-in features of multiple data sharding, which can well meet the needs of large data volumes.

Location based data query

MongoDB supports two-dimensional spatial indexes, so data can be retrieved from a specified location quickly and accurately.

Table structure is not clear, and the data is growing

In some traditional RDBMSs, adding a field can lock up the entire database/table, or significantly degrade the performance of other requests when executing a heavily loaded request. Usually occurs when the data table is larger than 1G (even more when it is larger than 1TB). Since MongoDB is a document-based database, adding a new field to an unstructured or unstructured document is a quick operation and won't affect existing data. Another benefit is that there is no need to modify the table structure by the DBA when business data changes.

No DBA support

If you don't have a full-time DBA and are prepared to work with data without standard relational thinking (structuring, joins, etc.), then MongoDB will be your first choice. MongoDB is very convenient for storing object data, and classes can be directly serialized into JSON and stored in MongoDB. But you need to understand some best practices first to avoid performance defects due to document design issues when the data becomes larger.


BillRun - MongoDB based billing system  (from oc666 )

BillRun is an open source billing system launched by Ofer Cohen, using MongoDB as data storage. This billing system is adopted by one of the fastest-growing telecom operators in Israel, processing 500 million communication records per month. Ofer explained on Slideshare which features of MongoDB are specifically beneficial:

The feature of weak data structure makes BillRun support new CDR (communication record) type very quickly. This feature makes document databases well suited for rapidly evolving systems with uncertain business requirements.

BillRun uses only one Collection, has managed terabytes of document data, and has not encountered limitations and problems caused by structural changes and explosive data growth .

The replicaSet replica set feature makes it easier to build more data center DRPs.

The built-in Sharding sharding feature prevents the system from encountering performance bottlenecks in the process of data growth.

With the insertion of 2000 communication records per second, MongoDB's architecture design supports high-load data writing very well . And you can use findAndModify (relatively slow) to complete the basic transaction features, and through the support of the application level, to achieve double-stage submission.

Compared with SQL, the query method is easier to read and understand, and the development is relatively easy.

Location-based allows for better analysis of user usage and thus better targeting of mobile telephony infrastructure.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325070272&siteId=291194637