【腾讯云TDSQL-C Serverless 产品测评】大数据时代是谁在国产数据库中开荒？

【腾讯云TDSQL-C Serverless 产品测评】大数据时代是谁在国产数据库中开荒？

在这里插入图片描述

@TOC

活动背景

“腾讯云TDSQL-C产品测评活动”是由腾讯云联合CSDN推出的针对数据库产品测评及产品体验活动，本次活动主要面向TDSQL-C Serverless版；

本次参与活动涵盖不同技术层面的用户，初步的产品体验或针对TDSQL-C产品的自动弹性能力、自动启停能力、兼容性、安全、并发、可靠性等多方面的产品测评，并通过征文的方式输出，参与活动的同时既可以收获相关技术领域的实战经验同时也可获得丰厚的活动激励。

点击参加活动

前言

最近在CSDN上也是看到关于腾讯云 TDSQL-C Serverless 数据库的活动，每次遇到陌生领域的东西，我觉得都很有必要参与一下，这次也是不例外，不过我觉得不仅仅是因为我没使用和了解过，主要是数据库本身就在我们的软件工程中就是非常重要的，随着软件的发展，编程语言对整个系统的影响越来越小，我们所见到的数据，所提交的表单，都需要我们的底层数据库有一个良好的支撑，所以在数据库的选择上是至关重要的；

为什么我觉得腾讯云的 TDSQL-C Serverless 数据库是值得研究的呢？

以下是官网举例的一些优势

1. 它可以完全兼容开源数据库 MySQL 5.7、8.0，业务无需改造即可平滑迁移
2. 超高性能：单节点百万 QPS 的超高性能，保证关键业务的连续性，并可进一步提供读写分离以及读写扩展性。
3. 海量存储：最高支持 PB 级的海量存储，为客户免去面对海量的数据时频繁分库分表的繁琐操作，同时支持数据压缩，在海量数据检索和写入性能上进行了大量优化。
4. 秒级故障恢复：计算节点实现了无状态，支持秒级的故障切换和恢复，即便计算节点所在的物理机宕机也可以在一分钟之内恢复。
5. 数据高可靠：集群支持安全组和 VPC 网络隔离。自动维护数据和备份的多个副本，保障数据安全可靠，可靠性达99.9999999%。
6. 弹性扩展：计算节点可根据业务需要快速升降配，秒级完成扩容，结合弹性存储，实现计算资源的成本最优。
7. 快速只读扩展：计算节点可根据业务需要快速添加只读节点，一个集群支持秒级添加或删除1个 - 15个只读节点，快速应对业务峰值和变化场景。
8. 快照备份回档：基于数据多版本的秒级快照备份对用户的数据进行连续备份保护，免去主从架构备份回档数据的同步和搬迁，最高以GB/秒的速度极速并行回档，保证业务数据迅速恢复。
9. Serverless 架构：Serverless 是腾讯自研云原生数据库 TDSQL-C MySQL 版的无服务器架构版，自动扩缩容，仅按照实际使用量计费，不用不计费，轻松应对业务数据量动态变化和持续增长。

说实话，光看优点很吸引人，但是对于没有使用过的用户来说，谁知道是不是吹牛呢？真金不怕火炼，我带着这个想法开始了对它数据库的一个测评！

本次测评内容主要围绕两方面进行：

1. 兼容性测试
2. 可用性测试

TDSQL-C Serverless环境搭建

整个环境构建非常的简单其实，官方的文档特别明了，这里我简要概述一下我的搭建过程，正常到 TDSQL-C 控制台是没有集群的，是下面这个状态

在这里插入图片描述

然后我们点击去购买集群，就会到购买页

在这里插入图片描述

根据我们的地区，和实例形态就可以进行购买了，之后下一步下一步设置密码和实例的配置就可以创建成功了，整个实例是按量付费的，而且没有流量来的时候实例是暂停的，所以根本不需要多少钱，所以大家也不用担心，参与实验的成本特别低！

1.0 兼容性测试

当涉及兼容性测试时，我主要是重点测试以下几个方面的兼容性：

• 索引：验证数据库中的索引是否能够在tdsql数据库中正确地创建和使用，以确保查询性能和数据完整性的兼容性。
• 存储过程：检查老项目中存在的存储过程是否能够在tdsql数据库中正确执行，并确保其逻辑和功能的兼容性。
• 视图：验证系统中使用的视图是否能够在tdsql数据库中正确定义和使用，以确保数据的一致性和查询结果的兼容性。
• 数据表：确认数据表的结构和约束是否能够在tdsql数据库中正确创建，并保持数据的完整性和兼容性。
• 触发器：检测触发器是否能够在tdsql数据库中正确触发和执行，以确保业务逻辑的兼容性和数据的一致性。
• 事件：验证事件是否能够在新系统中按预期调度和执行，以确保定时任务和事件处理的兼容性。

在我们的很多老项目中，存储过程的使用非常常见，并且视图在系统中也广泛运用。因此，对于兼容性测试来说，这些方面都是不可或缺的。我们需要确保这些核心组件在新系统中能够正确运行，以保证平稳的迁移和功能的无缝衔接。

1.1 构建测试环境

这里我是通过利用我的个人线上博客进行测试的，数据库中还有一些文章数据，数据库版本如下：

• mysql5.7.16-log

TDSQL-C Servless数据库版本如下：

• 5.7.18-cynos-log

然后我们开始构建我们的一些测试数据！！

1.1.1 针对文章表创建视图

SQL如下：

create view posts_view as select * from posts

在这里插入图片描述

1.1.2 针对文章增加索引

这里我主要创建了三个索引类型：

1. 唯一索引：针对 post_slug 创建
2. 普通索引：针对 uuid 字段创建
3. 多字段联合索引：针对 author_id 和 created_by 构建复合索引

这样可以有效观察数据库是否能够平滑将各种索引进行迁移

在这里插入图片描述

1.1.3 创建触发器

我的触发器逻辑是：当文章的title进行修改后就增加一条记录到log_table表中，记录好前值和修改后的值

首先我创建了一张 log_table

在这里插入图片描述

• 触发器sql代码如下

CREATE TRIGGER alter_event
BEFORE UPDATE ON posts
FOR EACH ROW
BEGIN
    IF NEW.title <> OLD.title THEN
        INSERT INTO log_table (event_type, event_description) VALUES ('Update', CONCAT('title updated from ', OLD.title, ' to ', NEW.title));
    END IF;
END;

在这里插入图片描述

然后我们将posts表中的title字段进行修改，看看触发器是否正常：

在这里插入图片描述

在这里插入图片描述

这样我们的触发器就算可以了！

1.1.4 创建事件

这个事件的主要逻辑就是每一秒对 log_table 插入一条测试数据：

在这里插入图片描述

• inert_event sql代码如下

CREATE EVENT insert_event
ON SCHEDULE EVERY 1 SECOND
COMMENT 'This event inserts a new record every second'
DO
    BEGIN
            INSERT INTO log_table (`event_type`, `event_description`)
            VALUES ('test event', 'test event');
		END;

• 查看所有事件

在这里插入图片描述

1.1.5 创建储存过程

这个存储过程的逻辑就是查询 posts 表中的 id 字段，然后循环将 id 字段改为大写进行修改

• 存储过程sql如下

DELIMITER //

CREATE PROCEDURE ConvertIdToUpperCase()
BEGIN
    DECLARE done INT DEFAULT FALSE;
    DECLARE currentId VARCHAR(255);
    
    -- 游标声明
    DECLARE cur CURSOR FOR
        SELECT id FROM posts;
    
    -- 游标异常处理
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
    
    -- 打开游标
    OPEN cur;
    
    -- 循环读取并更新每一行数据
    read_loop: LOOP
        -- 读取下一行数据
        FETCH cur INTO currentId;
        
        IF done THEN
            LEAVE read_loop;
        END IF;
        
        -- 将 id 字段转换为大写
        UPDATE posts SET id = UPPER(currentId) WHERE id = currentId;
    END LOOP;
    
    -- 关闭游标
    CLOSE cur;
    
    -- 打印操作完成信息
    SELECT 'Id 字段转换为大写完成。';
END //

DELIMITER ;

在这里插入图片描述

到现在为止，我们的测试环境就算构建的差不多了

1.2 执行兼容性测试

这里我们测试主要过程是：

1. 利用mysqldump将我们目前的数据进行导出
2. 通过腾讯dmc平台进行sql文件导入
3. 观察导入后的数据是否正常 - 索引 - 触发器 - 事件 - 表结构 - 存储过程等1.2.1 使用mysqldum进行数据导出

mysqldump -uroot -h 81.69.6.xx -p --port=3307 --routines --triggers --events -B blogs.szaecs.com > backup.sql

在这里插入图片描述

1.2.2 通过 DMC 平台进行数据导入

得到 backup.sql 后，我们通过腾讯云的 DMC 管理平台进行导入，首先在集群页面找到登录按钮，然后逐步按照截图进行即可！

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

点击开始后就可以开始执行任务了，这里我们可以看到已经成功了

在这里插入图片描述

接下来就是验证索引、存储过程、视图、事件、触发器是否正常

1.2.3 视图测试验证

主要看视图是否能够正常查询，并且数据是否正常

在这里插入图片描述

1.2.4 索引测试验证

在这里插入图片描述

1.2.4 存储过程测试验证

在这里插入图片描述

1.2.6 触发器测试验证

在这里插入图片描述

1.2.7 事件测试验证

在这里插入图片描述

1.3 兼容性测试总结

综合来看，对于我要测试的一些场景和数据来说是完全兼容且完整的，通过 索引、存储过程、触发器、事件、视图 来看，

我们日常使用的Mysql的数据库和TDSQL-C Mysql Serverless是完全兼容！这意味着，对于我们以前的传统数据库可以无缝完好地迁移到 TDSQL-C Mysql Serverless 中，而无需担心数据丢失或兼容性问题。

这其实是一个很重要很关键的事情，数据库是我们业务的核心，当我们决定迁移数据库时， 确保兼容性是至关重要的。

2.0 可用性测试

这里的可用性测试我主要是通过一些高危操作，例如误删数据等，进行特定库表恢复，其实可用性测试远不止如此，但是我们对于数据库最重要的就是数据的安全性，所以以这个为例，希望大家可以更好地判断数据库的选型！

无论是按时间点恢复还是按备份集恢复，都需要先将备份数据回档到原集群中，然后进行数据比对。

在这里插入图片描述

2.1 构建可用性测试环境

首先，在测试前，我们也是先手动全量备份一下集群，正常是可以通过设置每天自动备份的，这里为了更好的演示，我先进行一次全量备份：

在这里插入图片描述

在这里插入图片描述

这样就是全量备份好了，然后我们模拟删除一张表的数据，这里我把 log_table 这张表的数据删除了

在这里插入图片描述

2.2 验证可用性

2.2.1 执行回档

因为这里我知道时间，所以这里我直接回档到 19:00，也可以按照备份文件回档

在这里插入图片描述

在这里插入图片描述

2.2.2 回档数据对比

• 原始表
  

  在这里插入图片描述
• 回档表
  

  在这里插入图片描述

2.3 可用性测试总结

事实证明，当集群中的某个表或数据被误删或误修改，需要将其恢复到原有状态时，TDSQL-C Mysql Serverless 数据库是完全能够保护数据的完整性的，用户可以根据时间点和备份集进行选择恢复，并且在创建集群后，系统是默认开启自动备份，根据日志生成速率等因素，实现24小时不间断备份，备份文件生成周期间隔6～48小时不等，用户也可以根据业务需求，在控制台对备份保留时间进行设置，基于此，当对集群操作库表级恢复时，控制台会直接向用户展示可恢复的时间点和备份集。

总结

其实最终不管怎么测试，我也没有办法将整个产品的能力都测试出来，不管是兼容性还是可用性测试，都是我的个人观点，不过最终测试结果，也证实了产品宣传的真实性；

经过这次的深入体验，我也想到一个场景是我可以替换成TDSQL-C Mysql Serverless 的 ，像我们的开发测试环境和一些低频查询场景，夜间几乎没有查询或写入，然后我们就可以通过 serverless数据库 的特性，利用业务负载自动启动停止，无感扩缩容。计算节点关闭期间也不计费，设置最小cpu 和最大cpu 实现弹性扩缩容根据实际负载按秒计量，按小时结算。

这样我们既满足了业务对计算的需求，又在低峰节约成本，最大化利用资源。

同时我也总结了一下 TDSQL-C Serverless数据库系统相较于传统数据库系统具备 4 个方面的优势:

1. 弹性: TDSQL-C Serverless数据库可以基于工作负载实现自动扩缩容， 使实际资源使用量实时匹配于工作负载，避免因预先部署资源不足导致的业务容量瓶颈。
2. 可用性: 云数据库同时维护多个计算和存储副本以保证系统的高可用性
3. 灵活性: 开箱即用的特性让用户免于复杂的数据库部署过程； 系统支持自动化的运维调优，降低用户的管理压力.
4. 低成本: 按需计费模型让用户仅需为实际资源使用量付费，而非传统的预置模式， 结合实际工作负载的波动性， 云数据库能大幅降低用户的使用成本。

最后，希望本文能够为大家在数据库选型及 TDSQL-C Serverless 版的使用上提供一些有效的帮助。