设计规范

命名规范

• 数据库对象（库名、表名、字段名、索引名）命名建议全部使用小写字母开头，后面跟字母或者数字，数据库对象（库名、表名、字段名、索引名）名字长度建议都不要大于32字节。
• 数据库名称不能使用特殊字符("",.,$,\,/,*,?,~,#,:,|")和空字符\0，数据库名称不能使用admin，local，config。
• 数据库集合名称建议使用字母和下划线组合，不能以system为前缀，<数据库名>.<集合名称> 总长度不超过120字符。

索引设计规范

索引创建，可以避免全表扫描，有效地提高查询命令的执行效率。

• 索引字段的长度不能超过512字节，索引名称长度不能超过64字符，单个复合索引所包含字段数最多不能超过16个。
• <数据库名>.<集合名>.$<索引名>的总长度不能超过128字符。
• 在高选择性字段上的创建索引。在低选择性字段上查询会返回较大的结果集。尽量避免返回较大的结果集。
• 对集合的写操作同时会操作集合上的索引，从而触发更多的IO操作，集合上的索引数量不要超过32。
• 不要创建不会被使用到的索引，因为DDS会加载索引到内存，无用索引加载到内存会浪费内存空间因业务逻辑变化而产生的无用索引也要及时清理。
• 索引创建必须使用后台创建索引，禁止前台创建索引。在集合前台创建索引的过程中，会持续持有父数据库的独占锁。这将导致该数据库及其所有集合上的所有读写操作被阻塞，直至索引创建完成。为避免此类阻塞问题，建议在创建索引时使用 background: true 选项，以非阻塞方式执行索引构建。具体操作请参考创建索引。
• 业务中查询，排序条件的key一定要创建索引，如果建立的是复合索引，索引的字段顺序要和这些关键字后面的字段顺序一致，否则索引不会被使用。
• 不要基于复合索引的靠前字段再创建索引。复合索引可以被用于一个索引中主要字段的查询。例如，对于复合索引(firstname,lastname)可以用于在firstname上的查询，再创建一个单独firstname的索引是不必要的。
• 创建索引会消耗较多的IO与计算资源，建议在业务低谷期进行索引创建，禁止同时并发创建超过5条索引。如果需要对同一集合创建多个索引，建议使用createIndexes命令一次性下发多条索引，可以减少性能损耗。
• 在计划删除某个索引前，请先核实备节点上是否正在创建索引。若发现备节点中有索引正在创建，禁止立即删除索引，此时删除索引可能会导致备节点陷入锁等待，进而引发一些意外的问题。

分片设计规范

对于使用DDS分片集群，建议尽可能地使用分片集合以充分利用性能，详情请参见设置数据分片以充分利用分片性能。

分片集合使用上建议如下：

• 对于大数据量（数据量过百万），并有较高读写请求的业务场景，数据量随着业务量增大而增大的，建议采用分片。
• 对于采用hash分片的集合，需要根据业务后面实际数据量大小，采用预分片，提前预置chunk数量，减少自动均衡和分裂对业务运行造成影响。
• 对于非空集合开启分片，应将均衡器的开启时间窗放在业务空闲时，避免分片间均衡数据与业务冲突影响性能。
• 需要基于分片键排序查询且增加数据时可以分布均匀建议使用范围分片，其他使用哈希分片。
• 合理设计shard key，防止出现大量的数据使用相同shard key，导致出现jumbo chunk。
• 使用分片集群，执行dropDatabase后，一定要执行flushRouterConfig命令，详情请参见如何规避dds mongos路由缓存缺陷。
• 需要注意，对已有数据分片后，如果update请求的filter中未携带片键字段并且选项upsert:true或者multi:false，那么update 请求会报错，并返回“An upsert on a sharded collection must contain the shard key and have the simple collation.”