MongoDB幾個問題梳理和復(fù)盤過程是怎樣的

這篇文章給大家介紹MongoDB幾個問題梳理和復(fù)盤過程是怎樣的，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

工作中主要負(fù)責(zé)的系統(tǒng)主要以MongoDB數(shù)據(jù)庫為主，開發(fā)過程中積累了一些經(jīng)驗(yàn)和實(shí)際使用case，前一段時間把相關(guān)的場景整理了一下，組織了幾篇文章。

當(dāng)我嘗試想把這些文發(fā)布到MongoDB中文社區(qū)時，與負(fù)責(zé)人溝通后，他們提出了一些文章中有待商榷和不嚴(yán)謹(jǐn)?shù)牡胤剑以谶@里做一個梳理和復(fù)盤修正。

關(guān)于時間存儲類型的選擇

《MongoDB開發(fā)系列-從數(shù)據(jù)集合的設(shè)計(jì)開始 》中寫到

時間可以直接定義為格式化的時間，便于識別和查詢。不必特意存儲時間戳，這樣方便可視化的工具查詢核對。

這里的格式化的時間有歧義，會被認(rèn)為是時間字符串，比如（2019-07-03 19:10:11），我的本意是想表達(dá)使用ISODate類型的時間格式存儲。

時間戳和時間格式兩個數(shù)據(jù)類型的存儲是一個選擇問題，有的人習(xí)慣使用時間戳存儲，有的人習(xí)慣用時間類型存儲。

建議存時間戳的認(rèn)為，時間轉(zhuǎn)換成字符串很方便，字符串轉(zhuǎn)換成時間很不方便。還有效率的問題。

字段語義化和字段映射

字段長度盡可能的短，不宜過長。也是考慮到內(nèi)存優(yōu)化。

原廠專家的建議是

實(shí)際并不存在長短的問題，因?yàn)橛袎嚎s，字段名這種重復(fù)的字段壓縮后可以忽略

最開始我在考慮MongoDb是基于內(nèi)存和key value形式的數(shù)據(jù)庫，關(guān)于【命名規(guī)范，短字符的建議】這一條，我在官方和社區(qū)都沒有找到正面的回應(yīng)。

官方的文檔大多是以小寫命名做字段定義的，所以對于這個觀點(diǎn) 我也是在逐步否定，或者說這種做法對內(nèi)存的優(yōu)化并不明顯，反而犧牲了字段語意化，增加了開發(fā)字段映射和溝通成本。

官方文檔示例

正常的做法是：按照駝峰或者全部小寫的語義化命名即可

單文檔寬度

注意這種情況下，切忌文檔過寬。那如何避免這種情況，我的方法是預(yù)估最大字段數(shù)，以20個字段為節(jié)點(diǎn)，多于20則采用嵌套document的設(shè)計(jì)方式組織document。

這是工作中的設(shè)計(jì)經(jīng)驗(yàn)，有不嚴(yán)謹(jǐn)?shù)牡胤剑菀渍`導(dǎo)讀者。不應(yīng)該有20的這個量化數(shù)據(jù)，我的本意是，如果一級屬性太多，可以整理為二級嵌套字段，僅此而已。

關(guān)于MongoDB幾個問題梳理和復(fù)盤過程是怎樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。