共计 2997 个字符，预计需要花费 8 分钟才能阅读完成。
文 / OceanBase 解决方案架构师 韩冰
该企业成立于 1999 年，是国内当先的财税信息化综合服务提供商，次要为税务机关提供税务系统开发与运维，为征税企业和财税中介提供互联网财税综合服务。
通过多年倒退，为了更好地撑持用户业务需要和数据需要，该企业倒退出规模宏大的 IT 基础设施规模，领有私有云、公有云等多样基础设施，软件层面同样具备很高的复杂度。这无疑给企业在老本、运维、开发效率上带来了种种挑战。
作为一家器重技术，心愿通过技术给社会带来美妙扭转的公司，该企业始终在严密关注、亲密跟踪前沿技术的发展趋势。通过一直地考察钻研新技术并引入新技术，不仅实现了对业务的赋能，还同时实现了各项效率的晋升和老本的升高。本文，仅就数据库这一维度，分享其倒退历程、选型思考以及播种功效。
从集中式到真正的分布式
如下图所示，数据库从集中式到真正的分布式，经验了四个阶段的倒退历程。在企业倒退初期，业务规模较小时，集中式架构的数据库产品就能够满足业务倒退需要，MySQL 成为业务的首选，通过 RAID 和主备集群就能够比拟好地满足容灾需要。
但随着业务量的大幅增长，给数据库带来大量流量和大量数据撑持的需要，此时，集中式数据库曾经无奈很好地满足业务须要。 为了满足业务需要，企业不得不对数据库进行拆分，以分库分表形式的分布式架构计划尤为风行。 其中，支流的分库分表计划如下：
- 计划一：嵌入业务的分布式架构，利用嵌入分布式 SDK，在业务层做分库分表处理；
- 计划二：中间件的分布式架构，通过引入分库分表中间件，集中处理分库分表。
应用分库分表的形式能够疾速减少数据库的服务和存储容量，但同时也对业务和运维工作提出了新的要求和挑战。比方：
- 利用分布式革新， 无论应用嵌入业务或者中间件的分布式架构，都须要业务 SQL 为了适应分布式进行革新，并且因为底层的节点都是各自独立的，对于索引、复杂事物、和关联业务都有比拟多的限度；
- 节点无奈按需扩大， 因为应用比拟固定的分库分表规定，同时思考扩容需要，分库分表的形式个别要求扩容都是等比扩容，即扩容一次就要扩容到原来资源配置的一倍，灵便度比拟低；同时，因为各自实例独立，导致扩容后有大量的节点间数据迁徙，对服务质量有比拟大的影响；
- 初始节点数多， 因为以上两个起因的限度，为了屏蔽掉革新和扩容对业务以及数据歪斜的影响，个别都会一次布局到位，导致初始节点数量比拟多，整体资源利用水位比拟低。
分库分表的分布式架构在承载业务倒退的同时，也暴露出各种弊病，这也证实了这种计划只是分布式架构的两头过渡计划。之后，新数据模式的分布式架构，即原生的分布式架构呈现，很好地解决了分库分表的分布式架构的问题。原生分布式架构可能提供更好的服务能力，也是更好地解决以后业务阶段降本提效诉求的一种更无效的伎俩。
抉择提高技术播种显著功效
明确采纳原生分布式架构的数据库后，企业开始从泛滥产品中选型可能替换分库分表中间件的数据库产品，思考到将来的久远倒退以及与业务符合度，最终选定 OceanBase，并迅速开展迁徙工作。
▋ 资源整合，多套实例收归一套集群
原有分库分表架构下，各个物理表别离由不同的 MySQL 实例提供服务。因为业务顶峰时段数据歪斜的存在，必然导致不同 MySQL 实例在不同时间段简单不平衡。为了保障业务安稳，须要为每个 MySQL 配置满足业务平安的最大配置规格，这必然导致资源应用上的节约。
OceanBase 能够通过应用分区表形式将原来的分库分表的物理表汇聚到一个物理表，同时还能够保留原来的映射关系。
通过将物理分区正当散布到多个计算节点上，充沛应用所有计算资源，在保障资源应用在正当的水位根底上，将原来多个 MySQL 实例的计算资源整合到一个 OceanBase 集群中。通过 OceanBase 提供的主动平衡能力，保障每个节点的资源应用绝对均匀，保障资源的充分利用。
企业将原来配置了 16 个 8C16G 资源规格的 MySQL 迁徙到 OceanBase，仅应用 32C 双机房的 OceanBase 集群就能稳固撑持业务服务质量，计算资源节约显著。
▋ 高级压缩技术，节俭 85% 存储空间
通过二十余年的倒退，企业有着宏大的数据存量，始终在寻找一款既能节俭数据存储老本，还能保有原性能甚至晋升性能的数据库。经理解和调研，得悉 OceanBase 应用 LSM-Tree 存储引擎，采纳密实存储打消了存储空洞，在存储上应用行列混存的形式，同时通过对列数据进行编码，并且对编码后的数据最终提供了高级压缩的能力。
应用该高级压缩能力，存储压缩成果非常明显。比方，某个业务原来的数据量在 原数据库大概上有 20T，将这些数据迁徙到 OceanBase 后，只占用了 3T 的数据存储，相当于节俭了 85% 的存储空间。
▋ HTAP 让一份数据既能事务处理又能实时剖析
因为原数据底层存储理论散布在不同的 MySQL 实例上，如果想在全库级别进行简单查问，须要将数据会集到一处，且须要多条数据迁徙链路和汇聚剖析库的配置。如此一来，会导致两个问题：
- 问题一，数据时效性。 因为应用数据同步链路进行数据迁徙，分库分表中间件后端理论的 MySQL 实例越多，须要的数据同步链路就越多。在所有链路失常同步的状况下，数据提早取决于同步的速度。如果任何一条同步链路产生提早都会产生木桶效应，数据的最大提早取决于最慢链路的速度。
- 问题二，老本上涨。 以后架构下的老本分列为两项，一项是同步链路的老本，这个老本由同步的链路数量和数据的决定；另一项是汇聚剖析库的老本，这个老本由资源配置和数据量决定。
大数据时代，实时数据分析必不可少，作为国内当先的财税信息化综合服务提供商更是如此。然而，以上数据时效性和老本上涨的问题，始终困扰着企业。
OceanBase 能够在一份数据上进行 HTAP 的解决，不须要数据同步和新洽购汇聚剖析库。同时，企业能够设置剖析业务应用的资源配置或者调整主可用区独立一份资源给到剖析业务应用。通过以上伎俩保障不会因为剖析 AP 业务占用过多资源，导致在线 TP 业务的不稳定性。
携手共进，期待迁徙便利性更上一层楼
如下图所示，为迁徙过程示意图。
- 正向迁徙过程： 应用 OMS 工具迁徙分库分表中间件后端理论的 MySQL，如此，分库分表中间件后端的每一个 MySQL 须要独自一条链路进行数据迁徙到 OceanBase；在迁徙之前，须要依据分库分表中间件的表后果先批改 DDL 在 OceanBase 建设表构造。
- 反向迁徙过程： 在业务切换到 OceanBase 之后，业务写入的数据须要从 OceanBase 将增量数据通过 OMS 工具写入到分库分表中间件里。
通过上述迁徙过程能够看到，尽管整体应用过程在性能和效率上都有所保障，然而须要很多独立的 OMS 链路，整个流程的配置和保护复杂度都比拟高。
作为 OceanBase 的使用者和受益者，为了让更多业务享受分布式降级带来的降本提效收益，从业务角度登程，OceanBase 迁徙的便利性改良，将是最期待的改良点：
- 主动构造迁徙。 因为分库分表中间件的建表 DDL 迁徙到 OceanBase 的批改过程，规定是比拟固定的，后续将分库分表中间件的构造迁徙主动实现将带来很大便利性；
- 对立的正向数据迁徙。 在正向迁徙过程中须要依据理论的 MySQL 数量配置 OMS 理论迁徙链路，包含后续的数据校验和切换都须要独自操作，将这个过程统一化将大大加强操作便利性。更进一步，在将正向的数据迁徙过程对立后，能够不便地减少反向迁徙的链路。
