1、哪些mongoDB相关文章介绍不错？

个人无意看到杨亚洲的mongoDB系列相关文章，觉得挺不错

2、mongoDB数据库默认开启分片功能吗？

默认不开启

3、分片键如何选择？

可参考阿里云mongoDB云产品分片集群介绍，里面介绍到如何选择Shard Key。

场景举例：
某物联网应用使用MongoDB分片集群存储海量设备的工作日志。如果设备数量在百万级别，设备每10秒向MongoDB汇报一次日志数据，日志包含设备ID（deviceId）和时间戳（timestamp）信息。应用最常见的查询请求是查询某个设备某个时间内的日志信息。

查询需求举例：
查询某个设备某个时间内的日志信息。

方案一（推荐）：组合设备ID和时间戳作为Shard Key，进行范围分片。
写入能均分到多个shard。
同一个设备ID的数据能根据时间戳进一步分散到多个chunk。
根据设备ID查询时间范围的数据，能直接利用（deviceId，时间戳）复合索引来完成。

另三种缺点明显
方案二： 时间戳作为Shard Key，进行范围分片。
所有设备新的写入为连续的时间戳，都会请求到同一个分片，写分布不均且压力负载大。

方案三： 时间戳作为Shard Key，进行哈希分片。
虽分布均衡，查询分散到各个分片，效率低。

方案四：设备ID作为Shard Key，进行哈希分片。
单设备的数据只能在一个分片上，没法进一步的细分。方案一算是该方案的进一步优化。
容易造成jumbo chunk。

4、分片策略

范围分片：对分片键值进行范围分片
哈希分片：对分片键值算出hash值，取余

5、多字段的组合分片设置，两者区别？

复合分片键：
sh.shardCollection(“yourDatabase.sensorData”, { “deviceId”: 1, “timestamp”: 1 })；
适用场景：多维查询、时间序列数据
写入性能：可能会出现热点问题

哈希分片键：
sh.shardCollection(“yourDatabase.sensorData”, { “deviceId”: “hashed”, “timestamp”: 1 })；
适用场景：高写入频率、均匀分布
写入性能：对写入性能友好，数据均匀分布

组合索引创建：
一般还要创建组合索引 (deviceId，timestamp)；

6、MongoDB chunk和分片有什么区别

数据块（chunks）：MongoDB 将数据划分为多个块（chunks），每个块包含一个范围的数据。
分片功能启用时，分片服务器节点增加或减少时，涉及到chunk块的迁移，以便达到新的均衡分布。

7、造成jumboChunk原因？

一个最小的chunk只包含一个唯一的shardKey的记录数据，这样的chunk不可以再进行分裂。shardKey选择不合理才会产生jumboChunk。
合理选择shardKey是关键，尽量避免选择数据记录中值频繁出现的字段（例如设备ID）作为shardKey，可以加上时间戳，设置组合键(设备ID HASHED, TIMESTAMP)。

8、关联内容都塞到文档中，避免多次查询关联？

要注意文档过大问题，过大时需要拆分成多个集合存储。

9、mongoDB聚合分析

聚合函数统计， 分组求和、平均值等

10、全文检索

可分词在多个字段内进行检索，与Elasticsearch比较，检索较弱

11、MongoDB MapReduce

MapReduce提供了强大的数据处理能力，用户可以根据需要自定义Map和Reduce函数，处理复杂的数据聚合和分析任务；
MongoDB支持分布式MapReduce，能够在多台服务器上并行处理数据，提高处理效率；
不需要将数据导出到其他处理平台，可以直接在MongoDB中进行数据处理，减少了数据迁移的复杂性。

缺点：
尽管MapReduce可以处理大规模数据，但在某些情况下，性能可能不如其他数据处理方式（如聚合框架）；
自定义编写Map和Reduce函数有点复杂；
调试Map和Reduce函数可能比较困难。

12、TB级数据存储在副本集集群部署？

应该可以，看业务实际压测情况，不一定要分布式分片集群部署。