MongoDB Experience Sharing

This article is from the "Ten-day master MongoDB" series PPT last year. The content of this series of PPT is from the "MongoDB authoritative guide (English version)" at that time. The personal translation capability is limited, and the content of the PPT cannot be completely consistent with the content of the book. In addition, I have added a lot of my opinions. The tenth lesson is shared with you today, mainly my personal views at the time. These views are not necessarily correct at present. Please criticize and correct them more!

Understanding of nosql

Nosql does not mean no-SQL, but not only SQL.

The emergence of nosql aims to make up for the lack of performance of SQL databases in processing massive data and highly concurrent requests due to transaction and other mechanisms.

Nosql does not appear to replace SQL. It is a substitute solution, rather than the first choice for the solution.

Most nosql products are based on large memory and high-performance random read/write (such as SSDS with higher performance). Generally, small enterprises must be careful when selecting nosql! Do not use nosql for nosql, which may lead to a waste of money and delay in the project process.

Nosql is not omnipotent, but in large projects, you often need it!

Why is MongoDB?

• Bson-based, JSON-compatible
• Extensive Driver Support
• High-performance, open-source, document-oriented
• Full-text index support
• Auto copy parts
• Built-in Distributed File System
• Built-in mapreduce support
• ......

Don't be cheated by Chen, I just want to list the advantages of MongoDB, if you want to know other nosql products, may wish to look at the http://cloud.csdn.net/a/20110610/299526.html

Document Structure Design

In the SQL era, we can design our own table structure at will. We only need to pay attention to the selection of data types, but cannot directly use the tree design.

I am not so lucky at MongoDB. the built-in query mechanism of MongoDB is very limited, and it cannot make "your original design" so easy to migrate.

In fact, such "not powerful" as MongoDB is "intentional! CoreAlgorithmAnd forces developers to use a large amount of redundant data to improve computing efficiency.

This is a good practice! Not good! The good thing is that we can solve a lot of problems. The bad thing is, we need to change our previous ideas, or even the general practices we thought before, it also brings a lot of "seemingly unnecessary" trouble to maintenance.

MongoDB claims that the CPU resources it occupies are very low-because its architecture directly bypasses a lot of operations !!!

I don't have much to say here. To sum up, I just want to say a word-do not mean the storage space, and use the advantages of redundant data to the extreme!

Index and Query Optimization

Traditional SQL optimization techniques are also applicable to MongoDB;

Do not create an index for all keys or an index;

If necessary, compound indexes should be prioritized, but note the key order;

If you find that even index creation cannot be effectively improved, you should consider sharding data;

When designing a query, the conditions that can filter out a large number of records should be put in front, unless such changes affect business requirements.

Regardless of the business, please try to avoid processing various sorts on the database end. If possible, please try to reduce this design to improve the throughput of the database server. Old Chen's experience is: users do not really hate to mouse more than a few times. What they hate is that after clicking the mouse more than N times, they cannot find the appropriate content. Imagine why Baidu does not provide the user's active sorting function?

Copy parts and replica set

Copying refers to fully copying data to other MongoDB instances;

Sharding refers to distributing a lot of small pieces of data to different sets or MongoDB instances;

Replica set features failover

In fact, in the production environment, we should use three concepts in a hybrid manner and make full use of them.

Data security, computing efficiency, load distribution, failover, and so on. Every feature needs to be robust!

Do you remember what I said before? No one can play with nosql, and no one can play well! A strong MongoDB cluster may require at least a dozen servers. Hardware alone is a huge investment!

Data security-do not trust any device, and always back up important business data.

Yes, you can perform hot backup on MongoDB data using replication. The master database engine does not need to be stopped.

Others

Use as few nested documents as possible, which will make your database expand very quickly and is not conducive to expansion;

Of course, I am not saying I should not use it. If there is no deep query or sorting of sub-documents, or it is simply a record, it would be the best to use sub-documents!

MongoDB is not suitable for storing high-precision numbers. For example, if you need financial data storage with high precision, we recommend that you use other persistence solutions, alternatively, you can simply save it as a string or create a copy of the string format for storage.

MongoDB does not have an inline query mechanism and relies solely on manual foreign keys;

MongoDB has no auto-incrementing logo, and there are no signs of support in future plans. In fact, this is what MongoDB intentionally did! We recommend that you use a random ID instead of an incremental ID.

Mark, read it as biaozhi4, not biaoshi2. Remember it!