
# DDS4.4功能概述
文档数据库服务（Document Database Service，简称DDS）完全兼容MongoDB协议，提供安全、高可用、高可靠、弹性伸缩和易用的数据库服务，同时提供一键部署、弹性扩容、容灾、备份、恢复、监控和告警等功能。本次的4.4版本是以往版本的全面加强版，主要针对用户呼声较高的一些痛点重点进行了改进。本文主要介绍部分重点新特性，如果想要查看详细的特性变动，请移步[《兼容性详情》](https://support.huaweicloud.com/productdesc-dds/dds_01_0046.html)。
#### 可变分片键（Mutable Shard Keys）
在DDS分片集群中，一个好的[Shard key](https://docs.mongodb.com/manual/core/sharding-shard-key/#choosing-a-shard-key)至关重要，因为它决定了分片集群在指定的Workload（工作量）下是否有良好的扩展性。但是在实际使用DDS的过程中，即使我们事先仔细斟酌了要选择的Shard Key，也会因为Workload的变化而导致出现Jumbo Chunk（超过预设大小的Chunk），或者业务流量都打向单一分片的情况。
在上一版本4.2中，虽然允许修改Shard key的Value，但是数据的跨分片迁移由于其基于分布式事务的实现机制，导致整个过程性能开销很大，不能很好的解决访问热点或者Jumbo Chunk问题。针对这类问题，在4.4版本中，您可以通过[refineCollectionShardKey](https://www.mongodb.com/docs/v4.4/reference/command/refineCollectionShardKey/)命令给现有的Shard Key增加一到多个Suffix Field来改善现有数据在Chunk上的分布情况。并且，由于refineCollectionShardKey命令不涉及任何形式的数据迁移，因此性能开销非常低。不过由于Shard Key需要相应的Index支持，因此在执行[refineCollectionShardKey](https://www.mongodb.com/docs/upcoming/reference/command/refineCollectionShardKey/?spm=a2c4g.190311.0.0.2b0f69bduw3pqc#examples)命令前，请提前创建新Shard Key所对应的Index。
以下操作演示了如何在DDS 4.4集群实例上使用可变分片键功能：
1. 使用[shardCollection](https://www.mongodb.com/docs/upcoming/reference/command/shardCollection/#mongodb-dbcommand-dbcmd.shardCollection)命令，将test库下的coll集合按照customer_id字段进行范围分片（Range based sharding）：
   ```
   use admin
   db.adminCommand({ 
     shardCollection: "test.coll",  
     key: { "customer_id": 1 }
   })
   ```
   
2. 为了将coll集合的分片键调整为customer_id字段和order_id字段，即{ "customer_id": 1, "order_id": 1 }，首先需要创建对应索引：
   ```
   use test
   db.coll.createIndex({
     "customer_id": 1,
     "order_id": 1
   })
   ```
   
3. 之后使用refineCollectionShardKey命令添加order_id作为一个Suffix Field，来改变分片键（命令执行完成后可以使用sh.status()命令验证修改结果）：
   ```
   use admin
   db.adminCommand( {
      refineCollectionShardKey: "test.coll",
      key: { customer_id: 1, order_id: 1 }
   } )
   ```
   
 
#### 对冲读（Hedged Reads）
页面响应速度直接影响用户使用体验，和经济效益息息相关。如果一个网页的加载时间超过3秒，那么用户的跳出率会大幅上升。针对这类问题，DDS 4.4版本提供了对冲读（Hedged Reads）的能力，意即在DDS分片集群中，mongos节点会把一个客户端的读请求同时发送给某个Shard分片的多个副本集节点，最后选择响应最快节点的返回结果回复给客户端，来减少业务侧感知到的延迟。
您可以通过配置Read Preference参数来使用对冲读（Hedged Reads）功能，因此可以针对每一个具体的Operation进行配置。
- 当[Read Preference](https://www.mongodb.com/docs/v4.4/core/read-preference/)配置为nearest时，默认开启对冲读（Hedged Reads）功能；
- 当[Read Preference](https://www.mongodb.com/docs/v4.4/core/read-preference/)配置为primary时，不支持对冲读（Hedged Reads）；
- 当[Read Preference](https://www.mongodb.com/docs/v4.4/core/read-preference/)指定为其他参数时，需要显示地指明hedgeOptions才会启用对冲读功能。
例如：
```
db.collection.find({ }).readPref(
   "secondary",                      // mode设置
   [ { "usage": "read" },  { } ],    // tag标签
   { enabled: true }                 // hedgeOptions开关
)
```
#### 默认读写关注（Default Read and Write Concerns）
在4.4以前的版本中，当要执行的操作没有显示指定readConcern或writeConcern时，会有默认行为。例如：readConcern默认为local，writeConcern默认为{w: 1}。但这个默认行为是不可以变更的，有时会带来不必要的麻烦。如果用户希望保证数据的强一致性，让所有的insert操作的writeConcern默认为{w: majority}，令所有的read操作的readConcern默认为majority，那么只能在所有访问DDS的代码中来显示指定这个配置。
但在4.4新版本中，您可以通过[setDefaultRWConcern](https://docs.mongodb.com/master/reference/command/setDefaultRWConcern/#dbcmd.setDefaultRWConcern)命令来配置全局默认的readConcern和writeConcern，例如：
```
db.adminCommand({
  "setDefaultRWConcern" : 1,
  "defaultWriteConcern" : {
    "w" : "majority"
  },
  "defaultReadConcern" : { "level" : "majority" }
})
```
您也可以通过[getDefaultRWConcern](https://docs.mongodb.com/master/reference/command/getDefaultRWConcern/#dbcmd.getDefaultRWConcern)命令获取当前默认的readConcern和writeConcern。
#### 复合哈希分片键（Compound Hashed Shard Keys）
在4.4以前的版本中，当您指定哈希分片键时，只能指定单字段的哈希分片键，但是长期以往很容易导致集合数据在分片上分布不不均。
在最新的4.4版本中支持了复合哈希索引，意即您可以在复合索引中指定单个哈希字段，可以作为前缀也可以作为后缀，位置不限，由此来支持复合哈希分片键。
参考用法如下：
```
sh.shardCollection(
  "test.coll",
  { "fieldA" : 1, "fieldB" : 1, "fieldC" : "hashed" }  //哈希字段作为后缀
)
sh.shardCollection(
  "test.coll",
  { "_id" : "hashed", "fieldA" : 1}       //哈希字段作为前缀
)
```
这种灵活的复合哈希索引具有很多优点，消解很多库表设计的复杂性，例如：当集合指定的片键值是逐渐递增的，并且业务总是会访问那些最新加入数据，这会导致大部分的流量打向同一分片。在没有复合哈希分片键的情况下，需要先针对被访问的字段进行哈希值的计算，将结果作为特殊字段存放在文档中，然后再通过范围分片的方式指定其作为片键来解决这类问题。
但是在新版本中，直接把目标字段指定为哈希索引，即可轻松解决上述问题，极大简化了业务逻辑。
#### 其他易用性增强
1. Jumbo Chunk自动均衡。 在之前版本出现Jumbo Chunk问题时，通常只能通过手动迁移Chunk解决，而在4.4新版本中支持Jumbo Chunk的自动迁移与平衡，该功能全程后台进行，减少了不必要的告警，缓解了运维人员的压力，让数据库具有更强的健壮性。
   
2. 分布式事务支持单一文档大小超过16MB。 在之前的版本中，当您尝试插入大于16MB的文档或尝试以使其超过16MB的方式更新现有文档的时，DDS服务器将返回错误。而在4.4版本中，DDS对于分布式事务放开了这一限制，以更加适应实际业务需求。
   
3. projection增强。
   DDS 4.4版本完全兼容MongoDB 4.4版本的projection新语法和用法，例如：
   - projection中目前现在可以支持聚合语法，例如使用聚合算子等功能。
   
   - projection中支持使用json嵌套格式对指定字段进行映射。
   
   - projection中支持使用$符指定映射数组元素的具体index的子元素。
     
4. find命令添加allowDiskUse选项。 在DDS 4.4之前的版本，如果数据库在处理排序操作时超过内存使用限制，则具有阻塞排序的查找操作将失败。而在4.4版本中，find命令可以使用临时文件来支持大型无索引排序，当[allowDiskUse](https://www.mongodb.com/docs/manual/reference/method/cursor.allowDiskUse/#mongodb-method-cursor.allowDiskUse)选项为true时，find命令针对超过内存限制100MB的无索引（阻塞）排序操作，会使用磁盘上的临时文件。
   参考用法：
   ```
   db.coll.find({"location" : "unit12" })
       .sort({"time" : 1})
       .allowDiskUse()
   ```
   
 
#### 总结
本次发布的DDS 4.4版本主要是一个增强已有能力、提高易用性的版本，除了上述解读，还有很多其他的优化，详情请参见[《兼容性详情》](https://support.huaweicloud.com/productdesc-dds/dds_01_0046.html)。
