mongoDB学习要点回顾
- 1、哪些mongoDB相关文章介绍不错？
- 2、mongoDB数据库默认开启分片功能吗？
- 3、分片键如何选择？
- 4、分片策略
- 5、多字段的组合分片设置，两者区别？
- [6、MongoDB chunk和分片有什么区别](#6、MongoDB chunk和分片有什么区别)
- 7、造成jumboChunk原因？
- 8、关联内容都塞到文档中，避免多次查询关联？
- 9、mongoDB聚合分析
- 10、全文检索
- [11、MongoDB MapReduce](#11、MongoDB MapReduce)
- 12、TB级数据存储在副本集集群部署？
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级数据存储在副本集集群部署？
应该可以，看业务实际压测情况，不一定要分布式分片集群部署。