1、MongoDB設(shè)計(jì)命名規(guī)范設(shè)計(jì)命名規(guī)范1.庫(kù)1.庫(kù)名全部小寫，禁止使用任何`_`以外的特殊字符，禁止使用數(shù)字打頭的庫(kù)名，如：`123_abc`；2.庫(kù)以文件夾的形式存在，使用特殊字符或其它不規(guī)范的命名方式會(huì)導(dǎo)致命名混亂；3.數(shù)據(jù)庫(kù)名最多為64字符；4.在創(chuàng)建新的庫(kù)前應(yīng)盡量評(píng)估該庫(kù)的體積、QPS等，提前與DBA討論是應(yīng)該新建一個(gè)庫(kù)還是專門為該庫(kù)創(chuàng)建一個(gè)新的集群某開(kāi)發(fā)在拿到DBA提供的MongoDB后由于MongoDB的權(quán)限控制比較寬松導(dǎo)致

2、該業(yè)務(wù)的開(kāi)發(fā)在創(chuàng)建集合的時(shí)候懶得與DBA討論而是隨意的將所有集合都創(chuàng)建在一個(gè)庫(kù)中最初并沒(méi)有什么問(wèn)題因?yàn)闃I(yè)務(wù)的請(qǐng)求量并不大。半年后該業(yè)務(wù)增長(zhǎng)到了一個(gè)比較大的量級(jí)而此時(shí)開(kāi)發(fā)人員上線了一個(gè)新的項(xiàng)目該項(xiàng)目的寫入量很大大部分都為批量更新由于所有集合都存放在一個(gè)庫(kù)中這個(gè)新項(xiàng)目的批量更新帶來(lái)了頻繁的鎖、IO平均等。最后開(kāi)發(fā)配合DBA一起將該庫(kù)拆散到了多個(gè)新的庫(kù)中將一庫(kù)N集合轉(zhuǎn)換為單庫(kù)單集合性能問(wèn)題迎刃而解。2.集合1.集合名全部小寫，禁止使用任何`_

3、`以外的特殊字符，禁止使用數(shù)字打頭的集合名，如：`123_abc`，禁止system打頭system是系統(tǒng)集合前綴；2.集合名稱最多為64字符；3.一個(gè)庫(kù)中寫入較大的集合會(huì)影響其它集合的讀寫性能，如果業(yè)務(wù)比較繁華的集合在一個(gè)DB中，建議最多80個(gè)集合，同時(shí)也要考慮磁盤IO的性能；4.如果評(píng)估單集合數(shù)據(jù)量較大，可以將一個(gè)大表拆分為多個(gè)小表，然后將每一個(gè)小表存放在獨(dú)立的庫(kù)中或者sharding分表；5.MongoDB的集合擁有“自動(dòng)清理過(guò)期

4、數(shù)據(jù)”的功能，只需在該集合中文檔的時(shí)間字段增加一個(gè)TTL索引即可實(shí)現(xiàn)該功能，但需要注意的是該字段的類型則必須是mongoDate()，一定要結(jié)合實(shí)際業(yè)務(wù)設(shè)計(jì)是否需要；6.設(shè)計(jì)輪詢集合集合是否設(shè)計(jì)為Capped限制集，一定要結(jié)合實(shí)際業(yè)務(wù)設(shè)計(jì)是否需要；7.創(chuàng)建集合規(guī)則不同的業(yè)務(wù)場(chǎng)景是可以配置進(jìn)行不同的配置a.如果是讀多寫少的表在創(chuàng)建時(shí)我們可以盡量將pagesize設(shè)置的比較小，比如16KB，如果表數(shù)據(jù)量不太大(“internal_page_

5、max=16KB，leaf_page_max=16KB，leaf_value_max=8KB，os_cache_max=1GB“b.如果這個(gè)讀多寫少的表數(shù)據(jù)量比較大，可以為其設(shè)置一個(gè)壓縮算法，例如：“block_compress=zlib，internal_page_max=16KB，leaf_page_max=16KB，leaf_value_max=8KB“c.注意：該zlib壓縮算法不要使用，對(duì)cpu消耗特別大，如果使用snapp消

6、耗20%cpu，而且使用zlib能消耗90%cpu，甚至100%d.如果是寫多讀少的表，可以將leaf_page_max設(shè)置到1MB，并開(kāi)啟壓縮算法，也可以為其制定操作系統(tǒng)層面pagecache大小的該業(yè)務(wù)的數(shù)組字段中有11個(gè)元素那么等于一次創(chuàng)建了11條索引這是索引體積大幅度增大的根本原因。另外如果組合索引中存在數(shù)組字段那么MongoDB會(huì)為每一個(gè)元素與其它字段的組合創(chuàng)建一個(gè)獨(dú)立的索引例如:為數(shù)組字段a:[xyz]和b:qqq添加索引a

7、:1b:1實(shí)際上添加的索引為:a:[x:1]b:1a:[y:1]b:1a:[z:1]b:1如果一個(gè)組合索引中存在兩個(gè)數(shù)組字段那么索引的數(shù)量將是兩個(gè)數(shù)組字段中元素的笛卡兒積所以MongoDB不允許索引中存在一個(gè)以上的數(shù)組字段。5.如果字段較大，應(yīng)盡量壓縮存放某業(yè)務(wù)上線后一直很正常但在放量3倍之后發(fā)現(xiàn)MongoDB服務(wù)器的網(wǎng)卡流量報(bào)警IO壓力報(bào)警排查中發(fā)現(xiàn)該業(yè)務(wù)講一個(gè)超長(zhǎng)的文本字段存放在MongoDB中而這個(gè)字段的平均體積達(dá)到了7K。在并發(fā)

8、為2000QPS的場(chǎng)景下每次取出1~20條數(shù)據(jù)導(dǎo)致這個(gè)MongoDB每秒鐘要發(fā)送將近100MB的數(shù)據(jù)而對(duì)于數(shù)據(jù)庫(kù)而言讀寫均為隨機(jī)IO所以在如此大的數(shù)據(jù)吞吐場(chǎng)景中IO達(dá)到了報(bào)警閾值。由于文本是一個(gè)容易壓縮的樣本所以我們對(duì)該字段進(jìn)行了壓縮存放使其平均體積降低到了2K而解壓在業(yè)務(wù)端進(jìn)行處理最終將吞吐降低到了20MBS左右。如果字段較大且會(huì)成為查詢條件，例如一長(zhǎng)串的url，盡量轉(zhuǎn)成md5后存放某業(yè)務(wù)上線前進(jìn)行壓力測(cè)試測(cè)試中發(fā)現(xiàn)某個(gè)場(chǎng)景下的查詢性

9、能不夠理想排查中發(fā)現(xiàn)該場(chǎng)景的查詢條件類似:url:xxxx而url字段中的值大部分都很長(zhǎng)很長(zhǎng)該字段的平均體積達(dá)到了0.5K在這種情況下索引的體積會(huì)變得很大從而導(dǎo)致雖然請(qǐng)求雖然能夠走索引但效率并不夠理想于是dba配合業(yè)務(wù)開(kāi)發(fā)一起對(duì)該場(chǎng)景進(jìn)行優(yōu)化:1.將該字段的存放的內(nèi)容由真實(shí)的url改為url內(nèi)容md5后的值字段體積得到了大幅度縮小固定在了32位2.查詢時(shí)用戶請(qǐng)求通過(guò)url查詢而此時(shí)程序會(huì)將該url進(jìn)行md5然后用得到的值進(jìn)行查詢由于所以

10、體積大幅度縮小所以查詢速度有了極大的提高優(yōu)化完畢后再次進(jìn)行壓力測(cè)試性能達(dá)標(biāo)為之前的6倍。6.由于MongoDB是大小寫敏感的，如果字段無(wú)需大小寫敏感，為了提高查詢效率應(yīng)盡量存放統(tǒng)一了大小寫后的數(shù)據(jù)，如：全部小寫或?yàn)樵撟侄卧黾右粋€(gè)統(tǒng)一了大小寫的輔助字段；某業(yè)務(wù)需要根據(jù)字段a:XxX來(lái)進(jìn)行查詢?cè)贛ongoDB中a的值是大小寫敏感的并且無(wú)法配置為忽略大小寫但該業(yè)務(wù)場(chǎng)景為了滿足查詢需求而需要忽略大小寫這個(gè)大小寫敏感與否的矛盾導(dǎo)致業(yè)務(wù)需要使用正則