为什么我们选择了MongoDB？

我司是一家正处于高速发展，目前拥有数百万用户，年销售额近五十亿的社交电商公司。

图片来自 Pexels

公司技术部建立之初，为了适应用户量的高速增长，与业务的不断变更迭代，在选用数据库的时候，经过调研对比我们选择了 MongoDB。

是的，你没看错，All in MongoDB!

本文将围绕如下几个部分进行分享：

• 为什么使用 MongoDB(选择数据的时候我们是怎么考虑的?)
• MongoDB 架构(99.99% 高可用，晚上安心睡大觉!)
• MongoDB 分片(海量数据应对之道!)
• MongoDB 文档模型介绍(灵活!灵活!灵活!)

为什么使用 MongoDB

因为我司主要做社交电商的业务，所以对数据库的性能有一定的要求，加上商品交易是公司主要盈利来源，所以对数据库的高可用也有一定的要求。

总结一下我们对数据库的要求：

• 安全，稳定
• 高可用
• 高性能

我们在考虑数据库选型的时候主要考虑什么?

• 数据规模
• 支持读写并发量
• 延迟与吞吐量

从数据规模来说订单和商品 SKU，还有会员信息这些重要的数据记录肯定会随着时间源源不断的增长。

所以我们需要的不仅仅是满足当下要求，更需要为半年一年后海量数据更为方便的扩容做考量!

下面我们从 MongoDB 的架构，性能，和文档模型来介绍一下我们选择 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 进行改进使用。

raft 算法动画演示：

http://thesecretlivesofdata.com/raft/ 

③关于超大规模复制集(集群)

Non-Voting Members

上图是一个拥有 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 个投票节点呢?参考上节的 raft 算法，节点越多，投票时间越长，选举出来的 Primary 节点时间也就越长，这个过程中我们是无法进行写操作的，因为没有主节点。

那么多非投票节点有什么用呢?大家应该都听过 MySQL 的读写分离吧，利用读写分离来提高数据库性能。

MongoDB 这里其实也可以，Primary 用来写，Secondary 用来读，可以给 BI 部门一个 Secondary，给财务部门一个 Secondary，给运营部门一个 Secondary······

④WriteConcern

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

有以下几种情况：

• 写 Primary 成功，返回客户端写成功，Secondary 还未同步 Primary 的时候，Primary 挂了，数据丢失!
• 写 Primary 成功，数据同步一个 Secondary 成功，返回客户端写成功。此时 Primary 挂了，数据不会丢失。但是恰好 Primary 与同步的 Secondary 同时挂了，数据丢失!
• 写 Primary 成功，数据同步两个 Secondary 成功，返回客户端写成功。此时 Primary 挂了，数据不会丢失。

我们对以上三种情况进行分析：

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

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

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

MongoDB 分片

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

• 数据库的性能还与数据库本身规模息息相关。拿关系型数据库举例：
• 查询百万表和千万表甚至过亿的表效率相差很大，查询性能急剧恶化。

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

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

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

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

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

MongoDB 中我们是如何做的呢?

③MongoDBSharding

MongoDB 的分片

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

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

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

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

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

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

分片的负载均衡

当我们的 MongoDB 副本集变成分片集群后，随着数据量的增长，各个分片也会越来越大。

这里就会出现两种情况：

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

当出现问题(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!

作者：唐银鹏

简介：开源爱好者、Gopher。从事电商、IM 系统深度研发，MongoDB 爱好者，公众号《从菜鸟到大佬》作者。

编辑：陶家龙

出处：转载自微信公众号Mongoing 中文社区(ID：mongoing-mongoing)，本文是唐银鹏在“青芒话生长”MongoDB征文比赛的获奖文章。