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

三、画像解读

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

3.1 概要信息

1563773765885026509.jpeg

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

3.2 空间信息

1563773771705003550.jpeg

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

1）业务层垂直拆分

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

2）业务层水平拆分

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

3）应用层分库分表

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

4）基础层分布式数据库

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

3.3 对象信息

1563773778745085922.jpeg

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

1）表

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

2）表(大表)

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

3）表(分区表)

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

4）字段(大对象)

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

1563773786335094667.jpeg

5）索引(B 树)

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

6）索引(其他)

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

7）视图

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

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

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

1563773796045065132.jpeg

9）序列

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

10）同义词

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

3.4 访问特征

1563773803295039242.jpeg

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

形成类似下面的伪代码：

1563773812266093260.jpeg

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

3.5 资源消耗

1563773820215051083.jpeg

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

1）评估整体负载

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

2）评估瓶颈点

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

3.6 SQL 语句

1563773828645024682.jpeg

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 不擅长的。虽然优化器可在一定程度上进行优化，但还是值得关注。

本文转载自宜信技术学院网站。

原文链接：http://college.creditease.cn/detail/277