MongoDB从入坑到入迷思维导图模板_ProcessOn思维导图、流程图

为什么要用MongoDB

诉求

安全、稳定

高可用

高性能

如何选型

数据规模

支持读写并发量

延迟与吞吐量

公司背景

公司电商业务，对数据库性能有一定要求，加上商品交易是公司重要盈利来源，所以对数据库对高可用要求很高

从数据规模来看，订单和商品sku，还有会员信息这些重要对数据记录 肯定会随着事件源源不断增加，所以不仅要满足当前需求，还要为半年或者一年后海量数据 做扩展打下基础。

从架构、性能和文档模型来介绍我们选择mongodb的理由

MongoDB架构

关于高可用

数据库作为系统核心，要保证99.99%的可用性，而高可用的保证来自于MongoDB冗余数据的复制集模式。MongoDB自带多副本高可用，只需要合理的配置，就能避免单数据库节点故障导致服务的不可用。

图例说明： 一个Primary主节点，主要接受来自server的读写； 两个Secondary从节点，用于同步来自Primary的数据。

关于高可用：当主节点发生故障的时候，两个从节点会进行选举，投票产生一个新的主节点，进而保证服务的可用性。 （PS：在选举过程中数据不可写入，但是如果Secnondary节点配置可读，那么此时是可以读取数据的。） 这就是MongoDB的高可用，配置简单，不需要引入额外的中间件或者插件去辅助数据库节点间的故障转移。

关于选举算法《分布式一致性算法---raft》

raft协议是在leader节点发生故障或者网络分区导致脑裂时如何保证分布式数据一致性的一个算法， MongoDB采用了该算法来保证当主节点故障或者网络分区的情况下，数据的一致性。 当然MongoDB用的和raft原版算法肯定会略有不同，MongoDB会采用Secondary向Primary拉数据， 而不是Primary向Secondary推数据的方式来减轻Primary的压力等等有利于数据库操作的方式对raft进行改进使用。

关于超大规模复制集（集群）

上图是一个拥有7个可投票从节点，一个主节点，两个不可投票从节点。

{ "_id" : <num>, "host" : <hostname:port>, "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 0, // 设置为0 "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 0 // 设置为0 }

MongoDB最多允许50个节点，但是最多只有7个节点有投票权， 一个节点可以配置7个无投票权的Non-Voting节点，加上一个Primary节点。

为什么只能允许存在7个投票节点呢？参考2.2小节的raft算法，节点越多， 投票时间越长，选举出来的Primary节点时间也就越长，这个过程中我们是无法进行写操作的，因为没有主节点。

那么多非投票节点有什么用呢？大家应该都听过MySQL的读写分离吧，利用读写分离来提高数据库性能。 MongoDB这里其实也可以，Primary用来写，Secondary用来读，可以给BI部门一个Secondary，给财务部门一个Secondary， 给运营部门一个Secondary······

WriteConcern

既然我们的数据库拥有至少超过三个节点（1Primary+2Secondary），Secondary通过同步Primary的数据来保持一致性，那么当我们写操作的时候，如何保证数据安全的落盘呢？

子主题

有以下几种情况： 1. 写Primary成功，返回客户端写成功，Secondary还未同步Primary的时候，Primary挂了，数据丢失！ 2. 写Primary成功，数据同步一个Secondary成功，返回客户端写成功。此时Primary挂了，数据不会丢失。    但是恰好Primary与同步的Secondary同时挂了，数据丢失！ 3. 写Primary成功，数据同步两个Secondary成功，返回客户端写成功。此时Primary挂了，数据不会丢失。

我们对以上三种情况进行分析：第一种情况有风险会造成数据丢失。 第二种情况还是会出现数据丢失，但是数据丢失的概率大大降低。 第三种情况是最安全的做法，但是节点数目多了，同步非常耗时，用户需要等待的时间过长，一般不考虑。

MongoDB在这里推荐折衷方案就是使用Write Concern---在数据可靠性与效率之间的权衡！

db.products.insert( { item: "envelopes", qty : 100, type: "Clasp" }, { writeConcern: { w: "majority" , wtimeout: 5000 } } // 设置writeConcern为majority，超时时间为5000毫秒 )

MongoDB分片

大规模数据是如何影响数据库效率的？

数据库的性能还与数据库本身规模息息相关。拿关系型数据库举例：

1、查询百万表和千万表甚至过亿的表效率相差很大，查询性能急剧恶化。

2、插入的时候创建索引可能会引起索引树的调整与页分裂。

面对海量数据如何提升数据读写效率？

为了在海量数据中提升数据库的效率，我们采用分而治之的思想，将大表拆成小表，大库拆成小库。

关系型数据库中我们常用分表分库来解决：

1、例如将订单库分为在线库和离线库，近三个月是在线库，远期的订单数据放入离线库，这样在线库的数据就大大减少，数据库性能就得到了提升。 2、又例如当我们的用户量过多超过千万行记录，单表查询效率下降，我们将一张用户表拆成多张用户表，这个就是水平拆分。

MongoDB中我们是如何做的呢？

MongoDBSharding

通过将同一个集合（Collection1）的数据按片键（shard keys）分到不同的分片（shard）上面， 减少同一个数据文件上的数据量，已达到拆分数据规模的目的。

Shard 优势：在线扩容，动态扩容

Shard：用于存储实际的数据块，实际生产环境中一个shard server角色可由几台机器组个一个replica set承担，防止主机单点故障。

Config Server：配置服务器 mongod实例，存储了整个集群的元数据与配置，其中包括 chunk信息，在MongoDB 3.4中，配置服务器必须部署为一个副本集。

Mongos：mongos充当查询路由器，提供客户端应用程序和切分集群之间的接口。

服务器插入的数据通过Mongos路由到具体地址，这也是MongoDB的便利之处，不需要自己关注路由，也不需要使用第三方提供的中间件辅助路由，可靠，放心。

分片的负载均衡

当我们的MongoDB 副本集变成分片集群后，随着数据量的增长，各个分片也会越来越大，这里就会出现两种情况：

1. 冷热数据，某个分片数据量过大。 2. 数据总量大，分片集群的分片过大。

当出现问题（1）的时候，MongoDB的负载均衡器（Balancer）会自动将大分片中的数据迁往小分片。 注意这并不意味我们可以高枕无忧了，恰恰相反，我们应该反思是不是自己片键选择失误而造成的数据不均匀！ 因为对分片迁移也是消耗性能的，应用服务器写一次到Shard B，然后Shard B重写到Shard C无形之中数据被写了两次，这是极大的浪费！ 当出现问题（2）的时候，当然是给过大的分片集合添加新的分片以此分摊分片集群的压力。 注意：MongoDB分片虽然是可在线的，但是多少都会对正常的读写操作性能有一定的影响，建议在非繁忙时间段进行分片部署！

MongoDB文档模型介绍

数据库建模的挑战在于平衡应用的需要，适合该数据库引擎发挥的结构以及数据的检索模式。 当我们设计数据模型的时候，需要考虑应用使用数据的情况（查询，更新，和数据处理）以及该数据本身的结构。

灵活的Schema

在关系型数据库中，必须按照确定的表结构去插入数据。 但是，由于MongoDB是文档型数据库，在插入数据的时候默认并不对此做要求。其表现在于： 同一个集合中不同文档不一定需要有相同的字段，并且字段类型也可以不同。 在集合中改变文档的结构，例如增加一个字段，删除一个字段，或者改变一个字段的类型，只需要对该文档更新即可。

举例1:N模型设计

在电商业务中，一个用户可能有多个收件人以及收件地址。 在关系型数据库中，我们需要建立联系人表，地址表，并且将其关联。 但是在MongoDB中，我们只需要一个集合就能将此搞定！ 数据关系如下：

// patron document { _id: "joe", name: "Joe Bookreader" } // address documents { patron_id: "joe", // reference to patron document street: "123 Fake Street", city: "Faketon", state: "MA", zip: "12345" } { patron_id: "joe", street: "1 Some Other Street", city: "Boston", state: "MA", zip: "12345" }

在MongoDB中我们可以这样进行设计：

{ "_id": "joe", "name": "Joe Bookreader", "addresses": [ { "street": "123 Fake Street", "city": "Faketon", "state": "MA", "zip": "12345" }, { "street": "1 Some Other Street", "city": "Boston", "state": "MA", "zip": "12345" } ] }

没错，以上就是集合中的一个document（文档），是不是感觉很灵活很方便！ 你可以在SKU集合中添加分类信息，或者商品标签，还可以在库存集合中冗余SKU的基本信息， 还可以在订单集合中冗余部分下单者信息···没错，就是这么灵活！ 这也是我们选择MongoDB的一个重要原因之一，让开发者的心智负担少了很多， 不需要成为SQL高手，你也能在MongoDB中写出性能优异的查询语句。

当然冗余一时爽，重构火葬场的段子也不是没听过，因为过多的冗余最终会造成数据的过于臃肿，性能降低等各种问题，这个要控制住开发者的冗余冲动，也依赖于团队技术Leader对此的把关。

总结

互联网业务不是一成不变的，产品和用户的需求还有市场都一直在变！我们没有技术实力打造一个能够适应灵活多变的业务的中台，但是目前我们可以选择一个可靠，强大并且灵活的数据库 -- MongoDB!