背景介绍
中盾数科集团始创于2012年，是由网络安全服务而发展起来的科技型、多元化的企业集团。旗下包括网络安全服务、信创一体化服务、箱式液冷、区块链、位置服务、视觉服务等六大板块，业务覆盖湖南、甘肃、贵州等多个省份。
业务挑战
中盾集团基于AI模型的云数据分析平台很好地支持了公司网络安全的相关业务。但是随着多年业务的发展与数据积累，也面临诸多挑战：
- 数据量大，高并发更新：云数据分析平台对接很多的上游网络安全数据源，数据库每天需要写入千万级数据并伴随高并发的更新请求，当前的数据库系统遇到扩展瓶颈。
- 复杂查询影响线上业务：数据分析平台存在大量复杂查询，需要对数据进行Join 和聚合操作，需要能在不影响在线业务的前提下快速返回查询结果。
- 历史数据维护复杂：随着数据量积累达到数十TB 以上，在线数据库已力承载。虽然将部分表2年以上数据作为历史数据进行归档，减轻了在线数据库压力，但业务层面存在强烈的“冷热数据”混合查询需要，只能通过访问两套数据库，并在业务层进行数据合并，造成较大的运维和分析成本。
解决方案
经过多方面对比测试，中盾集团最终采用 PolarDB-X 云原生分布式数据库开源版本支持其网络安全数据平台业务。
基于开源的 polardbx-operator, 中盾数科在 Kubernetes 集群上快速完成数十节点的PolarDB-X 部署，将数据迁移至PolarDB-X，未增加业务改造成本的情况下，完成业务切换。下图给出了中盾数科部署的 PolarDB-X 数据库的信息：
PolarDB-X 提供的高性能、高可扩展性，很好地解决了当前业务的痛点，支撑业务的快速发展。
透明分布式，高效支撑高并发写入
PolarDB-X 的透明分布式能力，使中盾可以像使用单机 MySQL 数据库一样使用分布式数据库，从原数据库架构升级至 PolarDB-X 集群，无需任何业务改造，极大节约了运维成本，提升架构升级效率。
例如中盾系统中记录用户交易记录的表结构如下：
CREATE TABLE `transation_statement` ( `id` bigint(20) NOT NULL COMMENT '序列号', `src_account_no` varchar(30) DEFAULT NULL COMMENT '转账账号', `dst_account_no` varchar(30) DEFAULT NULL COMMENT '收款账号', `trx_amt` decimal(20,2) DEFAULT NULL COMMENT '交易金额', `trx_date` varchar(30) DEFAULT NULL COMMENT '交易时间', ...... PRIMARY KEY (`id`), index idx_src_account(src_account_no), )
迁移到 PolarDB-X 后，基于自动分区的能力，表结构无需改变，即可实现数据的自动打散, 将数据均匀分布到多个DN 节点上。使用上述CRATE TABLE 语句在 PolarDB-X 执行后，实际的表结构如下。可以看到 PolarDB-X 已经默认按照主键 id 分区，打散数据。
mysql> show full create table transation_statement\G *************************** 1. row *************************** Table: auto_t1 Create Table: CREATE TABLE `transation_statement` ( `id` bigint(20) NOT NULL COMMENT '序列号', `src_account_no` varchar(30) DEFAULT NULL COMMENT '转账账号', `dst_account_no` varchar(30) DEFAULT NULL COMMENT '收款账号', `trx_amt` decimal(20,2) DEFAULT NULL COMMENT '交易金额', `trx_date` varchar(30) DEFAULT NULL COMMENT '交易时间', ...... PRIMARY KEY (`id`), GLOBAL INDEX /* idx_src_account_$6425 */ `idx_src_account` (`src_account_no`) PARTITION BY KEY(`src_account_no`,`id`) PARTITIONS 20, LOCAL KEY `_local_idx_src_account` (`src_account_no`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 PARTITION BY KEY(`id`) PARTITIONS 20
同时，基于 PolarDB-X 分布式的线性扩展能力，不仅可以满足每天大量数据写入/更新的需求，更重要的是，PolarDB-X 还支持进一步扩展，最大可扩展至 1024 节点，支撑 PB 级的数据量，轻松化解数据快速增长带来的焦虑和业务压力，无需为数据库的扩展性担忧。
HTAP 一体化，满足复杂查询的需求
PolarDB-X 提供列存索引，一张表可以同时具备行存和列存的数据，通过CREATE CLUSTERED COLUMNAR INDEX这样的 DDL 即可为行存表创建列存索引，实现行列数据的混合存储。面向行列混合场景设计SQL优化引擎，通过一套引擎支持行列混合查询，能够在一套数据库内很好地满足业务复杂查询的需求。
众所周知，数据分析场景一定会占用比较大的数据库资源，包括CPU、IOPS、内存等，PolarDB-X 提供的从计算到存储的“全链路资源隔离”能力，首先行存主要在DN多副本上，列存是在OSS对象存储上，确保行存和列存数据在IO读取层面完全隔离，其次支持列存只读实例，可以通过业务直连 或者 通过主集群地址读写分离的方式路由，确保SQL引擎的计算链路也可以完全隔离，确保了中盾分析查询业务（AP）与在线的业务（TP）安全、稳定、高效运行。
冷数据归档，解决历史数据的痛
历经多年发展，中盾沉淀了大量的历史数据，除了需要确保这些归档数据安全、低成本的存储，还时常需要基于新老数据混合分析，挖掘数据价值。
针对大量历史数据的问题，PolarDB-X 提供冷数据归档能力，支持按照时间维度自动将超过一定时限的历史数据转存至低成本的对象存储（OSS， S3， Minio）上，形成一张归档表。
对于上面介绍的交易记录表，可以通过如下的 DDL，方便地将其转换成TTL 表，实现数据根据交易日期自动归档，将两年前的历史数据更新至低成本存储上。
ALTER TABLE `transation_statement` LOCAL PARTITION BY RANGE (trx_date) STARTWITH '2021-01-01' # 初始时间分区。TTL表会把“初始时间分区”作为第一个分区。 INTERVAL 1 MONTH # 时间分区的间隔，支持的时间粒度为YEAR、MONTH、DAY EXPIRE AFTER 24 # 指定分区失效的时间，此处是24个月 PRE ALLOCATE 6;
PolarDB-X归档表同样支持高效的主键与索引点查、复杂分析型查询，业务上可以在一套数据库内完成在线与历史数据的查询分析，具备两边数据实时Join的查询能力，大大降低当前历史数据的维护成本。
应用效果总结
- 基于 polardbx-operator，仅用十多分钟完成生产级 PolarDB-X 分布式集群的部署，支撑业务迁移。
- 基于 PolarDB-X 的 HTAP 能力，复杂查询的耗时从原先的10多秒优化至4秒以内，提升了系统的分析效率。
- 结合冷数据归档的能力，可以降低历史数据的存储与查询成本，最高可做到原来的1/20，同时原先针对冷热数据的多次查询也能够一条SQL搞定，详见《1/20的成本！PolarDB-X 冷热分离存储评测》
