👆 立即咨询 TiDB 企业版 👆
本篇合集将深入探讨 TiDB 如何在趣丸科技的社交娱乐、竞技世界的网络游戏以及新东方的教育服务中实现数据库架构的革新，优化业务流程，提升用户体验，并助力企业在激烈的市场竞争中稳健前行。
趣丸科技（TT 语音）x TiDB
数据库的“自动档”：
NewSQL 分布式数据库选型思考
业务痛点与难点
海量数据存储：需要存储的数据量巨大，传统的关系型数据库在扩展性上存在局限。
高并发：业务特性导致系统需要处理大量的并发请求。
HTAP：需要同时支持事务处理和复杂查询，对数据库的性能提出了更高要求。
弹性灵活的扩缩容：业务的快速变化要求数据库能够灵活地进行扩缩容操作。
多 AZ 部署：为了提高业务的可用性和容灾能力，需要在多个可用区（AZ）中部署数据库。
分布式数据库选型
在选型过程中，我们主要考虑了以下几个关键因素：
TiDB 就像一个开着“自动档”数据库，它通过自动化的分片和负载均衡，让团队无需关注复杂的数据库分表问题，从而更专注于业务逻辑和创新。
为什么选择 TiDB
海量数据存储能力：TiDB 分布式架构有效应对业务增长带来的数据膨胀，解决传统数据库扩展瓶颈。
高并发处理：通过水平扩展提升并发处理能力，确保高负载下的稳定性和响应速度。
HTAP 支持：支持事务和分析混合负载，减少数据迁移，降低延迟，提升效率。
弹性灵活的扩缩容：TiDB 在线弹性扩缩容能力允许根据业务需求快速调整资源，不影响服务。
多 AZ 部署：支持多 AZ 部署，增强业务可用性和系统的容灾能力。
兼容 MySQL 协议/语法：TiDB 兼容 MySQL 协议和语法，实现现有业务无缝迁移至 TiDB。
开源产品与活跃社区：TiDB 开源，拥有活跃社区，便于问题解决和产品定制开发。
周边生态与迁移/改造成本：TiDB 周边生态成熟，迁移改造成本低，提供丰富的工具和集成选项。
TiDB 当前规模与收益
未来展望
TiKV 支持 S3 存储（Serverless）：期望 TiDB 能够支持 S3 接口的存储，进一步降低存储成本并提高数据管理的灵活性。
多租户资源隔离：希望 TiDB 能够提供更好的多租户资源隔离功能，使得更多的小型业务能够高效地共享数据库资源，同时保证各业务间的数据隔离和安全性。
可视化管理平台：期望 TiDB 能够提供更为成熟和易用的可视化管理平台，以简化数据库的运维管理工作，提高运维效率。
点击此处丨阅读原文
竞技世界x TiDB
注册用户超 5 亿，大规模数据及
高并发场景下分布式数据库从 1 到 N 的演进
为什么选择 TiDB
在采用 TiDB 前，竞技世界面临 MySQL 和 MyCAT 架构的存储和性能瓶颈、高可用性问题以及扩缩容挑战。为应对这些问题，我们尝试了集群拆分和分库分表，并将分析型数据迁移至 ClickHouse 和 Doris，但这导致了数据孤岛和运维复杂性。
2021 年初，基于业务需求、架构演进、技术生态和多元化选择，竞技世界选择了 TiDB，它以稳定性、扩展性、业务需求满足、运维管理和成熟度脱颖而出，提供一致性、高可用性、弹性扩缩容和实时 HTAP 能力，且具有活跃的开源社区支持。
如何从 0 到 1 应用 TiDB
在选型阶段，我们完成了功能、性能等验证测试，确保 MySQL 到 TiDB 的迁移满足 SQL 兼容、可回退和性能不降的要求，并制定了针对 MySQL 和 MyCAT 的迁移策略。
对于 MySQL：采用集群拆分策略，通过业务维度拆分实例，并利用 DM 合并到 TiDB 集群。为满足可回退要求，我们通过 DM 同步数据至 TiDB 后，再通过 TiCDC 回写至 MySQL，确保随时可回退至原环境。数据一致性校验则通过 sync-diff-inspector 工具完成。
对于 MyCat 集群：从数据节点通过 DM 实时同步至 TiDB，再反向写入并通过 sync-diff-inspector 校验数据完整性。迁移后，TiDB 通过 CDC 接入 Canal 协议，无缝对接 Kafka，满足下游消费需求。
使用 TiDB 的收益
从研发侧角度来说：接入成本变得非常便捷，数据存储容量增加，聚合查询速率加快，数据统计分析更加实时，使业务团队能够更专注于业务创新。
从运维侧角度来看：TiDB 的引入降低了运维成本，提高了集群的稳定性和数据一致性，同时通过弹性扩缩容和主机迁移，运维效率提升了 10 倍以上。
遇到的一些问题
在使用 TiDB 过程中，我们遇到了热点问题、GC 失效、Write Stalls 和数据类型转换问题，并采取了相应措施：
热点问题：通过替换自增主键为随机主键、业务端生成 UUID、利用 Follower Reads 和 Stereo RAID 均衡负载，以及 TiDB 7.1 版本的负载自适应副本读功能，有效分散写入热点。
GC 不工作：解决了 GC 机制失效导致的空间未回收问题，通过重建 Region 和重启 TiKV 节点恢复 GC 功能。
Write Stalls：针对 RocksDB 流控机制引起的写入降速问题，调整 TiKV 参数或业务限流、集群扩容来解决。
隐式数据类型转换：确保数据类型一致性，优化 SQL 语句，显著提升了执行效率。
这些解决方案提升了我们对 TiDB 的理解和运维能力。
点击此处丨阅读原文
新东方x TiDB
从 v1.0 到最新版，
选择和升级 TiDB 的全面考量
新东方选择 TiDB 的背景和原因
探索与尝试：2017 年，为提升大表查询性能，我们探索分布式数据库解决方案。面对 OA 工作流和业务归档数据的需求，我们测试了 Postgres-XC/XL 和 MySQL NDB，但未达预期。随后，我们尝试了国产 TiDB，并与 CockroachDB 等国际数据库对比，最终选择 TiDB 作为数据基础架构，积累了宝贵的分布式数据库经验。
挑战与迭代：2018 年，面对业务增长和高并发挑战，我们重构了 ERP 报名系统，从分校独立部署的 SQL Server 架构转变为集中数据管理的分布式架构，提升了系统性能至每分钟 500 万请求量。我们选择了 TiDB 而非传统的分库分表方案，以降低开发和维护成本。在重构过程中，我们基于 TiDB v2.0 开发，解决了分布式事务的挑战，最终不再需要自研分布式事务架构。
新东方 TiDB 应用场景及版本分布
TiDB升级策略和相关考虑分享
精选稳定的版本：建议使用 TiDB 的 V6.5 LTS 版本，因其稳定性和社区支持，适合项目适配，后续版本如 V7.5 和 V8 LTS 也提供长期维护。
非核心业务先行：升级前在测试和灰度环境验证，确保 SQL 兼容性和性能，避免升级隐患。
升级方式的选择：迁移升级虽复杂但风险可控，滚动升级简单但需业务支持重试，TiProxy 可助平滑升级。
准备好回退方案：无论升级结果如何，周密的回退方案能迅速恢复业务，保证连续性，减少影响。
TiDB 后续升级计划
TiDB 新版本新特性分享
TiDB v6.5：TiDB v6 版本提升了与 MySQL 的兼容性，特别是自增 ID 现在能保证单调递增，满足依赖 ID 排序的业务需求。v6.5 版本支持类型转换，如 VARCHAR 到 BIGINT，简化表结构修改。V2 优化器在 v6.5 中引入，性能显著提升，尤其在 INDEX MERGE 方面，现在支持 AND 条件，优化了查询性能。
TiDB v7.5：我们正在将商机系统数据同步至 TiDB V7.5 版本集群，关注性能和兼容性。测试显示，V7.5 版本处理复杂 SQL 查询性能显著提升，比 V5.0 版本快约 15 倍。我们计划利用 V7.5 的租户隔离功能，将 TP 和 AP 请求分离，以实现查询的租户级别隔离，并减少非核心业务查询对主库的影响。对于核心业务，建议独立部署以确保稳定性，非关键业务可考虑多租户部署以提高效率。
TiDB v8.x：TiDB 的 V8.5 版本预计将引入多模态功能，支持 Vector store、Document store 和 Graph store，减少对多种数据库的需求。这将降低运维成本并简化数据库设计，同时 TiDB 的 CDC 能力增强，支持 Debezium 和 Canal 格式，有利于实时数据处理和开源生态的扩展。我们期待这些新特性以满足 AI 和推荐系统中多样化的数据需求。
点击此处丨阅读原文
👇 立即咨询 TiDB 企业版 👇
