MongoDB几个问题梳理和复盘过程是怎样的

发布时间:2021-09-29 11:35:10 作者:柒染
来源:亿速云 阅读:140

这篇文章给大家介绍MongoDB几个问题梳理和复盘过程是怎样的,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

工作中主要负责的系统主要以MongoDB数据库为主,开发过程中积累了一些经验和实际使用case,前一段时间把相关的场景整理了一下,组织了几篇文章。

当我尝试想把这些文发布到MongoDB中文社区时,与负责人沟通后,他们提出了一些文章中有待商榷和不严谨的地方,我在这里做一个梳理和复盘修正。

关于时间存储类型的选择

《MongoDB开发系列-从数据集合的设计开始 》中写到

时间可以直接定义为格式化的时间,便于识别和查询。不必特意存储时间戳,这样方便可视化的工具查询核对。

这里的格式化的时间有歧义,会被认为是时间字符串,比如(2019-07-03 19:10:11),我的本意是想表达使用ISODate类型的时间格式存储。

时间戳和时间格式两个数据类型的存储是一个选择问题,有的人习惯使用时间戳存储,有的人习惯用时间类型存储。

建议存时间戳的认为,时间转换成字符串很方便,字符串转换成时间很不方便。还有效率的问题。

字段语义化和字段映射

字段长度尽可能的短,不宜过长。也是考虑到内存优化。

原厂专家的建议是

实际并不存在长短的问题,因为有压缩,字段名这种重复的字段压缩后可以忽略

最开始我在考虑MongoDb是基于内存和key value形式的数据库,关于【命名规范,短字符的建议】这一条,我在官方和社区都没有找到正面的回应。

官方的文档大多是以小写命名做字段定义的,所以对于这个观点 我也是在逐步否定,或者说这种做法对内存的优化并不明显,反而牺牲了字段语意化,增加了开发字段映射和沟通成本。

MongoDB几个问题梳理和复盘过程是怎样的

官方文档示例

正常的做法是:按照驼峰或者全部小写的语义化命名即可

单文档宽度

注意这种情况下,切忌文档过宽。那如何避免这种情况,我的方法是预估最大字段数,以20个字段为节点,多于20则采用嵌套document的设计方式组织document。

这是工作中的设计经验,有不严谨的地方,容易误导读者。不应该有20的这个量化数据,我的本意是,如果一级属性太多,可以整理为二级嵌套字段,仅此而已。

关于MongoDB几个问题梳理和复盘过程是怎样的就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。

推荐阅读:
  1. Linux下的Mongodb部署应用梳理
  2. MongoDB库和集合管理是怎样的

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

mongodb

上一篇:如何实现smarty简单模板变量输出

下一篇:10段PHP常用代码编写方法教程

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》