⬆️PingCAP DevCon 视频回放及演讲资料已上线
TiDB Cloud 广泛应用出海领域，支持全球多云部署，致力于为出海企业提供安全合规、稳定可靠的数据库服务，成为企业开展全球化业务的重要基础设施和数据底座。
本文分享了 TiDB Cloud 在 vivo、NFTScan、携程等出海企业的应用实践。
vivo x TiDB丨解决云服务海量数据挑战
本文介绍了 vivo 的数据库和存储系统，以及如何使用分布式数据库 TiDB 解决海量数据挑战，包括海量数据实时 OLAP 方案、云服务业务中的元数据管理方案，和基于自研的 NoSQL 数据库 TiKV 的实践。分享了如何解决海量数据存储和管理的问题，以及提高业务效率和用户体验的实践经验。
vivo 数据库与存储体系
在整个 vivo 云服务体系中，数据库与存储处于核心位置，从体系上可以分为两层，最上面一层是工具产品层，下面一层是数据库产品层。
vivo 数据库与存储运营管理
为了管理这些众多的数据库与存储产品，vivo 打造了一个数据库与存储运营管理平台，主要分为三层架构。
TiDB 在 vivo 的落地实践
引入 TiDB 帮助 vivo 解决了一些在 MySQL 生态中无法解决的问题：
TiDB 可以解决数据量过大、流量过大的问题，以及海量数据分析的场景；
TiDB 兼容 MySQL 语法，业务迁移比较平滑；
TiDB 支持水平扩展，相比传统的 MySQL 复杂的分库分表方式，TiDB 的扩展能力大大降低了运维压力；
TiDB 具备数据强一致性、高可用性，可以提供金融级数据安全性。
在应用 TiDB 后，vivo 研发团队同样也将 TiDB 集成到该平台中，实现诸如 TiDB 的自动化部署、服务维护、数据变更、数据恢复，包括一些还在持续建设中的能力，如服务优化、服务变更。
应用场景
推送业务基于 TiDB 的海量数据实时 OLAP 方案
vivo 的推送业务基于 TiDB 实现了一套实时 OLAP 方案。该场景中具有千亿级别的数据指标，vivo 希望数据在数据指标写入时可以实现秒级入库。同时，该场景还要求以月度为范围秒级出报表。
CDC 模块的形态
vivo 云服务是 vivo 为用户提供的在手机上进行数据备份、数据恢复同步的一款服务。vivo 基于 TiDB 实现了一套海量元数据管理方案，支撑了 vivo 百亿级别的元数据表和日志数据表存储，核心业务时延小于 50ms。
点击此处丨查看原文
NFTScan x TiDB丨一栈式 HTAP 数据库
本文介绍了 NFTScan 数据架构面临的挑战、选型的思考、迁移至 TiDB 的过程以及迁移后获得的收益。一体化的 HTAP 架构能够替代 MySQL + Elasticsearch 的能力，成为支撑在线数据服务的最佳选择。
以前的 MySQL 解决方案的挑战
可扩展性差，存储和维护成本高。每天新的区块链数据量急剧增加，但 MySQL 无法自动横向扩展以应对不断增加的工作负载。NFTScan不得不手动对表进行分片并新增 MySQL 的主备集群，来分摊和均衡 CPU 和内存资源的使用，这大大增加了存储和维护成本。
随着成本的增加，使用率下降。Elasticsearch 部署在 AWS 上，由于 AWS 原生集群配置的限制，NFTScan不得不增加更多的 Elasticsearch 高配置数据节点来提供在线查询服务，这导致成本上升和使用率降低。
反复出现的精度错误。Elasticsearch 数据库更多的是为搜索而设计的，而不是为计算设计，所以在聚合计算中存在精度误差。
为什么选择 TiDB
经过近一个月的调研和测试，NFTScan 最终选择了 TiDB 来作为核心数据架构，替代原有数据库系统。NFTScan 研发团队在调研中选择 TiDB 主要有以下几点考量因素：
高度兼容 MySQL ；
弹性伸缩；
一体化 HTAP 架构；
高可用性。
迁移方案
经过两个月的时间，NFTScan 完成了将底层数据库系统全部切换到 TiDB 的工作，通过部署 2 台 TiDB 服务器、9 台 TiKV 服务器和 2 台 TiFlash 服务器，并在同一 region 下，跨三个可用区（AZ) 进行部署，保证了整体架构的高可用性。
截至 2022 年 11 月，NFTScan 的 TiDB 数据库存储了大约 6TB 的业务数据，QPS 达到 5000，平均查询时长 40ms，各种应用在 TiDB 上运行稳定。
使用收益
TiDB 支持多维实时查询，查询时间短。TiDB 完美地满足了 NFTScan 高吞吐量和低延迟的核心要求。以业务端的 API 服务为例，平均查询时间从 10-100 毫秒下降到 10 毫秒或更少。即使处理 1,000 QPS，这样的查询速度也能保持稳定。
TiDB 的列式存储引擎 TiFlash ，可以高效地处理分析工作负载。例如，在对某张具有数亿行的表执行复杂查询时，可以在几秒钟内获得结果。
TiDB 的智能 SQL 优化器可以根据数据的分布情况选择最具性价比的数据查询执行计划，让开发者可以灵活调整和优化 SQL 执行计划。
点击此处丨查看原文
携程 x TiDB丨一栈式 HTAP 实现架构革新
本文介绍了携程数据库架构从 SQL Server 到 MySQL 再到 TiDB 的革新历程，从痛点分析、选型思考到部署实践，全面介绍了 TiDB 如何支撑携程的酒店和度假结算场景、海量数据场景以及全球化业务，以一栈式 HTAP 支持携程全球业务海量数据增长。
原 MySQL 架构痛点与挑战
携程的应用部署在两个或多个 IDC 中，数据库也对等部署在每个 IDC 中。MySQL 部署方式采用 HA 节点，即主备节点，在同一机房部署，另一节点在不同 IDC 部署，这种方式保证了 HA 切换速度和数据的容灾。
分布式数据库选型
携程主要从以下几个维度考量分布式数据库：
性能：平衡性能和成本，选择通用机型，不使用高端存储或机器，并要求响应稳定；
运维与社区：学习成本适中，运维复杂度低，产品需开源且社区活跃；
成本：一方面，业务研发需要学习使用 SQL，特别是 MySQL 协议；另一方面，运维团队希望产品不要过于复杂，易于维护；
扩展性：分布式数据库需要具有快速的扩展能力，扩缩容对业务影响小。
TiDB 在海量数据场景中的应用
TiDB 的行列混存架构（ TiFlash 和 MPP 技术），使得携程部分查询性能有了 20 倍提升；在信息安全源数据标记数据时，单表数据也超过了 60 亿行，读写的响应时间都达到毫秒级，单天聚合查询秒级返回。
点击此处丨查看原文
为了更了解您的需求和喜好，给您提供更好、更便捷的服务
【TiDB Club】微信公众号粉丝调研活动上线，点击下图即可进入问卷页面
