读写比8：2给我们带来什么样的启示

白鳝的洞穴 2021-01-13

1976

多年前做过一项调查，在我们运维过的数百套信息系统中分析读写比的关系，发现绝大多数的信息系统的读写比里高达8：2，甚至9：1，也就是说大多数的SQL语句都是SELECT语句，只有少量的语句是INSERT/UPDATE/DELETE。虽然说这种调查不一定完全准确，不过对于大多数OLTP系统来说，读的比例远大于写是一个事实。

这个读写比的关系能给我们带来什么样的启示呢？十多年前的小型机服务器的CPU资源和内存资源十分有限，因此很多优化项目最后都遇到这两个资源带来的问题。我们给一些运营商做优化的时候，总是需要大量的优化SQL语句，从而降低资源的使用。对于这种优化模式，刚开始客户还比较能够接受，随着优化的常态化进行，他们有点受不了了。优化SQL虽然能够立竿见影的产生效果，但是整体成本太高了，不断地需要开发商进行版本变更，而且业务也在快速发展，要持续保持优化效果成本太高，有没有一些其他的方法，能够避免出现这种问题呢？

最终被想出来的办法是读写分离，利用逻辑复制或者ACTIVE DATAGUARD技术产生核心系统的只读副本，把一些大开销的读操作业务分离到只读副本上。这种架构上的优化实施之后，立即获得了十分明显的效果，把一些复杂的大查询迁移到只读副本上之后，生产系统稳定多了，性能也有了很大的改善。从此以后，优化那些复杂SQL的工作转移到了只读副本上了，生产系统的SQL优化工作也变得不那么急迫了。

读写分离确实是解决资源匮乏时代的系统负载过高问题的良方，实际上这剂良药到现在还是十分有用的。很多企业都在做系统的上云迁移、开源数据库/国产数据库替代ORACLE数据库等工作。大家在做这些工作的时候发现最大的问题是，开源数据库和国产数据库都没有Oracle那么强大（实际上，论起数据库的强大，其他商用数据库与Oracle相比也是存在差距的）。最大的差距是CBO优化器水平的差距，让很多SQL在非ORACLE数据库上运行的效率都低了很多。很容易因为某些SQL的性能问题导致服务器资源耗尽，最后导致性能问题。于是我们总是想方设法去找一些靠谱的分布式数据库来替代Oracle数据库，希望通过分布式的多节点环境来解决这个问题。实际上，这种尝试效果并不尽如人意。分布式数据库虽然有很好的扩展性，不过对于跨界点的大型查询语句的执行优化往往仍然不太完美，再加上分布式数据库复杂的运维以及不便宜的采购成本，使这个替代工作并不容易完成。

实际上以目前的X86服务器的性能而言，绝大多数的OLTP系统使用一台4路服务器就完全能够承担，甚至大多数系统在一台2路服务器上就十分轻松了。一台两路服务器上安装一些开源或者国产数据库，不用做什么调优，基本上能够跑出40-100万的TPMC。这个能力，可能可以覆盖大多数企业的90%以上的信息系统的数据库需求了。

如果不使用分布式数据库，那么一旦单台服务器达到了瓶颈怎么办呢？一旦服务器故障了怎么办呢？多副本读写分离可以解决你的这个问题。我们可以建设一个一主二备的数据库集群环境，主库负责所有的写操作和一些不复杂的，常用的读操作，两个备库负责一定数量的复杂的查询操作、定时汇总操作（定时汇总操作也是降低OLTP系统中复杂查询分析资源开销过大问题的一剂良方，今天时间有限，我们以后再专题讨论）、数据共享、统计报表等操作。

这种环境下，主备库之间的数据差异在正常情况下是秒钟级的（经过优化可以达到亚秒级别），对于能够允许这种数据延时的查询操作，都可以使用备库，而对于数据一致性要求极高的查询操作，仍旧使用主库（这些数据一致性较高的操作往往查询数据量十分有限，并且效率较高）。当主库发生故障的时候，两个备库中的一个升级为主库，只读副本变为1个，此时可以实现不需要人工干预的自动化切换，整个系统的运行不受影响。后续运维人员可以修复故障的主库，并把主库制作成新的只读备库。

实际上这种读写分离的数据库架构在很多企业都有十分成功的应用，最为典型的是MYSQL的MGR集群和MHA，以及Oracle的ADG。在2015年，我们为某电力公司的某个调度专业的系统设计双活方案的时候，就和达梦公司一起合作过一个基于达梦数据库准同步复制、JDBC引擎使用读写分离代理模式的技术方案。当时客户的系统主站和副站位于两个城市，中间的光纤距离是103公里左右。主站使用国产的服务器，凝思操作系统，国产分布式存储系统，达梦数据库，副站使用国产服务器、凝思操作系统，华为集中式存储系统，达梦数据库。全局负载均衡和本地负载均衡采用华三公司的国产方案。这是一套全国产的双活系统。

在这套系统中，正常运行状态下，省调主站负责70%的读业务和100%的写业务，备调负责30%的读业务。如果某一个站出现故障，则所有业务都切换到存活下来的站上。2015年上线以来，这套全国产的系统已经安全稳定运行了5年多。多次单站故障都实现了存活站的自动业务接管。

通过对数据库的升级（从DM6升级到DM7），以及在双活建设过程中进行了一系列的优化工作，核心业务模块的性能基本上维持了原有水平，并没有因为双活架构而导致性能的下降。项目总体是成功的。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

读写比8：2给我们带来什么样的启示

评论