网站建设需求分析的实施,网站设计建设公司,建设银行贵阳银行下载官方网站,wordpress 简书风格MongoDB#xff0c;常用的NoSql数据库#xff0c;在https://db-engines.com/en/ranking 里被分类为文档型数据库。本文从以下五个方面来了解MongoDB (和上一篇一样#xff0c;基础操作请查询官方文档或者菜鸟教程#xff09;使用场景存储引擎性能测试索引-B树分片与复制1…MongoDB常用的NoSql数据库在https://db-engines.com/en/ranking 里被分类为文档型数据库。本文从以下五个方面来了解MongoDB (和上一篇一样基础操作请查询官方文档或者菜鸟教程使用场景存储引擎性能测试索引-B树分片与复制1.使用场景一个业务系统的搭建什么情况下用关系型数据库MySql又在什么情况下用文档型数据库MongoDB呢在回答这个问题之前先来了解一下MongoDB与关系型数据库的几个显著区别。在MongoDB的自述中抽取出个人认为重要的两个点https://www.mongodb.com/nosql-explained1. Dynamic Schemas动态的数据结构MySql需要先定义好一张表的字段然后每个字段的值才能被插入MongoDB不用预先定义字段和数据类型可以随时动态插入新增的字段。对于一个不断变化发展的业务数据定义也必然是变化发展的因此一个灵活可变的数据结构才能较好的应对。比如社交类软件每一次的改版后台的数据结构都有相应的变化。2. Auto-sharding自动分片数据库层面原生的水平分库分表方案对于海量数据不用人为的去做分库分表操作。基本原理如下图所示图片来自MongoDB官网。基于以上两个特点不难看出在什么情况下需要使用MongoDB。遇到经常变化的数据需求。产品今天提需求要支持每个用户设定3个兴趣爱好明天起床觉得3这个数貌似不是自己的幸运数字啊还是改为7个兴趣爱好吧后天老板说我有8个爱好怎么办产品又默默的改了需求。如果用MySql来存储相信DBA会默默的准备麻袋和棍棒。所以一般不经常变的个人数据存在MySql里例如生日、姓名、籍贯当然还有性别。而经常变化的数据通过userid关联到MongoDB里存储比如头像、自我介绍、兴趣爱好可能、也许、应该还有婚姻状况。海量数据例如日志。其实MongoDB的使用场景在官网的用户案例里已经给出了很多答案百度在什么场景用MongoDB信息图片分享百度云百度地图社交论坛用户行为日志。奇虎呢基于地理位置信息的移动搜索与结果分发单点登录信息的缓存The user’s SSO session is cached in MongoDB for ultra-fast access. MongoDB supports millions of concurrent users, handling 30,000 operations per second and 1.8 billion queries daily. 关于性能在本篇第3部分中阐述日志分析平台。还有很多其他公司的应用实例大家可以访问下面这个链接获取信息。https://www.mongodb.com/mongodb-scale最常用的几个场景还是文档LBS相关的地理位置信息日志。这几个场景的共同特点数据量大需要经常查询。2.存储引擎MongoDB 4.x版本有两个常用的存储引擎关于存储引擎的概念请参看上一篇文章 CTO之瞳-数据库-MySql1. WiredTiger默认引擎也是社区版免费版唯一支持的引擎。从下图图片来自MongoDB官网可以看出WT引擎在内存中分了两个缓存区域一个是没做数据压缩的WT Cache另一个是做了数据压缩的FS Cache查询的顺序是先去WT Cache没有命中再去FS Cache最后再去磁盘而存进磁盘的数据都是压缩过的默认压缩。2. In-Memory企业版才支持的引擎看名字就想象的出所有的数据是存在内存中的目的是为了避免硬盘I/O操作提升性能。缺点也很明显一旦关机或重启所有数据都会丢失。看到这里始终想不明白In-Memory引擎的用途直到看见了MongoDB的又一特性Replication复制才秒懂。Replication类似于MySql Router机制。试想一下如果把Master设为In-Memory模式而数据持久化到Slave上读写不经过硬盘性能是何其的强劲或者把一台slave设为高频数据的专用读取源比如用户token这个访问性能也一定是杠杠的。猜想第1节里奇虎案例提到的性能参数 (MongoDB supports millions of concurrent users, handling 30,000 operations per second and 1.8 billion queries daily)就是通过使用In-Memory引擎实现的。对于In-Memory引擎的使用场景在第5节-分片与复制里再详述。3.性能测试测试环境MongoDB 4.2, Windwos社区版, WT engineIDEA 2019Windows10i7-9700F, 8G内存, 东芝固态硬盘代码访问路径https://gitlab.com/ctoeyes/mongodbDatabasetestCollectionWiredTiger为了和上一篇MySql的测试结果比对MongoDB的数据表设计如下实验一单线程连续插入5w条数据数据和MySql测试案例保持一致。实验二单线程连续查询1w次每次以_id列作为查询条件索引查询。实验三单线程连续查询1w次每次以D列作为查询条件非索引查询。实验四查看数据占用空间大小。实验结果如下和上一篇MySql的结果比对如下插入速度MongoDB 4.2支持事务与同样支持事务处理的MySql-InnoDB比较性能是较优的。索引列查询速度MongoDB劣于MySql的两个引擎这可能与MongoDB的索引采用B树的数据结构而MySql索引采用B树数据结构有关详细的在下一节“索引-B树”里讨论。非索引列查询速度MongoDB也明显慢于MySql原因是否和MongoDB的数据默认压缩后再存进磁盘有关查询前要解压缩有一定耗时。占用空间MongoDB占优。4.索引-B树MongoDB索引采用的数据结构是B树以上一篇MySql里相同的数据表为例画一下在MongoDB里的数据结构。这些数据长成这样回顾上一篇MySql InnoDB引擎的B树可以发现两者有两个很明显的区别1. B树只有最下层的叶子节点保存数据其他节点只保存关键字而B树每一层节点均保存数据。因此单一数据查询B树必须查到最下一层而B树只有在最坏情况下需要查询到最下层。但第3节的实验结果明明索引查询是MySql的B树胜出为什么个人猜测未必正确因为B树的非叶节点不保存数据空间占用小而被缓存在内存中这样访问速度快B树的非叶节点因为保存数据空间占用大有些存在磁盘里因而访问速度慢。2. B树每个相邻的叶子节点有指针连接而B树没有。因此范围查询B树更有优势。思考如果把Seat No也设为索引数据应该长什么样此时B树只有叶子节点保存数据的优势就体现出来了5.分片与复制分片Sharding与复制Replication是MonoDB的两种扩展方式前文也提到过。分片实质是一种水平方向上的分库分表主要目的是为了增大容量、提升性能。第1节里的示意图一目了然不再重复。复制类似于MySql Router主要目的是数据备份、故障热切换、读写分离。而第2节里提到的In-Memory引擎用在复制模式里也可以帮助提升性能看下图图片来自MongoDB官网。如果把右边的secondary DB设为读操作的默认DB同时设定它使用In-Memory引擎那么一些常用的数据读取会极大的提速。当然这种情况下需要保证最少两台secondary。为什么呢试想如果只有一台secondary且是In-Memory模式此时primary挂了secondary自动接替为primary然后它也宕机了那么primary切换后写入的数据就会全部丢失。这时咋办赶紧回家卷铺盖跑路吧 ^^如果把primary设为In-Memory模式读写都通过primary而数据持久化到secondary中那么读写性能都可以得到极大的提升。了解了分片与复制机制后想到一个问题这两种方式能不能放到一起用也就是既要分表扩容又要数据备份与故障热切换。仔细看了下MondoDB的官网其实已经给出了答案看下图图片来自MongoDB官网。在介绍Sharding架构的图中已经明确标明了红色圈圈每一台Shard DB和Config Server都可以是一组Replica集群。所以对于小型业务一台Primary一台Secondary的Replication方式即可满足业务需求。对于中大型业务采用Sharding Replication的矩阵组合基本也可满足业务需求。MongoDB就聊到这里依然是九牛一毛关键是思考另外官方文档仔细看有很多有价值的信息可以挖掘。下一篇开始说说后端体系坑中坑头大现在觉得B坑的一年之约太乐观了。
