我选MongoDB 中台数据库设计 毅然丢弃MySQL

本文关键讲述 vivo 评论中台在数据库设计上的技术探求和通常。

一、业务背景

随着公司业务开展和用户规模的增多，很多名目都在打造自己的评论性能，而评论的业务外形基本相似。过后各名目都是各自设计成功，存在较多重复的上班量;并且不同业务之间数据存在孤岛，很难发生咨询。因此咱们选择打造一款公司级的评论业务中台，为各业务方提供评论业务的极速接入才干。在经过对各大干流APP 评论业务的竞品剖析，咱们发现大局部评论的业务外形都具有评论、回复、二次回复、点赞等性能。

详细如下图所示：

触及到的外围业务概念有：

二、数据库存储的选择

团队在数据库选型设计时，对比了多种干流的数据库，最终在 MySQL 和 MongoDB 两种存储之启动抉择。

由于评论业务的不凡性，它须要如下才干：

而评论业务不触及用户资产，对事务的要求性不高。因此咱们选择了 MongoDB 集群 作为最底层的数据存储形式。

三、深化了解 MongoDB

1.集群架构

由于单台机器存在磁盘/IO/CPU等各方面的瓶颈，因此以 MongoDB 提供集群形式的部署架构，如图所示:

关键由以下三个局部组成：

2.片键

MongoDB 数据是存在collection(对应 MySQL表)中。集群形式下，collection依照 片键(shardkey)拆分红多个区间，每个区间组成一个chunk，依照规定散布在不同的shard中。并构成元数据注册到config服务中治理。

分片键只能在分片汇合创立时指定，指定后不能修正。分片键关键有两大类型：

3.评论中台的通常

1)集群的裁减

作为中台服务，关于不同的接入业务方，经过表隔离来辨别数据。以comment评论表举例，每个接入业务方都单独创立一张表，业务方A表为comment_clientA ，业务方B表为 comment_clientB，均在接入时创立表和相应索引消息。但只是这样设计存在几个疑问：

单个集群，不能满足局部业务数据物理隔离的须要。

集群调优(如split迁徙时期)很难业务个性差异化设置。

水平扩容带来的单个业务方数据过于扩散疑问。

因此咱们裁减了 MongoDB的集群架构：

裁减后的评论MongoDB集群 参与了 【逻辑集群】和【物理集群】的概念。一个业务方属于一个逻辑集群，一个物理集群蕴含多个逻辑集群。

参与了路由层设计，由运行担任裁减Spring的MongoTemplate和衔接池治理，成功了业务到MongoDB集群之间的切换选择服务。

不同的MongoDB分片集群，成功了物理隔离和差异调优的或者。

2)片键的选择

MongoDB集群中，一个汇合的数据部署是扩散在多个shard分片和chunk中的，而咱们宿愿一个评论列表的查问最好只访问到一个shard分片，因此确定了范畴分片 的形式。

后来设置只经常使用单个key作为分片键，以comment评论表举例，关键字段有{"_id":惟一id,"topicId":主题id,"text":文本内容,"createDate":时期},思索到一个主题id的评论尽或者延续散布，咱们设置的分片键为 topicId。随着性能测试的参与，咱们发现了有两个十分致命的疑问：

jumbo chunk疑问

惟一键疑问

jumbo chunk：

举例，若咱们设置1024M为一个chunk的大小，单个document5KB计算，那么单个chunk能够存储21W左右document。思索热点的主题评论(如微信评论)，评论数或者到达40W+，因此单个chunk很容易超越1024M。超越最大size的chunk依然能够提供读写服务，只是不会再启动决裂和迁徙，短暂以往会形成集群之间数据的不平衡。

惟一键疑问：

4.迁徙和扩容

随着数据的写入，当单个chunk中数据大小超越指定大小时(或chunk中的文件数量超越指定值)。MongoDB集群会在拔出或更新时，智能触发chunk的拆分。

拆分会造成汇合中的数据块散布不平均，在这种状况下，MongoDBbalancer组件会触发集群之间的数据块迁徙。balancer组件是一个治理数据迁徙的后盾进程，假设各个shard分片之间的chunk数差异超越阈值，balancer会启动智能的数据迁徙。

balancer是可以在线对数据迁徙的，然而迁徙的环节中关于集群的负载会有较大影响。普通倡导可以经过如下设置，在业务低峰时启动(更多见官方)

MongoDB的扩容也十分繁难，只有要预备好新的shard复制集后，在 Mongos节点中口头：

扩容时期由于chunk的迁徙，雷同会造成集群可用性降落，因此只能在业务低峰启动

四、写在最后

MongoDB集群在评论中台名目中已上线运转了一年多，环节中成功了约10个业务方接入，承载了1亿+评论回双数据的存储，体现较为稳固。BSON非结构化的数据，也撑持了咱们多个版本业务的极速更新。而抢手数据内存化存储引擎，较大地提高了数据读取的效率。

但关于MongoDB来说，集群化部署是一个无法逆的环节，集群化后也带来了索引，分片战略等较多的限度。因此普通业务在经常使用MongoDB时，正本集形式就能撑持TB级别的存储和查问，并非必定须要经常使用集群化形式。

以上内容基于MongoDB 4.0.9版本个性，和最新版本的MongoDB细节上略有差异。