MongoDB's reading Notes (via3.x) (00) _ "Overview" (_mongodb3.0) Some changes

First long-winded, really did not think, MongoDB can launch 3.x so quickly, my 2.6 of reading notes have not finished, 3.0 killed, how to do ... Headache ...

Look at the introduction of 3.0, I think it is directly on the 3.x reading notes, 2.x of East and 3.x compared to, so the old continuation of things can also review, new things can be immediately known, and 3.x x in the end to a few times to become relative bug fixed version still do not know, So watch the bug fix process while looking at it. The 3.0 change is the change from the underlying data storage, the storage mode of the API can enable the future to add more bottom-level solutions, according to different needs to customize different solutions. Mongodb3.x is an exciting change, and I am looking forward to further study and apply it to future work.
MongoDB 3.0 was released on March 3, 2015 I was in Beijing. Hopefully in MongoDB 4.0 when I can say that I'm in uh ... Where is it? A place where dreams can be made more beautiful. Oh.
Part of the article is the direct translation of document, part of my description of some of the combinations of previous features.

major changes in MongoDB 3.0 (excerpt from major changes) Pluggable data storage engine

MongoDB starts at 3.0 (actually 2.8 has started beta) and finally provides the underlying API, so that the underlying process of storage can be separated from MongoDB's application layer, and third-party storage solutions will emerge in the future.

Wired Tiger

Wired Tiger, to tell you the truth, I. I miss know. Previously only know that it is a work of berkeleydb architects, but do not know that this has been acquired by MongoDB, is now MongoDB has its own memory map of the storage mode and there is a very NB Wired tiger, it seems good prospects.
OK, what is wired tiger? Website: http://www.wiredtiger.com/
The word on the webpage is: making Big data roar. Roar the word ... I really am a dictionary, have not seen. The Chinese meaning of the word is "roaring", Wired Tiger homepage of the various data has embodied its algorithm advantages and capabilities, specific excellent place I in the back of learning and understanding continue to dig and then share out. MongoDB announced the acquisition of Wired Tiger on December 16, 2014, which was a very successful strategic acquisition, linked to poke me.
MongoDB 3.0 supports two underlying storage modes:

? MMAPv1

This is MongoDB's pro-son, himself has been doing the memory-mapped storage mode, which I wrote about in previous articles, is private view and Journal and shared view to achieve data writing, In fact, it is very hard to use the memory cache and logs. That, this natural has been suspected to be replaced by the adopted son, and 3.0 of the storage as the default mode. It seems that MongoDB still wants to continue to optimize and hold for some time (on optimization below will continue to say).

? Wiredtiger

As the 3.0 version of the star debut, but now only support 64-bit operating system.

features

Wiredtiger can support all of MongoDB's features, including the various operations of the server, the database, and data analysis, and I think this change is more transparent to the customer than the direct use result. If the existing data to switch to Wiredtiger need to use MongoDB's command to switch, and there is a more complex update process, which I have not studied, there is time to refine later.
Another more handsome is that we know that replica and Shard is able to support MMAPV1 and Wiredtiger mix-and-match mode, that is, according to our needs are very storage purposes to adjust the cluster mode, coupled with some of the MongoDB parameters command to "make the most use of" Can play better, back also hope to have the opportunity to practice my own practice.
Finally, although I have not studied this wiredtiger carefully, I think it is possible to see a picture of his homepage summarizing its features.
1. Good linear scalability, as the operating thread increases, the number of (query) operations is linearly incremented.
2. Good data write throughput, as the number of write lines increases, the inserts per second almost does not change (I, how to do ...) )
3. The low latency of the update operation, with the increase in request, the rate of delay change is very low (I, how this is done ...) )

If the efficient storage components plus MongoDB's easy-to-operate products must be very handsome. No wonder Wiredtiger's slogan is make big Data roar.

Another feature of the user's tear rush

The lock at document level. Previous MongoDB a big criticism is collection level of lock, this wiredtiger directly put out this regiment fire, document level lock directly solve big problem. And the use of snappy compression (sorry this I am also not very clear, have time to learn).

Improvement of MMAPv1 Concurrency Improvements

The adopted son is so strong, the pro-sons also do not show weakness, MongoDB said the original collection level of locking has been improved.
(-?-;) 。。。 Improvement, the effect is not yet known, but from the collection level of the words may seem to allow large-scale reading and writing operations to create fear of psychology.

changes of spatial distribution mechanism

The former MongoDB also has a criticism, is the space allocation mechanism.
There is a noun called the fill factor (padding Factor). Listen to a seemingly magical thing, in fact, nothing, plainly, is to give a document to occupy the parameters, because the NoSQL mongodb feature is the same collection document may be the internal shape and structure will be different ( If it is in-place-update, this situation will be very small, because in-place-update generally does not affect the length of the document changes), large-scale update and delete operations if the document length changes will occur when documents move, This movement can sometimes have a great impact on the operation, coupled with the collection level of the lock, so once the volume of data large concurrency and more, resulting in more mobile so the impact is also very large, in the second edition of the MongoDB authoritative guide explicitly wrote "Now MongoDB is not a good solution."
3.0, the first is to improve the collection lock, the second is to abolish the filling factor. Without a fill factor, the default is to use power of 2 allocation, which is less mature before mongodb, and claims to be well-optimized for this approach, and the processing of large-order data can be "handle". In fact, this is an algorithm-level approach, which is simply to make the space allocation into multiples of 2, in the opening, moving when the debris can be reduced and in the location of the calculation of the algorithm will be unified, simple. In MongoDB prior to 2.x, the usepowerof2sizes parameter in collection was deprecated, previous versions:

Mongod–setparameter Newcollectionsusepowerof2sizes=false/true

There is such a parameter setting, this setting for collection can use "power of 2 allocation" allocation strategy, and 3.0 began to not recognize this setting, the default MongoDB is "power of 2 Allocation "policy.
However, if our operation is not a regular update and delete operation, there may be only normal insertion or in-place-update operation, then you do not need to set the "Power of 2 allocation" mode. So MongoDB 3.0 provides a way to turn this policy off. Of course, 3.0 also emphasizes that you want to make sure that your operation is an operation that does not make the length of documents change, think twice.

Replica Sets 12→50

Although not a change in magnitude, this change is enough to scare a cow.
As discussed before, the maximum node support number for Replica set is 12, and 3.0 is 50 ...
Of course, whether or not the voting node is still 7 temporarily do not know, after looking at the document after the explanation.

support for replica sets drivers more

The release of various drivers and is under development.

the improvement of Replsetstepdown

Personally, this improvement is very useful.

the acceleration of Replsetstepdown

Acceleration, refers to some of the operations that prevent Replsetstepdown can be directly killed. such as indexing, write operations or a long mapreduce operation.

slowing down of the Replsetstepdown

Before, I once wrote MongoDB's very troublesome rollback, oneself also drew a picture to explain, originally thought this east only then, unexpectedly and 3.0 of MongoDB finally improved.
In the older version, if Replsetstepdown is executed, primary will default to 10 seconds for the candidate's secondary, which is a less-than-responsible setting, resulting in rollback, and MongoDB's rollback recovery work can only man-made operation, so calculate a small chicken. So, 3.0 start primary will wait for secondary to catch up with their own state after the suicide.

Replsetstepdown of the middle and

Above both acceleration, and deceleration, in fact, is an extreme operation, then the last trick: the Golden Mean.
is also a vague way of responsibility. After all, if you slow down primary suicide if it causes a long period of suspended animation may be saliva, so the latest Replsetstepdown command can be set to wait for secondary chase primary time, is a timeout parameter bar. In addition, if you do not consider secondary synchronization, directly kill primary words, you can also use the force:true parameters to shoot directly, a variety of combinations to choose from.

sharded Cluster

Sharding also changed, but I have not finished the detailed reading, the later refinement of the time to write.

Other Improvements

Security, query enhancement, log classification refinement ... More. Slow down, more days.

Just the sauce first.

つづく???

MongoDB's reading Notes (via3.x) (00) _ "Overview" (_mongodb3.0) Some changes