文档介绍：MongoDB 设计命名标准
库
库名全部小写，制止使用任何`_`以外的特别字符，制止使用数字打头的库名，如：`123_abc`；
库以文件夹的形式存在，使用特别字符或其它不标准的命名方式会导致命名混乱；
数据库名最多为 64 字符写入到达
300/s 的时候 IO 跑满,排查中觉察,该业务在设计的时候为了便利, 而将_id 中写入了无序的类似 md5 的数据。MongoDB 的表与 InnoDB 相像,都是索引 组织表,数据内容跟在主键后,而_id 是 MongoDB 中的默认主键,一旦_id 的值为非自增,当数据量到达肯定程度之后,每一次写入都可能导致主键的二叉树大幅度调整,这将是一个代价极大的写入, 所以写入就会随着数据量的增大而下降,所以肯定不要在_id 中写入自定义的内容。
尽量不要让数组字段成为查询条件
某业务在一个表的数组字段上创立了一个索引,创立完毕之后觉察表体积
增大了很多很多,排查觉察是由于索引体积的大幅度增大导致在
MongoDB 中,假设为一个数组字段添加索引,那么 MongoDB 会主动为这个数组中的全部元素依次添加独立索引,例如: 为数组字段
{a:[x,y,z]}添加索引{a:1},实际上添加的索引为:
{a:[x:1]}
{a:[y:1]}
{a:[z:1]}
该业务的数组字段中有 11 个元素,那么等于一次创立了 11 条索引,这是索引体积大幅度增大的根本缘由。 另外,假设组合索引中存在数组字段, 那么 MongoDB 会为每一个元素与其它字段的组合创立一个独立的索引, 例如: 为数组字段{a:[x,y,z]}和{b:qqq}添加索引{a:1,b:1},实际上添加的索引为:
{a:[x:1],b:1}
{a:[y:1],b:1}
{a:[z:1],b:1}
假设一个组合索引中存在两个数组字段,那么索引的数量将是两个数组字段中元素的笛卡儿积,所以 MongoDB 不允许索引中存在一个以上的数组字段。
假设字段较大，应尽量压缩存放
某业务上线后始终很正常,但在放量 3 倍之后觉察 MongoDB 效劳器的网
卡流量报警,IO 压力报警,排查中觉察,该业务讲一个超长的文本字段存放在 MongoDB 中,而这个字段的平均体积到达了 7K。在并发为2000QPS 的场景下,每次取出 1~20 条数据,导致这个 MongoDB 每秒钟要发送将 近 100MB 的数据,而对于数据库而言,读写均为随机 IO,所以在如此大的数据吞吐场景中,IO 到达了报警阈值。
由于文本是一个简洁压缩的样本, 所以我们对该字段进展了压缩存放,使其平均体积降低到了 2K,而解压在业务端进展处理,最终将吞吐降低到了 20MB/S 左右。
假设字段较大且会成为查询条件，例如一长串的url，尽量转成 md5 后存放某业务上线前进展压力测试,测试中觉察某个场景下的查询性能不够理 想,排查中觉察该场景的查询条件类似:{url:xxxx},而 url 字段中的值大局部都很长很长,该字段的平均体积到达了 ,在这种状况下索引的体积会变得很大从而导致虽然恳求虽然能够走索引但效率并不够抱负,于是 dba 协作业务开发一起对该场景进展优化:
将该字段的存放的内容由真实的url 改为 url 内容 md5 后的值,字段体