mongodb設(shè)計命名規(guī)范

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

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

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

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

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

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

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

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

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

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