于业务呈现出以较高速度向前发展的这种背景状况之下，数据库的架构常常会遭遇那种被称为“读写争锋”的艰难困境。
此文会拿一个典型的“高写入、强统计”情形当作例子，深入去剖析从读写分离开始、到索引优化、再到引进列式存储的整个链路的演进进程，探究怎么样凭借架构分级以及技术创新，在资源受限的状况下达成性能突破。
一、场景痛点：密集型写入与全表统计的冲突
该业务场景有着鲜明的数据特征，不存在事务，存在数据密集型写入，同时伴有明确的统计需求，且统计需求具有高频率的特点。
刚开始的时候，统计任务每隔7分钟就执行一回，并且查询语句大多数都是对整个表进行扫描这种程度的。
这种设计直接导致了两个核心问题：
1. 读写资源争抢，统计SQL大量消耗系统资源，也就是I/O和CPU，致使原本简单的写入操作变成慢日志SQL，也就是慢查询，进而形成资源瓶颈。
2. 优先级倒挂：业务存续存在着一种“硬需求”，那便是写入，辅助分析存在着一种“软需求”，那就是统计。
于统计SQL即结构化查询语言成为瓶颈之际，首要之任务乃把主库自繁重的分析计算里头解放出来。
二、第一步改进：读写分离，快速止血
最快的响应方案是将读负载转移。
架构实施调整之后，我们把统计类的查询呀，都导向了从库那边从而进行引流，达成了的是物理层面上读写相互分离的一种状况。
主库减压：转移读请求后，主库的写入压力得到极大缓解。
监控给出的数据表明，CPU的负载情况，从久久维持在90%以上的状态，急剧下降到了10%以内，这样一来为写入操作，提供了充足宽裕的缓冲空间。
从库承压：从库的压力随之显著提升。
但深入分析发现，压力的主要来源并非CPU，而是I/O层面。
统计需求仍然依靠全表扫描，海量数据页被读取，这使得磁盘I/O Wait急速上升。
三、第二步尝试：索引失效，瓶颈上移
面对从库的I/O瓶颈，常规思路是添加索引。
然而，在此场景下，索引优化收效甚微。
存在这样的缘由，统计查询常常都会涉及到数量众多的数据的聚合计算，就算是有索引覆盖这种情况，也只能将那种“全表扫描”的情况降级成为“全索引扫描”的状况。
索引数据页还是得加载进内存，针对大规模的时候数据集来讲，I/O的代价依旧是高昂的。
这意味着，仅仅是索引方面的优化，没办法从根本上解决统计情形之下的I/O呈现密集状态的问题。
四、架构分水岭：应用层分片与中间件博弈
从根本上对扩展性问题予以解决，团队试着引入分布式中间件，且规划了两个演进方向。
方案一，也就是中间件层分片，要添加数据节点，借助中间件打造分布式架构。
但从库为了节省成本采用了“单机多实例”模式。
该种方案里的隐患之处在于，中间件得去承担繁杂的数据汇总，以及要进行统计计算，这极其容易变成新的阻塞点。
且业务方采用动态配置建表，与中间件的静态路由规则难以兼容。
方案二，也就是应用层数据路由，实践已经证实，有一种更具可控性的方案，那便是将数据路由在应用层予以实现。
根据不同业务线（如业务1、业务2）映射到指定数据源节点。
这样一种“业务线分库”的法子，具备很强的扩展性，有着很低的耦合度，把数据分片的逻辑往应用层进行上移，从而避免了中间件的单点压力呀。
五、引入列式存储：统计性能的革命性优化
其业务呈爆发式增长态势，统计的需求由原本的10个骤增至30个，单个统计需求所关联的SQL（结构化查询语言）数量超过了5个。
即便完成了读写分离和应用层分片，从库的延迟依旧存在。
本质问题在于，MySQL，也就是一种关系型数据库管理系统，它的行式存储引擎，在面对海量数据聚合查询的情况下，其I/O模型具有天然的局限性。
基于此，团队作出决定，要引入列式存储方案归入数据仓库节点，进而构造“OLTP（在线事务处理） + OLAP（在线分析处理）”混合型架构。
1. 架构进行调整：于原生的主从复制架构建构之上，使一个基于列式存储技术的独立的数据仓库节点得以扩展。
在规定的时间间隔内，采用ETL工具，把MySQL（作为一种关系型数据库管理系统）从库之中的数据，同步到列式存储引擎那里去。
2. 表结构适配：原表结构有自增主键，其中有用户ID，还有动作类型，另外存在阅读次数，并且含有创建时间。
此类字段类型简便，数据具备较强规律性，极为契合于列式存储里面开展压缩以及向量化计算。
3. 性能质变：
I/O被大幅削减：对列式存储来说，仅需读取查询所关联的列（像用户ID以及 阅读次数），并非读取一整行的数据，是这样安排的。
关于统计SQL也就是结构化查询语言，其代码为 SELECT * FROM table WHERE...，在列式存储里要改写为仅仅选取所需的列，如此一来I/O开销能够降低80%以上。
《高压缩比》：同一列里头，数据类型保持一致，存储压缩比特别高，更进一步削减了磁盘I/O。
列式引擎常常支持向量化计算，这种向量化计算能大批量地处理数据，进而大幅度地提升聚合运算的效率，呈现为这样一种被称作向量化执行的情况。
六、技术选型的隐忧与前瞻
在落地列式存储方案时，需要关注开源社区的动态。
早期，有基于MySQL（它属于关系型数据库管理系统的其中一种）的那些列式存储引擎（就像某些第三方引擎那样），存在着功能限制（比如说不支持DDL还有数据操纵语言），并且社区版已经停止进行维护了，官方把重心转向了企业版。
这表明，于生产环境里挑选这类方案，必然要考量后续的技术支撑情况，也要预估版本迭代所存在的风险。
七、总结
有从最开始的读写分离去实行“救火”之举，经过应用层分片来“铺路”，进而引入列式存储以“治本”，这一整套的演进揭示了数据库性能优化的核心逻辑，那就是：没有银弹，只有进行持续不断地权衡与演进。
写入密集型：依赖应用层分片、数据路由解决扩展性。
对于统计密集型而言，要摒弃传统索引思维，接纳列式存储、MPP（大规模并行处理）之类面向分析的计算引擎，如此方可从根源上化解I/O瓶颈。
靠着构建一种将关系型数据库管理系统MySQL的主从加列式存储数仓组合起来的架构方式，此业务场景成功把主库的CPU从百分之九十持续稳定降低到百分之十以下，将统计查询性能提升了好多倍，为未来的指数级增长奠定了稳固的架构基础。
Comments NOTHING