mongodb设计命名规范方案.doc

...wd...
...wd...
block_compressor=zlib 默认为snappy
internal_page_max=16KB 默认为4KB
leaf_page_max=16KB 默认为32KB
leaf_value_max=8KB 默认为64MB
文档
文档中的key制止使用任何`_`以外的特殊字符；
尽量将同样类型的文档存放在一个集合中，将不同类型的文档分散在不同的集合中；一样类型的文档能够大幅度提高索引利用率，如果文档混杂存放则可能会出现查询经常需要全表扫描的情况；
制止使用_id，如：向_id中写入自定义内容；
某业务的MongoDB在放量后出现严重的写入性能问题,大致为:写入到达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]}
...wd...
...wd...
...wd...
该业务的数组字段中有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压力报警,排查中发现,该业务讲一个超长的文本字段存放在Mo