[mongodb-dev] MongoDB 3.5.12 is released

['Thomas Schubert' via mongodb-dev]

The Server Team is excited to announce that MongoDB 3.5.12 is ready for
testing. Among the numerous bug fixes and improvements
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2C%20TOOLS%2C%20WT)%20and%20resolution%3D%22Fixed%22%20and%20fixversion%20%3D%20%223.5.12%22>
delivered in the past three weeks, some major features we’ve completed
include:


Improved Connection Storm Handling in ASIO

This work adds improved control on the egress networking connection pool,
which helps mitigate connection storms. New limits on the number of
connections that can be created improve server stability, particularly for
newly promoted primaries in large sharded clusters.


Faster In-place Updates in WiredTiger

This work brings improvements to in-place update workloads for users
running the WiredTiger engine, especially for updates to large documents.
Some workloads may see a reduction of up to 7x in disk utilization (from 24
MB/s to 3 MB/s) as well as a 20% improvement in throughput.


All Issues
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%273.5.12%27>
| Downloads <http://www.mongodb.org/downloads>

Thanks,

The MongoDB Server Team

[张友东]

Faster In-place Updates in WiredTiger

I noticed you add a new WT_UPDATE_MODIFY time to express incremental
updatebut didn't find out how the incremental records stored on disk
Would you like to explain the detials

圚 2017幎8月23日星期䞉 UTC+8䞊午7:08:07Kelsey Schubert写道

Post by 'Thomas Schubert' via mongodb-dev
The Server Team is excited to announce that MongoDB 3.5.12 is ready for
testing. Among the numerous bug fixes and improvements
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2C%20TOOLS%2C%20WT)%20and%20resolution%3D%22Fixed%22%20and%20fixversion%20%3D%20%223.5.12%22>
delivered in the past three weeks, some major features we’ve completed
Improved Connection Storm Handling in ASIO
This work adds improved control on the egress networking connection pool,
which helps mitigate connection storms. New limits on the number of
connections that can be created improve server stability, particularly for
newly promoted primaries in large sharded clusters.
Faster In-place Updates in WiredTiger
This work brings improvements to in-place update workloads for users
running the WiredTiger engine, especially for updates to large documents.
Some workloads may see a reduction of up to 7x in disk utilization (from 24
MB/s to 3 MB/s) as well as a 20% improvement in throughput.
All Issues
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%273.5.12%27>
| Downloads <http://www.mongodb.org/downloads>
Thanks,
The MongoDB Server Team

['Keith Bostic' via mongodb-dev]

Post by 'Thomas Schubert' via mongodb-dev
Faster In-place Updates in WiredTiger
I noticed you add a new WT_UPDATE_MODIFY time to express incremental
updatebut didn't find out how the incremental records stored on disk
Would you like to explain the detials

The in-place update changes don't modify the on-disk collection data
structures, the disk savings come from writing change records to the
journal instead of complete data items. (We've thought about implementing
what the Microsoft bw-tree papers call "delta pages" in our storage
engines, that is, writing pages that are deltas from previously written
pages, but this work doesn't include anything like that.)

[张友东]

Thanks for your replyI got your idea.

I have read the bw-tree paper, the 'delta pages' idea is great to reduce
the write amplification on disk, I thought you have implemented it, so I am
confused after read the 3.5.12 source code.

圚 2018幎3月7日星期䞉 UTC+8䞋午10:27:05Keith Bostic写道

Post by 'Keith Bostic' via mongodb-dev

Post by 'Thomas Schubert' via mongodb-dev
Faster In-place Updates in WiredTiger
I noticed you add a new WT_UPDATE_MODIFY time to express incremental
updatebut didn't find out how the incremental records stored on disk
Would you like to explain the detials

The in-place update changes don't modify the on-disk collection data
structures, the disk savings come from writing change records to the
journal instead of complete data items. (We've thought about implementing
what the Microsoft bw-tree papers call "delta pages" in our storage
engines, that is, writing pages that are deltas from previously written
pages, but this work doesn't include anything like that.)