MGO design tuning.

This is a creation in Article, where the information may have evolved or changed.

MGO design tuning.

Really is that sentence, not you can't, knowledge you do not understand. Only.

2. Must not add two indexes.
   1. The cost of the index is too big, not only to occupy memory also a lot of loss of query performance, really can not endure ah.
4. The design of the time Dbref is definitely needed, directly with meaningful ID query is certainly the best performance.
6. It must be necessary to control the number of keys. For example, the number of users is the number of keys that's enough. Don't be so much. Collection otherwise loss of performance.
   1. If you really want to control the number, then the data association must be very necessary.

7. Flow control is certainly a must.

   2. The source of traffic is that find returns all query results directly. Horizontal slots. Eat all the traffic directly.
   4. Avoid querying multiple results directly with FindOne It's definitely necessary to get back.

   5. Is FindOne enough? I did meet this hole. The method of applying filter to this situation has been mentioned in blog post. The direct reference is OK.

      1	FindOne ({_id:xxx},{items:{"$slice": [3,1]}})

      Although this method is applied to design, the result of the query reduces the flow of traffic. But there are still problems.

      1. Must pay more attention, can not directly dbref because slice bad add ah. You can use the sequential ID to add pagination, or to calculate the time. 233 is very practical, typical use of space to change time.

      1 2 3 4 5 6 7

      Db.user.findOne ({user_id:2}, {"Book.price":1,"Book.price.": {$slice: [-10 ,4]}}) Explain the meaning of the following: 1. User Collection 2. user.book.price that users have books, books have a lot of price list 3. Note the red font "Book.price." must have a dot at the end. 4. Find the 4 data in the price list, starting from the right in the first ten places cheap

      But there are different grammatical explanations, so try it.

9. Update to make fine-grained changes.

1	such as update ({_id:xxx},{$set: {"Items.3.item.health":}}); //Modify the health value of the third weapon

As for a modification and batch modification, mongodb default 100ms flush once (2.x), as long as the two modifications are close, the likelihood of being together is very high.

The above is to quote what others say, or to directly fine-tune the changes, and the database will be automatically modified together, performance is not a problem

1. The last few notes
   1. Control IO (System throughput) This is the core of the whole system, and the core of system performance.
   2. Control memory (do not let index inflate)
      1. Control index number,
      2. Control the number of keys
   3. CPU control do not let JS do a lot of calculations, can migrate to the client's computing to migrate to the client, let them finish after the communication
   4. The first estimate of insufficient performance is the hard disk, which can be used to fix the whole problem with raid or Enterprise SSD.

Golang MgO Drive Use

Ref1

Ref2