Some summaries on the MongoDB of NoSQL _mongodb

NoSQL has been in vogue for a long time, so what exactly is the scene you need to use these "new things", like MongoDB? Here are some summaries:

You expect a higher write load

By default, MongoDB is more concerned with the high insertion speed than transaction security. If you need to load a lot of low-value business data, then MongoDB will be good for your use cases. But you must avoid using MongoDB, such as a 10 million dollar deal, in situations that require high transaction safety.

Unreliable environments guarantee high availability

Setting up a replica set (primary-from-server settings) is not only convenient but also quick, and using MongoDB enables fast, secure, and automated failover of nodes (or data centers).

There's going to be a big scale in the future.

Database extensions are challenging, and when a single table size reaches 5-10GB, MySQL table performance can be reduced without a doubt. If you need to fragment and split your database, MongoDB will be very easy to achieve this.

Using location-based data queries

MongoDB supports two-dimensional spatial indexing so that data can be obtained quickly and accurately from a specified location.

Explosive growth of unstructured data

Adding a column to an RDBMS can in some cases lock up the entire database, or increase the load causing performance degradation, which usually occurs when the table is larger than 1GB (the pain point in the Billrun system is mentioned below-a single table is a few gigabytes in number). Given MongoDB's weak data structure pattern, adding 1 new fields does not have any effect on the old table, and the entire process is very fast; therefore, you do not need a dedicated 1 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 join queries, MongoDB will be your first choice. MongoDB is ideal for class persistence, and classes can be serialized into JSON and stored in MongoDB. It's important to note that if you expect to get a larger scale, you have to understand some of the best practices to avoid going into the wrong.

billrun--uses MongoDB billing system |2014 Year February mug IL (from oc666) real-case Learning: Billing

On the last Ilmug, Ofer Cohen presented Billrun, a next generation MongoDB-based open source billing solution. The billing system, which has been adopted by the fastest-growing Israeli mobile phone operator, deals with more than 500 million CDR per month, and Ofer shares the advantages of how the system leverages MongoDB:

PPT please visit slide Share

The weak data structure pattern allows the system to quickly introduce a new CDR type, Billrun is responsible for hosting all the data. The Billrun system has managed TB-level tables, and I/O performance is limited by the increase in new fields and the volume of data. Fast replica sets allow for simpler setup of multiple data center DRP and HA scenarios. Fragmentation allows for linear scaling when I/O is hyper-budgeted. MongoDB is ideal for high write systems when CDR inserts reach 2000 per second. At the same time, you can use Findandmodify (which can affect performance) and 2-phase commit (application level) to resolve transactional issues. Developer-oriented queries allow elegant queries to be written. Location-based allows better analysis of user usage to better develop mobile phone infrastructure investment points.

Summarize

MongoDB is a very good tool, but only in the right scene to explode out of the overwhelming advantage, Billrun is a good use case.

The above mentioned is the entire content of this article, I hope you can enjoy.