|
|
马上注册，结交更多淘宝商家，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
“让技能被望见 | OceanBase 布道师操持”由 OceanBase 主理，CSDN 协办，面向广大开辟者的年度征文运动。整年 4 轮，以季度为周期举行良好文章评比，每年 1 届，以年为单元举行最佳布道师评比。
现在，首轮技能征文获奖文章已评比出炉，本篇内容为「OceanBase 布道师操持」良好文章之一，作者 rocH。
运动仍在举行中，欢迎感爱好的小同伴点击「阅读原文」进入运动官网，相识运动详情或进一步投稿：https://open.oceanbase.com/blog/essay-competition。
评委有话说
屠敏（CSDN 资讯主编、《新步伐员》特约专栏记者）：随着IT技能飞速发展，跨境电商企业业务规模不绝扩大，运维难度和资源也随之攀升。这篇文章深入探究了OceanBase在跨境电商OA体系中的应用，团结OceanBase的技能特性与大规模数据处理处罚本事，本文不光展示了高效办理方案，还对资源优化举行了深入分析。
章芋文（墨天轮社区负责人）：文章通过真实案例纪录了跨境电商行业数据库更换的寻衅、需求和选型重点，具体形貌了从其MySQL到OceanBase的迁徙过程和实行细节、运维过程中遇到的题目总结。文章结构清晰，逻辑严谨，徐徐引导读者从题目辨认到办理方案，再到效果评估和履历总结。别的，作者通过具体的技能分析和数据对比，突出了OceanBase在存储优化、性能提拔和高可用性方面的上风。总体而言文章有很强的实用性和行业鉴戒意义。
跨境电商数据库更换需求
本公司为跨境电商企业，从国内开辟商品，登载到国际电商平台上售卖。现在在售sku有100w+。由于管理的店肆较多。Sku放大到各个电商平台，存在几个亿的listing数据。
早期未做数据库拆分工作，全部平台店肆数据表都在同一个数据库(MySQL)中。各个业务之间，关联查询未作任何限定。导致反面想做分库分表，比力难以实现。现在总数据量到达6TB，共1400+张表，单表最大纪录数5亿，单表最大数据量300GB，徐徐体系出现各种瓶颈或题目，具体体现为以下几点。
第一，在业务发展早期，我们使用的是MySQL单机，业务强盛后升级为集群，使体系中存在不少汗青遗留的全表更新业务代码。一旦实行，MySQL主从延长就会凌驾设定的阈值，导致从库无法使用。同时，全部SQL全部被路由到主库，导致主库CPU使用率飙升，进而使业务显着感知到卡顿。
第二，部门表，单表数据量太多，如果做一次团体业务调解，必要频仍更新整张表，轻易出现TPS瓶颈。这时通常会举行分区，将TPS流量分片到差异呆板，进步业务实行服从。团结业务来说，假设我们对商品做一次全量调价的利用，为了确保调价乐成，会将调价信息发送到RabbitMQ。然后通过多台斲丧端举行接口调用并更新数据。但当出现大批量的调价需求时，如果增长过多斲丧者，会造成数据库压力过大。在维持一样平常业务使用的情况下，斲丧完备个队列的消息大概必要1-2个星期。这显然不符合业务预期。
第三，汗青代码量太多，业务中使用的关联多表的查询较多，使用传统的分库分表方案，改造工作量巨大，而且欠利益置处罚跨构造联查询引起的性能题目。
第四，MySQL数据膨胀锋利，云盘存储费用高涨，亟需优化存储资源。
数据库选型及二次迁徙
基于上述痛点，我们亟需一款新的数据库，且必要具备以下特点：
- 有良好的分库分表架构本事。
- 集群团体高可用，重要是从库延长低，能稳固提供读服务。
- 可以机动扩展。
- 运维简单，便于查找实时题目SQL。
- 能低沉存储资源。
在颠末开端调研市面上排名前十的数据库(墨天轮排行)，发现OceanBase技能架构强盛，产物文档美满，当我们在社区告急时很快就能得到反馈息争答。最紧张的是OceanBase的产物本事：
- 表组和复制表特性，能极大地镌汰分区带来的跨构造联查询斲丧，非常有利于我们简化后续的表分区工作。
- 数据压缩率高，最开始相识到OceanBase数据压缩率为1：3，而在实际应用后发现MySQL 6TB的数据，同步到OceanBase只必要920GB的空间，压缩率到达惊人的1：6。我推测是由于MySQL中存在大量由于数据删除而未开释的空间造成的。而在OceanBase的实际使用中，我们完全无需担心这一题目，由于每天OceanBase都将有一次数据归并，整理存储空间。
- 集群架构的高可用性和开源免费的OCP运维工具，比力适当自建集群运维，白屏页面化利用对于集群监控、集群扩展、SQL诊断能提供极大的方便。同时也省略了使用RDS时，必要淹灭的监控和SQL诊断服务费用。
- OceanBase使用的Paxos协议，固然把写放大了，但从另一个维度低沉了主从副本数据同步的延长。低延长对于我们原有的一主二从的RDS MySQL架构来说，更能发挥从副本呆板的查询性能。
下面来具体讲一下我们的迁徙过程。下表是我司最开始使用RDS的呆板设置和资源。以及终极迁徙完成后，使用的OceanBase呆板设置和资源。
生产库从MySQL迁徙到OceanBase ，我们做了两次实验，在这里万幸OceanBase提供了专业的数据迁徙工具OMS，支持数据的反向同步。正是这一功能顺遂支持了我们多次调解后的数据迁徙。
第一次，为了尽大概进步团体写性能，根据RDS原设置的核数和内存。我们使用9台16核64GB的小型机摆设OceanBase3-3-3的集群，将数据较多的表做分区。同时，将雷同业务的表到场同一个表组，把多个业务必要关联查询的部门表，改成复制表，办理跨机查询带来的性能题目。这种方案完善的办理了业务高频次的TPS哀求延长题目。但由于我们过于迫切地使用这种完善的切换方案，导致迁徙的集群性能无法支持原业务的一样平常哀求。重要存在如下题目。
- 汗青代码存量过多：固然做了很长时间的准备（分区、分表组、改复制表、关联查询和DDL语句加分区键），但照旧有“丧家之犬”导致存在较多跨构造联查询，占用了大量CPU。
- 部门业务表无法分区：有些业务没办法分区而且哀求量大，单台小型机完全无法支持这部门业务哀求，一个节点受阻就会使团体写同步延长。
- 我们将OBProxy和OBServer摆设在同一台呆板上，当这台OBServer由于提供查询导致CPU使用率过高时，通过OBProxy哀求会造成壅闭。
第二次迁徙基于失败履历，我们意识到必要办理三个题目。第一，单机性能必要进步，最少要能hold住无法分区的业务量最大的模块的哀求；第二，汗青代码巨大，全部业务模块团体分区工作量太大，而我司也亟需尽快升级数据库架构；第三，OBProxy不能和OBServer摆设在同一台呆板。
颠末优化，我们决定使用64核512GB内存摆设OceanBase 1-1-1集群再次实验，而且将迁徙和改造分三个阶段举行。
第一阶段，将全部表到场一个大组，表结构临时和MySQL划一，不做分区。如许就克制了跨机查询的题目。摆设2台OBProxy，一台查询只使用主副本，另一台查询优先使用从副本，通过延长阈值的多次调解，确定了400ms的延长阈值。由于这个署理的查询哀求险些都会发送到从副本哀求，而400ms的延长对业务来说是可担当的（相较之下，MySQL延长阈值3s，才气使用上一半从副本的性能）。同时为了克制由于主从数据差异等题目，我们对应用举行了改造，全部开启了事件的读哀求，都会使用主副本查询。
第二阶段，分业务模块徐徐改造业务分区和表组，查抄全部关联查询代码以确保不会存在跨构造联。然后将整个模块的表举行分区，并从原来的大表组中迁徙到新的业务模块表组中，徐徐将主副本打散到全部呆板上。
第三阶段，全部业务模块都完因素区和表组的改造后，取消读写分离署理。全部使用主副本查询数据，完全消弭掉同步延长带来的数据差异等题目，为后续集群扩容做好准备。
OceanBase试运行收益
现在为止，OceanBase 已经在内部OA体系试运行一个月，总体来说，以OA体系现在的数据量来看，使用OceanBase 和此前用MySQL实行SQL的服从相近，后续随着数据量的增长，预计OceanBase的性能上风会徐徐体现。
别的，在上线一个月以来，我们已经显着感知到OceanBase带来的上风，扼要总结为以下四点。
第一，存储资源降落40%，原MySQL单台呆板必要6TB存储空间，在OceanBase单台呆板只必要1.5TB，存储空间节流了3/4。
第二，由于OceanBase使用LSM Tree结构，优先写内存和日记，对于云盘的性能要求也降落了，云盘的性能级别从P2降为了P1。相较之下，本来在RDS必要使用L2级别10wIOPS性能的数据盘才气扛住的业务访问压力，OceanBase 使用L1级别5WIOPS的数据盘就充足支持。
第三，主从延长稳固性进步。由于OceanBase 主从延长低，能包管从库性能使用率，进而进步了整个集群的体系稳固性及性能稳固性。现在为止，还没出现由于从副本延长过高导致全部查询都打到主副本的情况，更没有整个服务卡顿或主从延长导致主副本哀求飙升的情况。
第四，运维服从提拔，运维资源低沉。OCP提供了全量SQL诊断，资助我们更便捷地举行全局慢SQL监控。这在此前的RDS MySQL必要开启全量SQL才气实现，每天斲丧几百块钱。可以说OCP帮我们省了一笔运维费用。
不外从MySQL迁徙到OceanBase也照旧有些不兼容的地方的。如下：
1. OceanBase 4.2.1版本暂不支持全文索引，OceanBase 4.2.3版本开始支持，但该版本暂未推出GA版本，以是我们本次迁徙照旧选择了4.2.1版本。
2. OceanBase 的SQL表明实行器服从没有MySQL高，对于传入参数较多的SQL，好比in查询范围较多的情况，获取实行操持就比力慢。
3. OceanBase 在部门SQL上，范例转换的优化不如MySQL美满，比方or查询中，条件中的字符串不会自动转换为int，导致无法使用索引。
4. OceanBase 4.2.1不支持临时表。
5. 同样的SQL，实行器每次给出的查询方案大概差异。通常是数据分布和索引创建非常。该题目也存在于MySQL中，比方查询时间范围内的数据，如果指定的时间所占团体数据的15%左右，就大概不使用这个时间字段的索引，引发全表扫描。如果要陵暴使用索引，必要指定force index，会有代码侵入。相比之下，OceanBase 给出了优化方案，我们可以通过告警知道哪些SQL颠簸导致恶化，然后绑定一个实行操持，相称于在数据库运维层面办理题目。
OceanBase运维履历
在使用OceanBase的过程中，我们也积聚了一些履历，下面以题目及相应办理方法的情势举行分享。
题目1：使用读写分离署理访问时，纵然开启了事件，查询也不会使用主副本，会造成数据划一性题目。
办理方法：对应用举行改造，对开启了事件的方法，指定使用主副本署理毗连。这对于全部刚刚从MySQL迁徙到OceanBase，又必要从副本提供查询本事的用户来说，应该是一个通用的办理方案。
题目2：生产集群内存设置题目，一开始为了尽最大大概使用全部内存，我们直接指定了memory_limit=512G. 在夜间存在数据统计的大查询，导致内存溢出， 阿里云服务器直接消除了OBServer。
办理方法：一种方式是按照官方保举，memory_limit改回默认值 0M. 默认常驻使用80%的呆板内存。另一种方式是优化大查询，同时规范全部SQL誊写，在以后必要更多内存的时间，将memory_limit改为90%。
题目3：夜间归并时，磁盘使用量突增20%，触发90%预警。LSM Tree结构决定了每天必要归并数据以镌汰垃圾数据的存在。使用OceanBase 必要额外思量多加20%的磁盘空间用于归并时的空间伸缩。
办理方法：额外扩容20%的磁盘。
题目4：数据备份设置了7天规复期，但实际存储的备份量为14天。
办理方法：通过日记备份量和数据备份量分析，由于每天天生的日记备份量和整库备份使用的空间是差不多的，我们可以直接改为每天都全量备份，如许就能保持仅留存7天的备份数据了。
总体而言，OceanBase的应用符合预期，社区官方职员的实时相应和生动的社区用户互帮相助，给了我们更大的信心。由于对新数据库的不敷认识我们在使用过程中走了一点弯路，也渴望官方可以来个傻瓜式的生产设置保举，低沉小白入门采坑概率。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
上一篇：跨境电商时机，德国limango平台入驻全攻略下一篇：跨境电商概念13日主力净流出8.46亿元，国货航、供销大集居前
|
发表于 2025-1-31 22:09:11
