一、前言
- 企业 & 行业 & 业务介绍
目前的业务以水务行业为主，涉及灌区、水厂、河流、水库等。
- 目前遇到的数据库挑战
系统业务往往涉及到很多物联网数据采集，这些数据往往点位很多，存储间隔小，写入频繁，存储开销大，使用查询效率也是一大问题。
- 参加活动的原因
公司部分项目体量不大，并没有足够的资源来支撑高可用多节点的部署模式，敏捷模式的出现比较符合小项目的实用场景，想借此来试验其在后续项目中的选择可行性。
- 敏捷模式的体验总结
更适合小规模项目，使用方便；但对于大体量项目还是适合分布式多节点的模式。
- 敏捷模式是否能应对该挑战
比较适配信创条件要求的小项目。
二、平凯数据库敏捷模式功能体验
- 数据迁移体验
这次是首次尝试DM进行迁移，以往的迁移主要通过navicat的备份还原或数据传输功能进行操作，但也遇到过以下几个问题：
- 部分字符集的转换报错问题，之前的做法都是手动调整解决的
- 数据量稍微大一点就容易失败，迁移过程中卡死甚至直接程序崩溃导致失败
通过DM迁移，除了刚开始不熟悉操作，安装配置环境花了些时间，迁移过程就顺畅湿滑很多，字符集会自动转换成兼容的格式，数据量较大的场景下也更有保障。
- MySQL 兼容性
整体来说对于mysql的兼容性做得很好，现有的项目从mysql转到tidb基本上都能很平滑的进行迁移，代码层面几乎没啥改动。
遇到过的最大的问题在于不支持存储过程，这部分目前来说主要靠转换成程序语言去实现；其次是部分字符集的兼容性问题，不过目前测试下来通过DM迁移能够比较好的进行解决。
- 压缩比
同样的数据对比下来如下，很明显的要少很多
-
在线 DDL 操作易用性
日常操作中基本没遇到过啥问题，在使用navicat工具进行字段增加时倒是遇到过一个语法兼容性问题，同时新增多个字段操作会报错，检查下来发现是由于tidb不支持after语法，只能改为单个字段操作，期望后续tidb能兼容该语法，毕竟日常很多时候是借助navicat来操作数据库。
-
高可用/容灾（敏捷模式三节点）：
由于本地资源限制暂未测试多节点的模式
-
可扩展性：
通过Tem能很方面的扩展组件，如下图所示直接动态添加之前未安装的TiFlash组件，整个过程不影响现有数据库服务运行，操作也简单便捷。多节点的操作也类似，但由于手上服务器资源有限暂未测试。
-
敏捷模式性能表现：是否满足实际业务场景性能需求（附上截图，如有）
准备了3个数据库进行单机环境条件下的测试，tidb敏捷版、tidb社区版、mysql。
1）测试事务批量插入10W数据
2）测试事务批量插入50W条数据
3）聚合查询，基于模拟生成的600W数据进行测试
select sum(age) from test_demo;
执行该sql后，敏捷版耗时3.662s，社区版耗时0.688s，mysql耗时11.724s。
二次查询后，敏捷版和社区版耗时均在0.2s左右，mysql耗时始终在1-2s。
select sex,sum(age) from test_demo GROUP BY sex;
执行该sql，tidb的查询效率明显快于mysql。
-
TEM 易用性
最直接的好处就是简化了安装部署流程，以往手动安装往往需要数个小时，通过TEM能很快安装部署完成，且简化了动态扩容的操作，对于后期出现瓶颈进行扩容，也提供了很方便的操作指引，大大降低了安装运维的专业性门槛，节省了公司投入时间成本。
TEM自带的运维管理功能，如监控、告警、巡检等功能，也提升了日常运维的效率，方便监控和排查数据库异常。可惜目前社区版没有自带TEM，暂时只有企业版/敏捷版才有，没法自己单独使用。
三、平凯数据库敏捷模式优势 & 体验总结
- 所在行业哪些场景会建议用敏捷模式
主要是一些小规模的项目，不需要用到高可用多节点数据库的场景下，更适合用敏捷模式。
- 敏捷模式整体体验总结
- 敏捷模式的部署维护简单，针对小型项目使用更加方便快捷
- 存储空间占用对比mysql有优势，更节省空间
- 方便扩展，对应成长性项目，更易于后续扩展成分布式多节点的数据库服务
- 纯单机场景下，对比社区版本的单机部署的性能有提升，但对比mysql如批量写入等还是有所不足，通过交流得知敏捷版这方面还在持续优化，期待正式版的性能效果
- 一些查询如聚合类、二次查询的速度对比mysql存在优势