---
title: 'TiDB x 东吴证券 | TiDB 在东吴证券秀财 APP 的应用'
date: '2024-05-06T17:33:50+08:00'
status: publish
permalink: /case/user-case-soochow-securities
author: '周, 盛虎'
excerpt: '东吴证券选择 TiDB 分布式数据库作为其秀财 APP 底层的数据库产品，一举替换了 MySQL、MongoDB、MyCat 等多个数据技术栈，解决了日常业务中的各种需求和痛点。'
type: case
id: 6618
thumbnail: https://img1.pingcap.com/files/2024/05/20240717084756100.png
industry:
    - 金融
scene:
    - '实时 HTAP'
banner_image:
    - ''
company_desc:
    - '东吴证券股份有限公司（以下简称“东吴证券”）成立于 1993 年，是拥有全部证券类业务牌照的综合券商。2011 年 12 月 12 日，东吴证券作为全国第 18 家上市券商、首家地级市上市券商在上海证券交易所挂牌上市。目前，东吴证券在全国设有 22 家分公司和 132 家营业网点。'
white_paper_link:
    - ''
---
业务挑战
----

长期以来，金融行业主要依赖国外厂商提供的基础软件产品，尤其是在关键的核心数据库领域，使用由 Oracle 等国外科技公司的产品。然而，国外数据库产品存在技术壁垒，其核心技术封闭且不可控，版权费用高昂，存在着潜在的风险。在自主创新的环境下，选择国产数据库替代主流的国外商业和开源数据库，已成为当前的主要趋势之一。

东吴秀财 APP 是东吴证券倾力打造的新一代移动端财富管理平台，是一个具有强烈互联网属性的产品。其原有架构主要基于 MySQL ，并在部分场景结合使用 NoSQL 数据库，如 MongoDB 提供服务。部分 MySQL 实例基于模块和项目组独立搭建和维护，采用了基于MyCat + 分库分表架构的逻辑集群。该架构存在以下问题：

- **架构复杂**：使用多款数据库产品，一个模块的应用使用一个独立的 MySQL，当业务量增长时，还需要采用基于 MyCat 的分库分表数据库，对于一些文档类的场景，还需要单独使用 MongoDB。多个数据库产品的堆积导致了烟囱式的发展，使得数据架构变得复杂，且无法有效解决业务问题。
- **业务扩展性不足**：用户行为、运营、消息等业务都呈现出明显的互联网特征，数据需要根据业务的需要实现灵活的扩展。然而，无论是单机 MySQL，还是基于 MyCat 的分库分表数据库，都未能满足这种灵活扩展的需求。
- **性能不能满足要求**：业务对数据插入和查询的效率要求相当高，尤其是在业务高峰期，性能要求更为严格。在一些复杂场景下，查询响应时间甚至超过了 10 秒，这对于 C 端应用来说是无法接受的。
- **开发心智负担重**：对于分库分表的集群，研发层面需要提前设计好分库分表的逻辑，原本由数据库处理的工作需要应用程序来实现，这给研发人员带来了相当大的心智负担。
- **运维复杂**：在监控和运维方面需要投入大量精力，许多独立的 MySQL 实例只是最基本的读写分离或者主备架构，无法做到故障情况下的自动恢复。

使用一个 TiDB 替换多个数据技术栈
-------------------

在经过对多款产品进行严格测试验证并综合考虑研发、运维等方面的因素后，东吴证券最终选择了 TiDB 分布式数据库作为东吴秀财 APP 底层的数据库产品，一举替换了 MySQL、MongoDB、MyCat 等多个数据技术栈，解决了日常业务中的各种需求和痛点。经过三年时间的实践探索，TiDB 在 MySQL 兼容性、功能、性能、运维层面的表现达到了业务预期，主要情况如下：

![东吴证券秀财 APP 数据架构示意图](https://img1.pingcap.com/files/2024/03/20240314111010714.png)<center>东吴证券秀财 APP 数据架构示意图</center>
### 兼容 MySQL 生态，应用平滑过渡

在研发层面，无需修改代码即可实现从 MySQL 平滑迁移至 TiDB。对于涉及大事务或特定函数的场景，可能需要考虑一些优化和调整，但改造成本相对较小。此外，无需引入额外的数据库驱动，对于使用标准框架进行开发的项目组来说，几乎没有额外的学习成本。对于遗留项目的迁移，TiDB 提供了一系列与 MySQL 生态兼容的工具，支持多种迁移和并轨的运行模式，可以实现应用的平滑过渡。总体上做到了对应用研发人员的透明无感知。

### 性能实现质的飞跃

得益于 TiDB 原生分布式架构设计，可按需对计算和存储节点分别进行在线扩容或者缩容，而这个过程对应用运维人员是透明的。在单机数据库无法应对因数据爆炸性增长的场景下，TiDB 成为一种性价比高的解决方案，其规模可以线性扩展，集群容量已经支持到 PB 级别。在迁移到 TiDB 后，在结构和查询语句设计合理的前提下，各个项目组基本上都反馈性能得到了大幅提升，从原来的 10+ 秒提升到 100+ 毫秒级别，实现了质的飞跃。

### 满足金融数据强一致性的 HTAP

以运营和用户行为数据为例，传统的数据处理流程需要经过线上库、数据仓库、数据集市等一系列采集、处理、聚合的流程。不仅耗时，还涉及到与数据组的对接和合作，整体上线和升级流程显得比较缓慢。使用 TiDB 的 HTAP 特性后，相关业务的交付效率大幅提升，整个处理流程都在 TiDB 和单一应用内完成，数据链路短，排障难度也大幅降低，极大地节省了人力和时间成本。TiFlash 提供了强一致性的数据保证，确保数据分析结果与业务数据完全一致，避免了数据延迟和不一致的问题。在金融行业中，这一特性显得尤为重要。

### 运维便捷

对于运维人员来说，TiDB 提供直观的监控 Dashboard、管理控制台，集群本身的扩容能力也使得日常的运维监控、服务器上下线、配置升级等操作更加容易。此外，统一对一个 TiDB 数据库集群进行监控维护的成本也会比维护多个零散的 MySQL 实例更为简洁。使用 TiDB 集群不仅提高了服务器的资源利用率，也大幅度减少了运维人员时间成本的碎片化，极大地提升了工作效率。

未来展望
----

当前，很多证券企业遇到了存量 MySQL 实例的标准化和管理成本问题。这些 MySQL 实例部署和使用的周期不同，在版本、配置和工具的使用方面都大相径庭，导致在升级、维护和管理上需要投入大量成本。后续，东吴证券计划引入 TiDB 新版本的资源管控功能，结合 TiDB 的可伸缩特性，通过构建 TiDB 统一集群的方式对通用服务资源进行分配和隔离，实现对存量 MySQL 实例的归集和统一管理，提升资源利用率，降低运维投入，同时解决不同业务之间的资源争抢问题。