Some summary about NoSQL and MongoDB

NoSQL has been popular for a long time, so in what situations do you need to use these "new things" more, such as MongoDB? Here's a summary:

You expect a higher write load

By default, MongoDB is more concerned with high insertion speeds than transaction security. If you need to load a lot of low-value business data, MongoDB will be a good fit for your use case. However, you must avoid using MongoDB in situations where high transaction security is required, such as a $10 million transaction.

Unreliable environments guarantee high availability

Setting up replica sets (master-slave server Settings) is not only convenient and fast, but also enables fast, secure, and automated node (or data center) failover using MongoDB.

There will be a very large scale in the future

Database scaling can be challenging, and when a single table size reaches 5-10GB, the performance of the MySQL table will undoubtedly decrease. If you need to shard and split your database, MongoDB will easily implement this 1 point.

Use location-based data queries

MongoDB supports 2-dimensional spatial indexing, so you can quickly and accurately retrieve data from a given location.

The explosion of unstructured data

Adding a list to RDBMS can in some cases lock the entire database, or increase the load and result in performance degradation, which usually occurs when the table is larger than 1GB (more on the pain points in the BillRun system below -- a single table is more than GB). Given the weak data structure pattern of MongoDB, adding a new field will not have any impact on the old table, and the whole process will be very fast; Therefore, you do not need a dedicated DBA to modify the database schema when the application changes.

Lack of professional database administrators

If you don't have a professional DBA, and you don't need to structure your data and do join queries, MongoDB will be your first choice. MongoDB is ideal for class persistence, which can be serialized to JSON and stored in MongoDB. It is important to note that if you want to achieve a larger scale, you must understand some best practices to avoid pitfalls.

BillRun -- using MongoDB's billing system | February 2014 MUG IL (from oc666) reality use case study: billing

In the last ILMUG, Ofer Cohen proposed BillRun, an open source billing solution based on MongoDB for the next generation. This billing system has been adopted by the fastest growing mobile phone operator in Israel, handling more than 500 million CDR (traffic records) per month. Ofer shares how the system can take advantage of MongoDB:

For PPT, please visit Slide Share

The weak data structure pattern allows the system to quickly introduce a new CDR type, which is responsible for hosting all the data. The BillRun system already manages TB level tables, and I/O performance is limited by the addition of new fields and the growth of data volume. Fast replica sets allow easier setup of multi-data center DRP and HA schemes. Sharding allows for linear horizontal scaling of I/O when over budget. MongoDB is very good for high-write systems when CDR inserts reach 2,000 per second. At the same time, you can use findAndModify (which affects performance) and phase 2 commit (application level) to resolve transaction issues. Developer-oriented queries allow for the writing of elegant queries. Location based allows better analysis of user usage and thus better planning of investment points for mobile phone infrastructure.

conclusion

MongoDB is a great tool, but only in the right circumstances can it be overwhelming, and BillRun is a great use case.

That's all for this article, I hope you enjoy it.