Real MongoDB Performance

I recently started to study MySQL and MongoDB and found that there is not much information in this area. Especially when it comes to ideasArticle, Too few.

Some articles on comparative testing are basically blind tests. The testing methods are tested on the horse, and the conclusion is basically that nosql has no value.

Let me borrow the sentence from Russell Smith: It's not MongoDB, but you don't understand it.

Let me analyze the real performance of MongoDB.

It is said that MongoDB is slow.

Objection: If no unique index is set, tens of thousands are inserted per second on a common office computer with only _ ID, and tens of thousands are inserted per second on a common X86 server, what do you mean is this low performance? It is an order of magnitude higher than MySQL.

Agree: retrieval is really slow. Unlike SQL databases, the more complex the Search Condition mangodb suffers, the more pressure on CPU and Io. In the face of the usage of Directly Writing SQL queries into mangodb, don't turn around, you won't get any performance improvement.

You can't do it: I can't say you can't do it. MongoDB leads the nosql movement. Note that the most important thing we oppose is the SQL methodology. You can only get disappointed when using mangodb using SQL. Think about MongoDB's design philosophy: docization. _ Id is the file name, And MongoDB is a file system. Full-text search? Don't bother. Use a file name to find a file. A file name corresponds to a file, and you will never be disappointed.

So how should MongoDB be used?

First, forget SQL

You should forget the elegant and invincible SQL statements you have learned. It doesn't mean that throwing an index is good to improve the search performance.

There is a simple fact: there is only one default _ id index. At this time, the insertion performance is 1. You can add another index, with the insertion performance of about 1/2 and about 1/3, and so on ......

If this fact is shocking to you, it means that you have not forgotten the SQL statement, and then forget it.

MongoDB indexes have a negligible hold on the insert performance. Therefore, we should use _ id as the Insert key, as the query key, and as all the keys.

Second, I forgot to search for this issue.

Use MongoDB as your hard disk and give it a file name.CompositionThis is the key-value database practice. You can use it with a slight design.

In fact, all your operations can be simplified to two commands, which are logically a dictionary.

You give him _ id, insert a data into the dictionary, or take a data.

Save ({_ ID: XXX ,.....})

Findone ({_ ID: XXX })

To achieve high performance, make good use of the _ id to hash your original primary key into _ id.

What are the original query conditions? Query, take _ ID, and cut down all other items.

Third, this is not a data table

Remember, this is not a data table. What corresponds to a _ id is not a row of data, but a file.

What is the difference between file storage and table storage?

For example, we want to store a list of users and a list of items for each user.

A data table is used to create a user table and a item table. A field in the item table indicates the user to which the table belongs.

Then, you can't do without the query of all evil.

If a user has 100 items, 1 million users mean that the item table has 0.1 billion records.

At this time, I started to test your small database, but this is all the past steps. Using MongoDB is not a problem at all.

Because MongoDB is used as a file storage, only one user set is designed. each user's information is a file, and the 100 items are separated and stored in each user's file.

Next, let's make a comparison. We get the user's record, and then take out 100 items, nosql method.

Query the 0.1 billion table to find the records of a user.

Are you familiar with quick start?

Then you may recall that, in the SQL method, I can also set up a prop field to package the user's 100 items in a certain protocol, and then perform the operation, which can achieve huge optimization.

Yes, you have a good idea. You are using SQL in nosql.

Fourth, the essence of file storage

If the problem stops here, MongoDB has no advantages. If this method is so easy to use on the SQL database, what should I do with MongoDB?

Let's try again. If you need to store 100 transfer records for each item, you can still pack the records, but you have already packed the field 1 MB.

Therefore, every time you access this packaging field, it is a system project, and it will take 1 MB of traffic.

What about MongoDB? We can directly read and write a part of the file. For example, I only return the information of the second item of a user, and return the 1st ~ of the second item ~ 30 transfer records.

What is the difference.

You want a photo of a beautiful girl. Your friend has one, but he only has one compressed package. He does not have a unpacking tool, so he passes the entire package to you. He wants to ask you for a photo, but he does not have a compression tool. for archiving purposes, he asked you to press it into the bag and pass it to him.

This friend is the row of your user table. If it is an incredible event in the real world, it is the problem of packing data in a field.

A record of MongoDB is a more normal friend. You want him to take a picture and he will find it for you from the bag. You give him a picture and place it in his bag.

Using the file thinking to access MongoDB is a better friend.

Check whether most of the data requirements in your project can be organized in this way?

If yes, join nosql. Our slogan is: very violent, not SQL

What are the benefits?

1. horizontal segmentation without logic concerns

No need to talk about it. For MongoDB, this is the work of O & M personnel.

2. Non-Aligned Data Structures

No alignment means you don't have to worry about the migration of previous table structure changes. Some files have a part, but some do not. This is normal for MongoDB.