朱晔的互联网架构实践心得S1E3：相辅相成的存储五件套

这里所说的五件套是指关系型数据库、索引型数据库、时序型数据库、文档型数据库和缓存型数据库。

上图显示了一套读写服务搭配这五种类型数据库的例子：

1. 这里只是说明了咱们能够这么来搭配这些类型的数据库，不是说咱们全部的应用都须要用到这些类型的数据库。

2. 同步写服务负责第一时间把重要的数据落地和落缓存。

3. 异步写服务经过监听MQ来感知数据的变化，而后从新读取最新的数据来把数据写入其它次要数据源，好比文档性数据库和索引型数据库，须要的话能够在缓存中回写一个状态。

4. 由一个专门的数据查询服务来根据需求作数据路由，根据需求和性能因素，从不一样的数据源读取数据。

5. 数据聚合服务根据需求从次要数据源进一步读取数据以时间维度进行聚合，聚合到时间序列数据库，供监控查询服务查询。

下面咱们来具体说说这些存储系统。

关系型数据库

毫无疑问，强事务性的数据写入MySQL之类的关系型数据库是最可靠的，搭配SSD盘的使用，关系型数据库也很容易达到万级的QPS。对于超大数据量加上超大并发的应用来讲，单表的数据量过千万伴随着数万的QPS很难以单体数据库来支撑，咱们须要对数据表进行Sharding分片处理，把数据按照必定的维度切分到好比128个数据表，而后分散在8套甚至16套数据集群，这样每一台MySQL的实例只须要承受1/8或1/16的请求压力并且数据量更小。随之带来的问题是，咱们须要对应用进行改造，使之只能按照必定的查询条件来查询这个切片后的表，若是不带条件或带任意条件的话，咱们是没法知道数据实际存储在哪一个表哪一个实例上的。

这确实是一个比较麻烦的地方，咱们的查询条件可能有十几个，只能按照一个维度来查询知足不了咱们的需求。一个折中的方式是咱们引入所谓的Index数据表，也就是在写入实际的完整数据到Sharding的数据表的同时，咱们把数据表里须要查询的字段写入一个专门的没有通过Sharding处理的Index数据表，这个数据表里存放的几乎没有varchar类型的数据，所有是各类bigint的各种业务ID或是tinyint类型的各类状态，以及时间。因为这个表很是亲，虽然数据条数多可是表空间几乎能够在数据库的缓存中容纳，性能会高很多。对于实时性要求很是强的基于条件的查询能够从这个数据表来进行查询。而Sharding后的数据只能用于按ShardKey来进行查询。

缓存数据库

Redis是最经常使用的分布式缓存解决方案，几乎在任何互联网应用中都会用到，特色是：

1. 能持久化数据，可是个人观点是缓存数据库仍是仅仅做为缓存的好，要可以承受丢失数据的风险，不然可能会死的比较难看。由于RDB或主从复制致使的一些事故也是层出不穷的。

2. 丰富的数据结构是必定要利用的，丰富的数据结构表明了能够依赖丰富的API在服务端作复杂的运算，性能比反序列化取出后运算再序列化存入效率高的多。有的时候甚至能够把这些数据结构和API组合在一块儿碰撞出绝妙的方案以极高效的方式实现一个高性能的业务逻辑。能够看看《Redis实战》一书。

3. 超高的性能（固然了，配合一些集群方案好比codis就更上一层楼了）足以抵挡任何业务请求的直接访问，不少时候缓存的方案挂是挂在由于各类各样的缘由穿透缓存而不是Redis档不住。

4. 丰富的集群和高可用方案以及各种各类实用的功能（管道、事务、Lua脚本），5.0的版本还推出了Stream特性来替代少有人关注的Disque值得关注。

因此Redis的应用也很普遍：

· 数据缓存

· 分布式锁

· 消息队列

· 服务端运算

在上图的架构中，咱们经过同步写服务对数据库和缓存进行双写，目的也就是为了让缓存中能有新鲜热数据，无论是对内仍是对外这种单条数据的查询能够直接路由到缓存。

文档型数据库

文档型数据库的表明就是耕耘多年的Mongodb，我在一些非重要业务的场景使用过Mongodb几回，个人评价以下（最近1年多没有碰过Mongodb，也可能评价有失偏颇）：

1. 超高的写入性能，很是不错的读取性能（和Redis是不能比的，性质不一样），数据量增多后可能会有很厉害的性能衰退，不是Hbase那种无底洞型的存储，不维护就往里面一直堆数据进去最后的性能可能好比MySQL。

2. 由于存的是文档，因此是弱结构的，存一些事先不能肯定的数据很是很是合适，并且之后要查的时候能够任何加索引对须要的数据进行搜索查询。一个很实用的场景就是做为爬虫的数据源，数据变化无穷并且不那么重要，并且写入性能很重要。

3. 不太可靠和稳定，可能会丢数据，强烈不建议做为核心数据存储，建议做为一个旁路数据库用在非关键的业务。好比在上图的架构图中，咱们可能会拿到核心数据后再从其它地方去补一些数据而后进行适当的加工，保存到Mongodb做为一个监控数据库或者面向后台的数据库来用（MEAN套件之一，能够想象对于简单的应用来讲配合脚本语言用起来多舒服了），挂了也就挂了，没挂的话能够分担不少MySQL的压力。

4. 玩法虽然多，什么Sharding、复制、集群都有，但随着数据量的增多运维多是一个大坑，极可能遇到集群全军覆没没法启动的状况，数据的恢复耗时很长。内存的使用至关疯狂，对硬件的使用总感受性价比不高。

索引型数据库

ElasticSearch做为其表明是最近几年的黑马。ELK集群各大互联网公司都有使用，只要集群配置得当，每秒几十万的写入不是大问题，毕竟完全的分布式化理论上能够有无限高的写入能力。ES的特色以下：

1. 很是丰富的查询API，不只仅是全文索引查询，普通的查询API丰富多样，组合起来能够在服务端完成各类业务逻辑，基本上SQL+MySQL能够实现的，ES查询均可以实现，并且还多了更强大的全文搜索。固然，查询的语法稍显晦涩确定没有SQL来的直挂。

2. 相似于Mongodb的schema-free，无需实现定义表结构。

3. 还算强大的写入和读取能力，固然，索引多的话写入文档的效率确定会下降。这也是图中对于ES的写入由专门的异步流程进行的缘由。

4. ES天生的分布式配置决定了，在写入亿、十亿的数据量以后，还能在至关能够接受的时间内（好比10秒）完成一个多条件复杂查询，对于MySQL这个量级下这样的查询可能须要10分钟甚至100分钟的时间来执行，彻底不能接受。

5. ES对嵌套型数据的查询支持不错，通过测试咱们倾向于把多标关联的数据做为一个大的嵌套的JSON拍扁了直接存入ES，好比咱们能够把用户我的惟独的基本信息+充值订单+提现订单+投资订单，一人一个JSON存进去，而后对于嵌套的下层JSON数据也是能够方便的利用查询API进行查询。

由于这些特色，在这个架构图上，咱们把ES也做为了查询服务的数据源，对于知足下面这些条件的查询，咱们能够走ES：

· 对数据延迟不敏感，能够接受一段时间查不到新鲜数据

· 查询特别复杂，或是全文搜索，不能走Sharding后的RouteKey，Index表也没法知足需求

· 查询的结果也不只仅是单表的数据而是比较丰富的数据，查询数据库须要查询多个表屡次

索引型数据库和文档型数据库的底层存储结构是大相径庭的，虽然如今有不少人使用ES来彻底替代Mongodb，可是我的以为ES适合存比Mongodb更大的一个数据量，分布式不利用起来发挥不了ES，Mongodb仍是适合中型数据非Sharding的存储。

时序型数据库

InfluxDb是时序型数据库的表明。对于按照时间段进行Group By查询的话，无论是ES仍是MySQL仍是Mongodb在API层面固然都是支持的，可是查询效率不堪入目。所以对于诸以下面的需求首当其中能够考虑时序型数据库：

· 监控图表

· 按时间维度聚合

· 查询的时间维度能够跨度很长

· 须要按期归档

若是使用传统方案的话，咱们每每会以固定的时间维度来聚合保存数据，若是咱们要查1小时和1年的维度，都使用5秒的聚合粒度显然不合适，咱们须要在写入数据到时候针对不一样的粒度进行聚合，须要必定的工做量，使用时间序列数据库能够少一些这样的烦恼。并且InfluxDb之类的数据库的性能是很是高的，写入数据的性能堪比Redis，单节点甚至能够承受十万指标的写入，基本能够知足大部分应用场景的需求。对于一些业务指标的监控，业务事件的打点，业务数据的时间维度聚合，咱们彻底能够考虑引入专门的时序型数据库。

综上所述，这里的架构图只是体现了几个重要思想：

1. 使用专门的服务来作数据的写入和读取，方便进行路由。

2. 合理规划好Sharding的方式，以及想好RDBMS在Sharding后的全套查询方案。

3. 数据的写入区分主要数据源的同步写入和次要数据源的异步写入，让主流程更快。

4. 合理利用不一样数据源的特性，组合使用发挥所长，避免所短。

5. 数据的加工能够是一个层级的关系，能够由专门业务中间件来进行数据加工。

6. RDBMS之外的数据库若是打算做为主核心存储引擎的话千万慎重思考。

7. 采用丰富的数据源意味着维护成本的增多，数据不一样步的问题在所不免，须要考虑一下咱们是否能够接受必定层度的数据不一致。