MongoDB表的设计
5星 · 超过95%的资源 156 浏览量
2021-01-27
15:44:29
上传
评论
收藏 73KB PDF 举报 
MongoDB表的设计表的设计
1、Collection Sharding是否靠谱
Sharding key的一些烦恼；
单一key可能导致分布不均匀；
使用符合Sharding KEY
复合sharding key也不是万能的；
Count计算性不准确；
Balancer不够智能，时间不确定；
禁用Auto-Sharding功能不可靠（尤其是2.X版本）；
线上禁用Auto-Sharding
开启库级Sharding；
固定分片；
手动分片、分表；
完全控制并取得较好结果；
2、Free Schema真的Free吗？如何应对
Free Schema意味着重复的Schema；
每个文档都需要有Schema（重复存储的代价）；
Free Schema意味着ALL Schema，需要知道所有schema并且进行查询与解析；
尽量表中Schema都是固定的，将会大大简化程序复杂度；
尽可能减少字段名，数据存储压缩（字段名称都一样、压缩比高、zlib type compression、减少存储空间、减少访问压力）；
3、字段名如何进行选取
FreeSchema意味着重复存储，存储空间浪费；
字段名尽量短地存储；
1.6billion（243-183=60GB）；
减少字段名将会带来可读性的问题，应用层做字段的映射；
4、_id如何进行生成
collection级doc唯一标示，集合内部唯一；
文档主键，默认为12字节，24位的字符串，_id在服务器端生成；
在客户端生成合适的_id，例如IM用户可以使用unit64_t作为id；
在业务层统一生成（_id生成器，twitter snowflake保证生成唯一性）；
5、索引如何设计
原理：内存处理速度比硬盘快100倍，加快索引速度；
索引类型：唯一性索引（索引项的唯一），联合索引（支持前缀查询）；
返回某些字段，将这些字段都放在索引中；联合查询，支持前缀查询（前面的节点可以利用索引）；返回95%的集合文档，小
数据量索引建议使用索引；后台索引，background:true，不允许暂停数据库访问，可以在后台构建索引，仍然占用写锁，但
是会释放给业务读写操作；MongoDB对外读写性能会下降；
索引副作用，增、删、改的开销；
索引是否合理，explain+hint命令；
评论10
最新资源