资讯专栏INFORMATION COLUMN

通过自研数据库画像工具支持“去O”数据库评估

Drummor / 1312人阅读

摘要:本文通过自研工具,生成数据库画像,为去评估提供一手数据,希望给大家带来借鉴。基础层分布式数据库较分库分表方式更为彻底的是直接使用分布式数据库。近些年来,分布式数据库已逐渐成熟,推广落地并开始在关键场景中尝试使用。

“去O”,是近些年来一直很火的一个话题,随之也产生了各种疑惑,包括现有数据库评估、技术选型等。去O是项系统工程,需要做好充分的评估。本文通过自研工具,生成数据库画像,为去O评估提供一手数据,希望给大家带来借鉴。

一、常见疑惑

很多公司在考虑去O的时候,经常面临这样的问题—"对自己的数据库不够了解",也不免有这样一些疑惑:

[管理者]

数据库去O成本高嘛?

工作量大不大?

工期长吗?

是否存在什么风险?

[架构师]

使用MySQL能承载现有业务规模嘛?

是否有什么技术风险?

是否需要引入分库分表嘛?

是否需要引入缓存嘛?

研发复杂度高嘛?

需要投入多大工期?

数据访问特征如何?

迁移前后对比数据量大吗?

[开发者]

复杂SQL多嘛?

改造量是不是很大?

是不是使用Oracle方言、专有对象,需要改造?

等等

面对上面这些问题,就需要快速了解现有Oracle的对象、语句、访问特征、性能表现等,并据此评估技术方案、迁移方案以及后续的工作量等。也就是说,需要给我们的数据库进行“画像”。基于上面的数据库画像,对去O工作全周期进行指导,包括以下方面都将大有裨益:

决策阶段:整体难度、成本(人财时)、技术风险

架构阶段:技术方案、对象结构、性能评估

研发阶段:兼容性、复杂度、测试

迁移阶段:结构迁移、数据迁移、数据校验

正是基于此类需求,有些公司推出评估产品,例如阿里的数据库和应用迁移服务(简称 ADAM),但此类产品往往需要部署agent,上传分析包等,对于安全比较敏感的企业不太可行。我所在的公司在两年前启动去O工作时,也面临此问题。故特意开发个绿版小程序,可在本地运行,方便评估工作。

地址:https://github.com/bjbean/ora...

二、设计思路

收集并汇总 Oracle 数据库信息,包含环境、空间、对象、访问特征、资源开销及SQL语句等六方面信息,全面覆盖数据库实际运行状况。为信息收集更有针对性,工具通过参数设置部分阈值。通过运行命令行,收集信息后生产WEB版评估报告,以可视化的方式直观体现出来。不仅可作为去O评估依据,亦可作为后续改造的数据参考。

三、画像解读

下面针对报告数据进行解读,并对常见的去O选型-MySQL进行说明。

3.1 概要信息

图1

显示收集的目标的概要信息,包括IP、实例、用户等。需注意分析时间,脚本会提取数据库执行特征(24小时内),因此建议在业务高峰之后运行。

3.2 空间信息

图2

空间大小是数据库选型需重点考虑的指标之一,也会影响到后续迁移。如库规模较大,应考虑做分拆处理。拆分的原则就是尽量控制单库规模。一般可遵循如下拆分优先原则:

1)业务层垂直拆分

在应用层面,将数据按照不同的业务条线进行拆分。例如电商平台中按照订单、用户、商品、库存等拆分。各自拆分的部分,业务内聚,无强数据依赖关系。

2)业务层水平拆分

在同一业务内部,对数据建立生命周期管理,进行数据冷热分层。针对不同层的数据访问特点不同,可做进一步拆分。例如电商平台中,针对订单可分为活跃订单(二周内,可退换货)、非活跃订单(二周至半年期,客服可受理)、历史订单(半年以上)。

3)应用层分库分表

若经过上述拆分单个库的规模仍然较大,可考虑使用分库分表技术。通常的做法是引入数据库中间层,逻辑上虚拟出一个数据库,但物理上划分为多个数据库。这是一种不太“优雅”的方案,因为很难做到应用透明。也就是说,必须在研发方面有所妥协,牺牲一部分数据库能力。常见技术方案上可分为:Client、Proxy、SideCar三类,现多推荐使用Proxy模式(容器部署可考虑SideCar模式)。

4)基础层分布式数据库

较“分库分表”方式更为彻底的是直接使用分布式数据库。它提供了一种可承载更大规模(容量、吞吐量)的解决方案。近些年来,分布式数据库已逐渐成熟,推广落地;并开始在关键场景中尝试使用。

3.3 对象信息

图3

针对Oracle中对象,在改型中各有不同的考虑要点。报告中给出汇总数据,也可给出明细数据方便查询。

1)表

表的数量过多,直接影响数据字典大小,进而影响数据库整体效率。从MySQL来看,还需考虑文件句柄等问题。这一指标没有一定之规,需根据情况酌情考虑。这里更多是数据架构层面考虑,避免单库数据表过多。曾经历过单库10万张表,性能低下;优化后整合成2万张的优化案例。如选择MySQL,建议单库不超过5000张表;库*表的总数不超过20000。

2)表(大表)

控制单表的规模,是设计的要点之一,直接影响到访问性能。表过大,应考虑采用上面的原则进行拆分。表大小没有通用原则,这里可通过参数进行配置。可按照物理大小或记录数两个维度设置。这里的关键点在于表的访问方式,如均为简单的kv型访问,规模大些还好;如访问比较复杂,则建议阈值设置更低些。如选择MySQL,大表复杂查询或多表关联等均不是其擅长场景,可考虑使用ES、solr+hbase等方式异步处理复杂查询。

3)表(分区表)

从9i、10g以来,Oracle的分区功能日趋完善、功能增强。可以说已成为Oracle应对海量数据的利器。但对于MySQL来说,仍然不太建议使用分区功能。一方面,随着硬件能力的增强,单表可承载力变大;另一方面,MySQL使用分区还需面对“DDL放大”、“锁变化”等问题。如果团队可以很好地驾驭数据库中间层,还是建议使用复杂度更低的分表技术。这也许会稍许增加研发量,但对运维来说,好处多多。

4)字段(大对象)

在任何数据库中,都不建议使用大对象。如果你用了,趁着改造工作,赶紧去掉吧。大对象功能对数据库来说,就是鸡肋。数据库自身的ACID能力,应着力保存更为重要的数据。

图4

5)索引(B树)

索引过多会影响DML效率、占用大量空间。可通过“索引/表”,大致反应出索引数量的合理程度。这里没有建议的数值,可根据情况酌情考虑。对于任何数据库来说,都有类似的问题,就是如何“构建战略性索引策略”。这里可参考下表(选自李华植-《海量数据库解决方案》一书),梳理索引需求。科学地创建、维护索引。

6)索引(其他)

Oracle除了通常的B+树索引外,还支持其他类型的索引。如选择其他数据库,那么这些索引都需要改造,通过其他方式实现。

7)视图

视图,作为SQL语句的逻辑封装,在某些场景下(如安全)很有意义。不过它对于优化器有较高要求,Oracle在这方面做了很多工作(可参看作者写的《SQL优化最佳实践》一书)。而对于MySQL,则不建议使用,考虑改造。

8)触发器/存储过程/函数

对于数据库来说,承载了计算、存储两类能力。作为整个基础架构部分最难扩展的组件,尽量发挥数据库的核心能力很重要。相较于存储能力而言,计算能力是可通过应用层解决,而应用层又是往往容易扩展的。此外,考虑到未来的可维护性、可迁移性等因素,这部分考虑在应用端解决吧。

图5

9)序列

Oracle中的序列,可提供递增的、非连续保障序号服务。在MySQL中有类似的实现,是通过自增属性来完成。这部分应该可以做迁移,但如果并发量非常大;亦可考虑使用发号器的解决方案。

10)同义词

同义词是数据耦合的表现,无论在什么数据库,都应该摒弃掉。应考虑在业务端进行拆分,不再依赖于这种特性。

3.4 访问特征

图6

这里收集了,在过去的24小时内数据库中DML次数最多的Top20。这直接地反应出当前系统的操作的“热点”对象。这些对象都需要在选型之后、迁移之前重点评估其性能表现。能考虑分拆、缓存等手段,均可减低这些对象的热点压力。不仅局限于这些对象,更建议的是建立“业务压力模型”。通过对业务充分的了解和评估后,将业务逻辑抽象出来,转化为数据压力模型。此处的难点在于对业务逻辑的抽象能力及对模块业务量的比例评估。

形成类似下面的伪代码:

图7

可依据上述伪代码,编制压力测试代码。通过一些工具调用测试代码,产生模拟测试的压力。这对于系统改造、升级、扩容评估、新硬件选型等均有意义。在具体去O工作中,新技术方案是否满足需要,可通过此方法进行评估验证。更多用业务的语言,来对比去O前后的承载力变化。这也是决策技术方案是否可行的考虑因素之一。当然上述信息,只包括了DML,对查询部分是不包含的,可以从Oracle AWR中获得这些数据。更为完整的,可以考虑结合应用做全链路的压测。

3.5 资源消耗

图8

这里列出了最近24小时的资源使用情况。这些数据主要有两个目的:

1)评估整体负载

因为上述指标是Oracle的度量显示的,无法直接类比到其他数据库。可以凭借专家经验+历史数据,评估负载压力。用于对其他备选技术方案进行评估的依据之一。这其中的有些指标(例如user calls等),可以转化为量化指标指导后续测试等工作。

2)评估瓶颈点

对于某项指标非常突出的情况,那说明现有业务也有瓶颈,在迁移至其他方案时尽量在设计阶段就予以考虑,并在测试环节重点关注,减少可能的技术风险。

3.6 SQL语句

图9

SQL语句的改写,是整个迁移工作中最为头疼的部分。除非是完全重构,否则是需要关注SQL改写的工作任务。这里面涉及到改写量、复杂度、性能对比等诸多内容,很多还是需要人工甄别完成。

笔者曾经有过这样的经验,项目组花1个月的时间就完成某项目的“结构+SQL”的迁移工作,但是后续又花费了3个月的时间完成语句优化、甚至结构调整。其原因是迁移上线后语句无法满足性能需求。而这是在边上线、边调整,过程异常痛苦。因此早期查明现有SQL情况,对于评估工作量、改写难度、性能评估,有着重要的意义。而上面这部分就是收集了分析用户在历史的所有SQL(可以打开明细开关,显示全量SQL),其包含了以下这些维度。

1)总SQL数

该指标可近似反映业务繁忙程度。此外,也可用于后续有问题语句的比例分析基础。

2)超长SQL

这里列出了超过指定字符数的语句,阀值在可通过参数进行配置。如果是考虑MySQL,建议使用“短小精悍”的SQL,面对复杂SQL则一般表现不佳。那么对于这些超长的语句,都是值得关注的对象,起码是容易出现问题的语句。

3)ANTI SQL

反向查询,数据库处理上都较为困难,这部分也比较考验优化器。虽然在MySQL的较新版本中,对反向查询有了不错的优化,但这部分仍然值得关注。

4)Oracle Syntax SQL

有Oracle特征的写法,即Oracle的方言(例如特有函数、伪列等),这些都是需要在迁移中进行处理的。当然现在也有的厂商,宣布其产品是兼容Oracle语法的,但也建议针对这些做专门测试。

5)Join 3+ Table SQL

多表关联,也是比较考验优化器。特别是MySQL表间关联效率偏低,不建议使用超过2个以上表的关联。这里列出的是3个及以上的关联查询,需要考虑修改。针对特别复杂的查询,可以考虑将其卸载到大数据平台完成。

6)SubQuery SQL

子查询情况类似上面,也是MySQL不擅长的。虽然优化器可在一定程度上进行优化,但还是值得关注。

作者:韩锋

首发于公众号《韩锋频道》,欢迎关注。

来源:宜信技术学院

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/49255.html

相关文章

  • 通过自研据库画像工具支持O据库评估

    摘要:本文通过自研工具,生成数据库画像,为去评估提供一手数据,希望给大家带来借鉴。基础层分布式数据库较分库分表方式更为彻底的是直接使用分布式数据库。近些年来,分布式数据库已逐渐成熟,推广落地并开始在关键场景中尝试使用。 去O,是近些年来一直很火的一个话题,随之也产生了各种疑惑,包括现有数据库评估、技术选型等。去O是项系统工程,需要做好充分的评估。本文通过自研工具,生成数据库画像,为去O评估提...

    GT 评论0 收藏0
  • “大数据+”实践:数据平台的设计与搭建

    摘要:在近期举办的全球架构师峰会上,个推首席数据架构师袁凯,基于他在数据平台的建设以及数据产品研发的多年经验,分享了面向机器学习数据平台的设计与搭建。二具体开展机器学习的过程原始数据经过数据的处理,入库到数据仓里。 机器学习作为近几年的一项热门技术,不仅凭借众多人工智能产品而为人所熟知,更是从根本上增能了传统的互联网产品。在近期举办的2018 ArchSummit全球架构师峰会上,个推首席数...

    BlackHole1 评论0 收藏0
  • 数据在人力资源管理当中的应用

    摘要:对数字的利用在推动人类文明进步的时候都发挥了重大作用例如美国制宪会议。在随后的几十年内,摩尔定律被无数次的被印证。 大数据时代 数字与人类文明 数字是人类发明的最重要的概念之一,与整个人类文明进程相伴相生 早在8000年前美苏尔地区商人利用泥球计算商品销量 showImg(http://upload-images.jianshu.io/upload_images/1382...

    dance 评论0 收藏0
  • UAVStack的慢SQL据库监控功能及其实现

    摘要:页面展示的统计追踪等信息则通过的接口获取四功能展示数据库监控目前已实现的功能有分类统计数据库连接池监控慢耗时分布统计慢统计慢追踪以及调用链日志关联功能。 作者: 王林林 出处:UAVStack智能运维 来源:宜信技术学院技术沙龙001期|AI中台:一种敏捷的智能业务支持方案|宜信技术沙龙 3月28日晚8点线上直播,点击报名 UAVStack是一个全维监控与应用运维平台。UAV.Mon...

    biaoxiaoduan 评论0 收藏0
  • UAVStack的慢SQL据库监控功能及其实现

    摘要:页面展示的统计追踪等信息则通过的接口获取四功能展示数据库监控目前已实现的功能有分类统计数据库连接池监控慢耗时分布统计慢统计慢追踪以及调用链日志关联功能。 作者: 王林林 出处:UAVStack智能运维 来源:宜信技术学院技术沙龙001期|AI中台:一种敏捷的智能业务支持方案|宜信技术沙龙 3月28日晚8点线上直播,点击报名 UAVStack是一个全维监控与应用运维平台。UAV.Mon...

    luodongseu 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<