点击了解
MongoDB 4.4提供了您最需要的特性和增强功能。MongoDB 4.4 版本是“用户驱动的工程”，建立在MongoDB 4.x版本家族的基础上，是未来数据处理的理想平台。
MongoDB 4.4 使您能够：
更高效地构建事务、操作和分析型应用随着需求的发展，可以随时随地灵活定义和优化数据分布，从而在全球范围内扩展赢咖4平台同时为您提供全球任意位置最优秀的延迟，弹性和安全性控制体验。
MongoDB 4.4 作为每年一度的大版本更新，已经在 7.30 号正式宣布 GA，不像之前的大版本，总是有一些重磅 Feature 的发布，比如 3.6 的 Change Stream & Causal Consistency，4.0 的多文档事务，4.2 的分布式事务，这次的 4.4 版本更像是一个维护性的版本，而且是一个用户期待已久的维护性版本，MongoDB 官方也把这次发布称之为「User-Driven Engineering」，说明新版本主要是针对用户呼声最高的一些痛点，重点进行了改进。
MongoDB 在 3.0 支持新的 WiredTiger 引擎后经过几年的快速奔跑，终于在 4.4 稍作歇息，开始在细节上进行打磨，4.4 发布的新特性很多，下面笔者就针对一些用户关注度比较高的 Feature 进行重点介绍。
扩展性和性能增强
Hidden Indexes
Hidden Index 是阿里云 MongoDB 和 MongoDB 官方达成战略合作后共建的一个 Feature。我们都知道数据库维护太多的索引会导致写性能的下降，但是往往业务上的复杂性决定了运维 MongoDB 的同学不敢轻易的删除一个潜在的低效率索引，担心错误的删除会带来业务性能的抖动，而重建索引往往代价也非常大。
Hidden Index 正是为了解决 DBA 同学面临的上述困境，它支持通过 collMod 命令对现有的索引进行隐藏，保证后续的 Query 都不会利用到该索引，在观察一段时间后，确定业务没有异常，可以放心的删除该索引。
索引在隐藏期间，如果新的写入，也是会被更新的，所以也可以通过取消隐藏，很方便的让索引立刻变的可用。
Refinable Shard Keys
当使用 MongoDB 分片集群时，相信大家都知道选择一个好的 Shard key 是多么的重要，因为它决定了分片集群在指定的 Workload 下是否有良好的扩展性。但是在实际使用 MongoDB 的过程中，即使我们事先仔细斟酌了要选择的 Shard Key，也会因为 Workload 的变化而导致出现 Jumbo Chunk，或者业务流量都打向单一 Shard 的情况。
在 4.0 及之前的版本中，集合选定的 Shard Key 及其对应的 Value 都是不能更改的，在 4.2 版本，虽然可以修改 Shard Key 的 Value，但是数据的跨 Shard 迁移以及基于分布式事务的实现机制导致性能开销很大，而且并不能完全解决 Jumbo Chunk 或访问热点的问题。比如，现在有一个订单表，Shard Key 为 {customer_id:1}，在业务初期每个客户不会有很多的订单，这样的 Shard Key 完全可以满足需求，但是随着业务的发展，某个大客户累积的订单越来越多，进而对这个客户订单的访问成为某个单一 Shard 的热点，由于订单和customer_id天然的关联关系，修改customer_id并不能改善访问不均的情况。
针对上述类似场景，在 4.4 中，你可以通过 refineCollectionShardKey 命令给现有的 Shard Key 增加一个或多个 Suffix Field 来改善现有的文档在 Chunk 上的分布问题。比如，在上面描述的订单业务场景中，通过refineCollectionShardKey命令把 Shard key 更改为{customer_id:1, order_id:1}，即可避免单一 Shard 上的访问热点问题。
需要了解的是，refineCollectionShardKey 命令性能开销非常低，只是更改 Config Server 上的元数据，不需要任何形式的数据迁移（因为单纯的添加 Suffix 并不会改变数据在现有chunk 上的分布），数据的打散仍然是在后续正常的 Chunk 自动分裂和迁移的流程中逐步进行的。此外，Shard Key 需要有对应的 Index 来支撑，所以refineCollectionShardKey 要求提前创建新 Shard Key 对应的 Index。
因为并不是所有的文档都存在新增的 Suffix Field(s)，所以在 4.4 中实际上隐含支持了「Missing Shard Key」的功能，即新插入的文档可以不包含指定的 Shard Key Field。但是，笔者不建议这么做，很容易产生 Jumbo Chunk。
Compound Hashed Shard Keys
在 4.4 之前的版本中，只能指定单字段的哈希片键，原因是此时 MongoDB 不支持复合哈希索引，这样导致的结果是，很容易出现集合数据在分片上分布不均。
而在 4.4 中支持了复合哈希索引，即，可以在复合索引中指定单个哈希字段，位置不限，可以作为前缀，也可以作为后缀，进而也就提供了对复合哈希片键的支持，
而在 4.4 中直接把需要的字段指定为为哈希的方式即可轻松解决上述问题，比如，对于上文描述的第二个问题场景，片键设置为 {customer_id:'hashed', order_id:1} 即可，大大简化了业务逻辑的复杂性。
MongoDB 4.4提供了您最需要的特性和增强功能。MongoDB 4.4 版本是“用户驱动的工程”，建立在MongoDB 4.x版本家族的基础上，是未来数据处理的理想平台。
MongoDB 4.4 使您能够：
更高效地构建事务、操作和分析型应用随着需求的发展，可以随时随地灵活定义和优化数据分布，从而在全球范围内扩展赢咖4平台同时为您提供全球任意位置最优秀的延迟，弹性和安全性控制体验。
MongoDB 4.4 作为每年一度的大版本更新，已经在 7.30 号正式宣布 GA，不像之前的大版本，总是有一些重磅 Feature 的发布，比如 3.6 的 Change Stream & Causal Consistency，4.0 的多文档事务，4.2 的分布式事务，这次的 4.4 版本更像是一个维护性的版本，而且是一个用户期待已久的维护性版本，MongoDB 官方也把这次发布称之为「User-Driven Engineering」，说明新版本主要是针对用户呼声最高的一些痛点，重点进行了改进。
扩展性和性能增强
Hidden Indexes
Hidden Index 是阿里云 MongoDB 和 MongoDB 官方达成战略合作后共建的一个 Feature。我们都知道数据库维护太多的索引会导致写性能的下降，但是往往业务上的复杂性决定了运维 MongoDB 的同学不敢轻易的删除一个潜在的低效率索引，担心错误的删除会带来业务性能的抖动，而重建索引往往代价也非常大。
Hidden Index 正是为了解决 DBA 同学面临的上述困境，它支持通过 collMod 命令对现有的索引进行隐藏，保证后续的 Query 都不会利用到该索引，在观察一段时间后，确定业务没有异常，可以放心的删除该索引。
需要注意的是，索引被隐藏之后只是对 MongoDB 的执行计划器不可见，并不会改变索引本身的一些特殊行为，比如唯一键约束，TTL 淘汰等。db.runCommand( {
collMod: 'testcoll',
index: {
keyPattern: 'key_1',
hidden: false
}
} )
索引在隐藏期间，如果新的写入，也是会被更新的，所以也可以通过取消隐藏，很方便的让索引立刻变的可用。
Refinable Shard Keys
当使用 MongoDB 分片集群时，相信大家都知道选择一个好的 Shard key 是多么的重要，因为它决定了分片集群在指定的 Workload 下是否有良好的扩展性。但是在实际使用 MongoDB 的过程中，即使我们事先仔细斟酌了要选择的 Shard Key，也会因为 Workload 的变化而导致出现 Jumbo Chunk，或者业务流量都打向单一 Shard 的情况。
在 4.0 及之前的版本中，集合选定的 Shard Key 及其对应的 Value 都是不能更改的，在 4.2 版本，虽然可以修改 Shard Key 的 Value，但是数据的跨 Shard 迁移以及基于分布式事务的实现机制导致性能开销很大，而且并不能完全解决 Jumbo Chunk 或访问热点的问题。比如，现在有一个订单表，Shard Key 为 {customer_id:1}，在业务初期每个客户不会有很多的订单，这样的 Shard Key 完全可以满足需求，但是随着业务的发展，某个大客户累积的订单越来越多，进而对这个客户订单的访问成为某个单一 Shard 的热点，由于订单和customer_id天然的关联关系，修改customer_id并不能改善访问不均的情况。
针对上述类似场景，在 4.4 中，你可以通过 refineCollectionShardKey 命令给现有的 Shard Key 增加一个或多个 Suffix Field 来改善现有的文档在 Chunk 上的分布问题。比如，在上面描述的订单业务场景中，通过refineCollectionShardKey命令把 Shard key 更改为{customer_id:1, order_id:1}，即可避免单一 Shard 上的访问热点问题。
需要了解的是，refineCollectionShardKey 命令性能开销非常低，只是更改 Config Server 上的元数据，不需要任何形式的数据迁移（因为单纯的添加 Suffix 并不会改变数据在现有chunk 上的分布），数据的打散仍然是在后续正常的 Chunk 自动分裂和迁移的流程中逐步进行的。此外，Shard Key 需要有对应的 Index 来支撑，所以refineCollectionShardKey 要求提前创建新 Shard Key 对应的 Index。
因为并不是所有的文档都存在新增的 Suffix Field(s)，所以在 4.4 中实际上隐含支持了「Missing Shard Key」的功能，即新插入的文档可以不包含指定的 Shard Key Field。但是，笔者不建议这么做，很容易产生 Jumbo Chunk。
Compound Hashed Shard Keys
在 4.4 之前的版本中，只能指定单字段的哈希片键，原因是此时 MongoDB 不支持复合哈希索引，这样导致的结果是，很容易出现集合数据在分片上分布不均。
而在 4.4 中支持了复合哈希索引，即，可以在复合索引中指定单个哈希字段，位置不限，可以作为前缀，也可以作为后缀，进而也就提供了对复合哈希片键的支持，
有这个新功能之后，会带来很多好处，比如在如下两个场景下，sh.shardCollection(
"examples.compoundHashedCollection",
{ "region_id" : 1, "city_id": 1, field1" : "hashed" }
)
sh.shardCollection(
"examples.compoundHashedCollection",
{ "_id" : "hashed", "fieldA" : 1}
)
- 因为法律法规的要求，需要使用 MongoDB 的 zone sharding 功能，把数据尽量均匀打散在某个地域的多个分片上。
- 集合指定的片键的值是递增的，比如在上文中举的例子，{customer_id:1, order_id:1} 这个片键，如果customer_id 是递增的，而业务也总是访问最新的顾客的数据，导致的结果是大部分的流量总是访问单一分片。
而在 4.4 中直接把需要的字段指定为为哈希的方式即可轻松解决上述问题，比如，对于上文描述的第二个问题场景，片键设置为 {customer_id:'hashed', order_id:1} 即可，大大简化了业务逻辑的复杂性。
