南宁制作网站公司,网站建设的优缺点,重庆妇科医院咨询,东莞市建设网站随着企业业务的不断发展#xff0c;数据量往往呈现出快速的增长趋势。使用MySQL的用户面对这种增长#xff0c;普遍选择采用分库分表技术作为应对方案。然而#xff0c;这一方案常在后期会遇到很多痛点。
分库分表的痛点
痛点 1#xff1a;难以保证数据一致性。由于分库分…随着企业业务的不断发展数据量往往呈现出快速的增长趋势。使用MySQL的用户面对这种增长普遍选择采用分库分表技术作为应对方案。然而这一方案常在后期会遇到很多痛点。
分库分表的痛点
痛点 1难以保证数据一致性。由于分库分表方案使得数据被分散存储于不同的数据库或数据表中这在一定程度上使数据之间的关联变得更为复杂确保数据的一致性的难度也随之增加。 痛点2查询性能下降。分库分表会导致查询的性能下降因为查询需要对多个数据库或数据表进行查询增加了查询的时间和成本。非分区键查询需要借助其它的中间件或索引表进行查询。
痛点3业务变更难度大。分库分表会增加系统的复杂度当业务变更时需要对所有分片进行修改和调整增加了业务变更的难度和风险。
痛点4数据迁移成本高。分库分表的场景下数据的迁移成本很高迁移过程中会涉及数据的拆分、合并和迁移等环节增加了数据迁移的难度和成本。
痛点5运维难度高。分库分表会增加系统的运维难度需要对多个数据库或数据表进行管理和维护增加了系统的故障排查和维护难度。尤其是自建 MySQL 集群。
痛点6分库分表后的历史问题数据追溯困难。在分库分表的场景下历史问题数据追溯问题是一个普遍存在的问题由于数据被分散存储在多个数据库或数据表中导致历史数据的追溯变得困难。
另外使用 MySQL 分库分表的方案时不仅需要依赖第三方工具而且数据读写都比较复杂。 以上的常见挑战也是OceanBase的客户绿普惠所遭遇过的因此他们舍弃了 MySQL 分库分表方案转而使用分布式数据库。经过绿普惠的初步筛选在一众分布式数据库中OceanBase 可以支持 HTAP 混合负载且在 TPC-C 和 TPC-H 的评测中均取得了好成绩故而展开了进一步的调研和测试。
一、绿普惠的业务背景
系统上指数级增长的数据要求技术人员在运营上采用有效的应对方案而诸如分库分表的措施也带来了后期维护成本。在绿普惠的系统中其中的关键平台之一是“绿普惠云-碳减排数字账本”。数字账本平台主要包括三个模块租户查询系统、碳减排量交易系统和运营端报表系统。
租户查询系统租户可以通过 API 进行减排量指定维度和场景查询操作查询系统将返回相应的减排数据。碳减排量交易系统交易核心减排量处理可以支持大数据量低延迟满足事务 ACID 要求。运营端报表系统用于统计分析和生成报表可以处理大量大事务和复杂查询。 由于业务数据量庞大目前绿普惠的存量数据表行数达到上亿行还有每天上千万条的增量数据。面对庞大的数据量他们采用了一种常见的数据处理方案 —— MySQL 分库分表。即通过将一个大的数据库拆分成多个小的数据库或将一个大的数据表拆分成多个小的数据表来减轻单一数据库或数据表的负载压力提高系统的性能和可用性。但是其存在的痛点也让人束手无策。 二、调研过程及功能测试
在深入调研过程中绿普惠了解到 OceanBase 已经应用在诸多行业覆盖行业头部企业和一些中小型企业。对于绿普惠而言他们看中了 OceanBase 的原生分布式无需分库分表、HTAP混合负载、并行执行优秀、存储成本低、数据迁移方便等特点。
一原生分布式
OceanBase 是原生的分布式数据库可以保证多个数据副本之间的一致性利用基于 Paxos 分布式一致性协议保证了在任一时刻只有当多数派副本达成一致时才能推选一个 Leader通过保证主副本的唯一性来对外提供数据服务。相比分库分表方案大大降低了绿普惠的运维难度和业务变更难度。利用 OceanBase 的多地多副本架构以及高效的 Paxos 一致性协议工程实现还支持数据副本分别存储在同城和异地实现异地容灾。 二HTAP 混合负载
除了原生分布式无需分库分表的特性OceanBase 可以同时支持 OLTP 业务与 OLAP 业务故而被称为 HTAP 数据库。但这不单是一句口号背后涉及四个关键技术。
1. 读写分离
分库分表会导致查询的性能下降而数据库的读写分离策略是一种将数据库的查询操作和写入操作分离的方案目的是降低读写操作的相互影响并提升资源利用率。在 HTAP 数据库中读写分离的应用场景非常普及。OceanBase 数据库天然支持读写分离的功能即通过 OBProxy 代理服务和修改 OBServer 的配置即可实现业务的读写分离策略。
OceanBase 数据库在读取数据时提供了两种一致性级别强一致性和弱一致性有效解决分库分表的查询性能问题。强一致性是指请求路由给主副本读取最新数据弱一致性是指请求优先路由给备副本不要求读取最新数据。通过应用侧为执行的 SQL 添加 SQL Hint 来显性开启弱一致性读就可以实现基于注释的读写分离功能同时也衍生出种各种各样的读写分离策略比如备优先读、只读 zone、只读副本企业可以根据实际情况对读写分离策略进行灵活的配置。
2. 大查询队列
对于数据库来说相比于单条复杂大查询让大量的 DML 和短查询尽快返回更有意义。为了避免一条大查询阻塞大量简单请求而导致系统吞吐量暴跌避开分库分表的查询性能局限当大查询和短请求同时争抢 CPU 时OceanBase 会限制大查询的 CPU 使用。当一个线程执行的 SQL 查询耗时太长这条查询就会被判定为大查询一旦判定为大查询就会进入大查询队列然后执行大查询的线程会等在一个 Pthread Condition 上为其它的租户工作线程让出 CPU 资源。 配置大查询的参数为 large_query_threshold执行时间超过这个参数设置的阈值则认为是大查询。
属性描述默认值5s取值范围[1ms, ∞)
如果系统中同时运行着大查询和小查询OceanBase 会将一部分 CPU 资源分配给大查询并通过配置参数 large_query_worker_percentage默认值为 30%来限制执行大查询最多可以使用的租户活跃工作线程数。
属性描述默认值30取值范围[0, 100]
OceanBase 数据库通过限制大查询能使用的租户活跃工作线程数来约束大查询最多能够使用的 CPU 资源以此来保证系统还会有足够的 CPU 资源来执行 OLTP例如交易型的小事务负载通过这样的方式来保证对响应时间比较敏感的 OLTP 负载能够得到足够多的 CPU 资源尽快地被执行无需面对分库分表导致查询的性能下降。 3. 资源隔离
资源隔离并不是一个新概念传统方式下不共享物理资源可以理解为物理资源隔离方案。这种方案下不同租户或同一租户内 OLAP 和 OLTP 使用不同的副本只读副本服务 OLAP全功能副本服务 OLTP两种业务不共享物理资源。如果不考虑成本物理资源隔离无疑是更好的选择。但现实中大部分企业都会考虑硬件成本及其资源利用率。一方面数据库硬件的购买和维护成本高昂而所有硬件都需要定期换新另一方面数据库硬件在进行单项业务处理时平均占用率水平较低。如果不能充分利用硬件资源无疑会造成巨大的资源浪费。并且基于此进行的分库分表方案需要对多个数据库或数据表进行管理和维护增加运维难度。
而要充分利用硬件资源不同租户或同一租户内 OLAP 和 OLTP 共享物理资源的逻辑资源隔离方案自然脱颖而出。实际上物理资源隔离和逻辑资源隔离不是二选一而是互为补充的关系。理想的资源隔离方案是在完全物理隔离和逻辑隔离中找到平衡点OceanBase 会给用户更多自由帮助绿普惠在面对各类场景下都可以做出最合适的选择有效降低分库分表带来的系统复杂度。 4. SQL 执行优化
SQL 的执行引擎需要处理很多情况为什么要对这些情况进行细分呢是因为 OceanBase 希望在每种情况下都能自适应地做到最优不依赖现行的分库分表方法。从最大的层面上来说每一条 SQL 的执行都有两种模式串行执行或并行执行可以通过在 SQL 中增加 hint /* parallel(N) */ 来决定是否走并行执行以及并行度是多少。 模式一串行执行
如果这张表或者这个分区是位于本机的这条路线和单机 SQL 的处理是没有任何区别的。如果所访问的是另外一台节点上的数据有两种做法一种是当数据量比较小时会把数据从远程拉取到本机远程数据获取服务当数据量比较大时会自适应地选择远程执行把这条 SQL 发送到数据所在节点上将整条 SQL 代理给这个远程节点执行结束之后再从远程节点返回结果。如果单条 SQL 要访问的数据位于很多个节点上会把计算压到每个节点上并且为了能够达到串行执行在单机情况下开销最小的效果还会提供分布式执行能力即把计算压给每个节点让它在本机做处理最后做汇总并行度只有 1不会因为分布式执行而增加资源额外的消耗比分库分表在资源上利用率更高。对于串行的执行一般开销最小。这种执行计划在单机做串行的扫描既没有上下文切换也没有远程数据的访问是非常高效的。 模式二并行执行
并行执行同时支持 DML 写入操作的并行执行和查询的并行执行对并行查询分还会再去自适应地选择是本机并行执行还是分布式并行执行。对于当前很多小规模业务来说串行执行的处理方式足够。但如果需要访问大量数据可以在 OceanBase 单机内引入并行能力目前这个能力很多开源的单机数据库还不支持但只要有足够多的 CPU可以通过并行的方式使得单条 SQL 处理时间线性缩短只要有一个高性能多核服务器增加并行就可以了。而分库分表较为麻烦SQL 执行依赖中间件难以进行性能调优。
针对同样形式的分布式执行计划可以让它在多机上分布式去做并行这样可以支撑更大的规模突破单机 CPU 的数目去做更大规模的并行比如从几百核到几千核的能力。 OceanBase 的并行执行框架可以自适应地处理单机内并行和分布式并行优于传统的分库分表方案。这里所有并行处理的 Worker 既可以是本机上多个线程也可以是位于很多个节点上的线程。分布式执行框架里有一层自适应数据的传输层对于单机内的并行传输层会自动把线程之间的数据交互转换成内存拷贝。这样把不同的两种场景完全由数据传输层抽象掉了实际上并行执行引擎对于单机内的并行和分布式并行在调度层的实现上是没有区别的。 那么如果不采用分库分表什么时候适合并行执行通过充分利用多个 CPU 和 I/O 资源达到降低 SQL 执行时间的目的呢当满足下列条件时使用并行执行会优于串行执行
访问的数据量大SQL 并发低要求低延迟有充足的硬件资源
三存储成本
相比分库分表简单地对数据库进行分片作为一款 HTAP 数据库产品 OceanBase 使用基于 LSM-Tree 架构的存储引擎同时支持 OLTP 与 OLAP 负载这种存储架构提供了优秀的数据压缩能力。在 OceanBase 中增量数据会写入 Clog 和 Memtable 中OceanBase 的 Memtable 是内存中的 B Tree 索引提供高效的事务处理能力。Memtable 会定期通过 Compaction 生成硬盘持久化数据 SSTable多层 SSTable 会采用 Leveled Compaction 策略进行增量数据重整。SSTable 中数据块的存储分为两层其中 2M 定长的数据块宏块作为 SSTable 写入 I/O 的最小单元存储在宏块中的变长数据块微块作为数据块压缩和读 I/O 的最小单元。 在这样的存储架构下 OceanBase 的数据压缩集中发生在 Compaction 过程中 SSTable 的写入时数据的在线更新与压缩得到了解耦。批量落盘的特性使其采用更激进的压缩策略相比分库分表而言存储空间更少。OceanBase 从 2.0 版本开始引入了行列混存的微块存储格式 PAX 充分利用了同一列数据的局部性和类型特征在微块内部对一组行以列存的方式存储并针对数据特征按列进行编码。变长的数据块和连续批量压缩的数据也可以让 OceanBase 通过同一个 SSTable 中已经完成压缩的数据块的先验知识对下一个数据块的压缩进行指导在数据块中压缩尽量多的数据行并选择更优的编码算法。 与部分在 schema 上指定数据编码的数据库实现不同 OceanBase 选择了用户不感知的数据自适应编码在给用户带来更小负担的同时降低了存储成本从历史库角度而言用户也不需要针对历史库数据做出过多压缩与编码相关的配置调整。相比分库分表OceanBase 之所以能够在事务性能和压缩率之间取得更好的平衡都得益于 LSM-Tree 的存储架构。
当然 LSM-Tree 架构不是解决数据库压缩所有问题的万金油如何通过数据压缩降低成本、提升性能是业界一直在讨论的话题。对 BTree 类的存储引擎进行更高效的压缩也有很多探索比如基于可计算存储硬件的工作利用存储硬件内部的透明压缩能力对 B Tree类存储引擎的数据压缩进行优化使其写放大达到了接近 LSM-Tree 架构存储引擎的效果。但 LSM-Tree 中内存数据页更新与数据块落盘解耦和 sstable 数据紧凑排布的特点使得 LSM-Tree 相对 B Tree类存储引擎仍然更适合在对查询、更新带来更少负面影响的前提下实现更高效的数据压缩这是分库分表所不具备的特性。
四OMS 数据迁移
分库分表的场景下数据的迁移成本很高。OceanBase 提供的数据迁移工具 OMSOceanBase Migration Service支持 MySQL 等关系型数据库与 OceanBase 双向自动迁移和数据校验可以在大幅提升迁移效率的同时进一步降低数据不一致的风险。OMS 还提供丰富的数据订阅 CDC 能力支持数据流到 Kafka、MQ 等消息队列的同步。 在传统的数据库迁移方案中基于分库分表场景数据的迁移成本很高为了保障迁移任务的稳定性和数据的一致性通常通过停机迁移的方式进行数据迁移。停机期间需要暂时停止写入数据至源端数据库待迁移完成并确认数据一致性后再切换业务数据库。但停机迁移的耗时和业务数据量、网络状况相关在业务量巨大的情况下数据库的停机迁移可能耗时数天对业务影响较大。
OMS 提供的不停服数据迁移功能不影响迁移过程中源数据库持续对外提供服务能够最小化数据迁移对业务的影响。在完成结构迁移、全量数据迁移和增量数据迁移后源数据库的全量和增量数据均已实时同步至目标数据库中数据校验通过后业务可以从源端切换至目标端有效避开分库分表场景下数据迁移的难度和成本。 三、解决方案和性能测试
绿普惠通过 OceanBase 替换 MySQL 分库分表的方案如下
通过 OMS 将异构数据库分库分表同步至 OceanBase 原生分区表多表汇聚同步。迁移至 OceanBase 后多个实例融合为一个实例摆脱分库分表下所依赖的中间件大幅提升存储可扩展性。OceanBase 的 HTAP 模式满足了业务上分析查询的业务得以前置无需像分库分表那样等待 T1 数据直接于在线库实现实时决策等分析需求。 基于该方案绿普惠在测试环境中部署了三个 OceanBase 3.1.4 版本的集群节点相较于分库分表对运维监控工具、分区功能、分区表读写性能等方面逐一展开了测试。
一OceanBase 集群运维监控
绿普惠使用了 OceanBase 的运维工具 OCP 来实现集群的运维管理和监控告警利用 OCP 的告警功能配置企业微信告警渠道实现告警信息的实时推送到企业微信保证了开发能够第一时间获取到 OceanBase 集群重要的告警信息运维上远优于分库分表方案。 二分区功能测试
绿普惠的关键业务表是减排行为表在 OceanBase 中绿普惠给这张表做了二级分区一级分区键为租户 id二级分区键为手机号 sha256 加密字符串表的定义类似于 OceanBase 提供的分区功能非常强大无需像分库分表一样进行缺乏弹性的物理分区详细分区表可以点击文末“阅读原文”查看官方文档。
三分区表性能测试
提前测试可降低分库分表场景下的数据迁移的难度和成本。使用 OceanBase 3.1.4 社区版本可以创建分区表或者非分区表。对于非分区表在数据量巨大的情况下性能肯定不好所以我们没有对其进行压测。对于分区表在数据量大的情况下才能充分发挥其性能所以绿普惠给分区表提前写入了三亿条数据并且以递增线程数的方式去进行压测每次压测执行三分钟。然后分析结果中的吞吐量当吞吐量无法继续增加时认为此时的线程数是系统能承受的最大并发数。
绿普惠的压测脚本分为两部分第一部分是增删改查测试插入、查询、修改相当于 read write 性能第二部分是事务测试插入、修改相当于是 write only 性能。测试环境是三台 32c 128g 的机器测试的版本是较早的 OceanBase 3.1.4 社区版整体优于分库分表的迁移复杂度。测试结果如下表所示 注OceanBase 3.1.4 社区版的 sysbench 详细性能测试报告详见性能测试官方文档。
四测试过程中遇到的一些问题
在测试过程中绿普惠发现当 OceanBase 3.14 社区版本在二级分区表数据量过大时创建索引失败。不过该问题已经在 OceanBase 3.15 版本被解决。另外OceanBase 的 MySQL 模式租户下有 global 索引的分区表不支持 insert ignore执行时直接报了 not supported。绿普惠猜测不支持的原因是全局索引插入成功之后如果主表插入失败这时不仅要回滚主表的改动还需要回滚全局索引的改动。这个回滚数据的过程的实现复杂度非常高OceanBase 暂时还没有支持该功能。相比分库分表还是从性能和根源上避开不少痛点。 四、总结
在选择使用原生分布式 OceanBase 替代 MySQL 分库分表方案后收益符合预期主要包括几点
降低运维难度相比分库分表方案大大降低了绿普惠的运维难度和业务变更难度。而且完全兼容 MySQL 的语法强大的 CDC 能力支持方便多种类型的下游进行数据消费。比分库分表更灵活的动态扩容单集群最大可超过上千节点数据容量可以超过 PB 级。强大于分库分表的数据更新能力基于关系型数据库的更新能力副本间毫秒级极低延迟。优于分库分表的HTAP 一体化一套引擎处理 OLTP 和基本的 OLAP 场景同时基于资源组隔离技术提供 OLTP/OLAP 业务资源隔离的可靠方案免去复杂的实时数仓建设。 分布式并行计算引擎强大的 SQL 优化器和执行器支持向量化计算和海量数据的并行计算分析。
经过探索测试绿普惠验证了 OceanBase 在性能、成本等方面的优势避开了分库分表的诸多痛点符合当前业务发展的需求且 HTAP 混合负载能力与企业的实际业务场景非常契合后续必定会有更加深入的合作。
