MyCat - 背景篇（1）

此文已由做者张镐薪受权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

SQL与NoSQL

目前，对于互联网海量数据的存储以及处理，按使用场景，分为OLTP（联机事务处理，好比即时交易，强调快速响应与处理）与OLAP（联机分析处理，好比BI，强调多维数据分析）。对于这些数据的存储，主要有两种解决方案，即基于SQL的关系型数据库，和NoSQL的非关系型数据库。 非关系型数据库在某些特定场景下有奇效，好比键值存储（redis,ROMA,Memcached）数据库应用在排行更新，会话保存，面向文档的数据库（mongoDB、couchDB）应用在日志记录，面向列的数据库（Cassandra、HBase）在博客中的应用。关系型数据库最大的问题在于速度与可扩展性上，而这些NoSQL数据库通常部署简单，支持扩展，并且速度极高。 可是，NoSQL目前仍是只能作为关系型数据库在某些特定应用场景的补充，不能彻底替代严谨规范的关系型数据库。

关系型数据库瓶颈

目前商用的数据库以及开源的数据库通常都不支持大规模自动扩展，单库上面存在着性能瓶颈。通常的，MySQL数据库单表超过1000W~2000W条记录时，性能就会有比较明显的降低。为了提高性能以及能够存储数据的量，咱们须要分库分表。

分库分表

举个例子，假设咱们原来的应用是为了客户完成下单，快递员接受并更新运单状态，客户能够随时查看运单状态的任务。一开始咱们的数据库层架构设计（忽略其余部分，好比缓存、CDN等）多是这样：可是很快地，咱们发现，把全部的数据放在同一个库里面，随着业务的增加，数据量太大，响应时间变得愈来愈慢。业务需求已经承受不住了。咱们首先作了垂直分片，按照业务模块，将数据库拆分红了快递员库，运单库和客户库来管理。再以后，咱们发现运单单表有效数据量量级已经超过了2000W条，为了避免影响TPS与QPS。咱们须要把运单表作进一步的水平拆分。可是，水平分片后，像分片表关联这种操做，好比order by,group by还有join就不能经过数据库本身自己去完成了，由于每一个分片库的数据都不是完整的。并且，跨分片事务（即分布式事务，分布式XA），比较难以实现。 拆分规则有不少种，须要根据具体业务决定。好比若是咱们总体业务TPS小于单库可承受TPS，只是咱们天天要产生2000W记录，并且这些记录要保存一周。咱们能够按照日期分片，好比周一的数据保存到库1，以后以此类推。可是这样作的缺点很明显，同一天的写压力全都打到一个分片上，其余分片处于写空闲状态。即便总体业务TPS小于单库可承受TPS，这样的架构也不利于之后业务增加进行扩展。 咱们还能够按照运单号对某一数字（分片个数）取模，让这些运单平均分布到每一个后台分片库上。这样，咱们能够保证同一时间全部的分片都是工做状态，没有资源浪费。可是，将来若是分片不够用了，扩容难仍是个问题。 还有不少其它分片的规则（好比wang-jeekins哈希取模范围，扩容哈希范围，id字段范围等），在以后的MyCat中间件具体使用篇我会详细介绍，并给出一些原创的可行的分片方案。

谁来分库分表

实现这种分库分表能够有多种思路，看上面的架构图，咱们能够：

• 在数据库层作手脚

• 在应用层作手脚

• 在应用层与数据库层添加数据库路由中间件（至关于代理）

  首先，在数据库层作手脚，须要数据库产品为开源的，并且修改MySQL和MariaDB之类的数据库须要至关专业的团队以及较高的成本，因此，通常项目初期不会考虑这种方式。

而后是在应用层作手脚，像Ibatis sharding, shark，TDDL等。他们实现分库分表的思路是很类似的：通常这些框架很轻量级，在应用端放一个jar。他们自己不必定都实现了动态配置，可是他们均可以和Disconf之类的动态配置中心结合，实现动态数据源与动态分片规则。首先，应用会访问附近的配置中心，配置中心会告诉这个应用应该去访问哪一个数据库以及分片规则是什么。以后，应用会本身去访问数据库，并做分片和合并结果。 这样作的好处是：

• 实现分片和结果聚合的压力分摊给了每个应用

• 根据应用业务场景开发对应的功能

• 轻量级，代码少

• 能最大发挥后台数据库的能力 可是同时，也有它的局限性：

• 依赖于额外的配置中心实现动态配置

• 对应用代码有侵入性

• 使应用处理变重

• 应用出问题难以定位是哪里出了问题

• 将业务开发与后台数据库分库分表管理耦合，难于开发管理

最后，是代理的方式：实现思路大概是，实现mysql协议栈，将本身假装成一个mysql数据库，本身后台管理全部mysql实例。应用无感知，只当后台只是一个mysql实例。这个代理mysql实例，实现分库分表，结果合并等功能。 这种代理实现的好处在于：

• 对应用没有侵入性

• 压力打在中间件上

• 统一管理后台数据库，能及时定位问题 可是，他也有本身的缺陷，首先就是压力打在中间件上的话，可能不能发挥后台数据库最大的能力。由此，中间件须要作负载均衡集群，这要求中间件必须是无状态的。可是，这无疑增长了架构的复杂程度。目前，淘宝的高吞吐量业务仍是在用TDDL相似的产品也是这个缘由。 这两种实现方式还都有共同的难以解决的问题，好比分布式事务这个问题，目前也没有很是完美的方案。还有，他们对于SQL都有限制（好比有的不支持DDL，大部分都不推荐使用大事务等） 总体说来，项目初期使用代理这种实现方式仍是利大于弊的，网上有不少开源产品，他们基本和淘宝的Amoeba和Cobar一脉相承。实际应用场景众多，较为可靠。本文即将介绍的MyCat也不例外。下一篇咱们将更详细地介绍MyCat的背景 :-D

免费体验云安全(易盾)内容安全、验证码等服务

更多网易技术、产品、运营经验分享请点击。

相关文章：
【推荐】 知物由学 | AI时代，那些黑客正在如何打磨他们的“利器”？（一）
【推荐】 Hive中文注释乱码解决方案
【推荐】 分布式存储系统可靠性系列三：设计模式