我与 tidb 的十年，我的职业生涯中遇到的各式各样的数据库。

2024-08-09
北京
本文字数：3621 字
阅读完需：约 12 分钟

作者： tidb 狂热爱好者原文来源：https://tidb.net/blog/47ba7314

一、数据库发展的宏观脉络

从 20 世纪 90 年代至 21 世纪初，数据库行业相对稳定，以 Oracle、MySQL 等为代表的传统数据库占据主导地位。然而，随着时代的变迁和业务需求的不断增长，数据库技术在近年来发生了显著的变化。分布式数据库逐渐崭露头角，经历了从简单的分片方式到更加复杂和高效的架构演进。

二、第一代分布式数据库

十年前，我初入数据库领域，那时的我犹如一艘在知识海洋中刚刚起航的小船。在一次项目的困境中，我第一次听说了 TiDB。当时我们的公司业务不断扩张，传统的数据库在处理日益增长的数据量和高并发请求时显得力不从心。我们面临着数据存储瓶颈、查询速度缓慢等诸多问题，就像在迷雾中艰难前行的航船找不到方向。我当时在龙席电商。我们用 mysql 主从加上分片搭建了我们的电商平台。当时搞 ipad 秒杀。结果黑客来了拿走了奖品。公司不兑现承诺。黑客就不停的 cc 我们服务。分片的各种问题暴露出来。这个用户分片的数据库报警，mysql 奔溃。业务页面不可用。

这一时期的分布式数据库主要依靠中间件来实现水平分片。常见的方式包括业务层手动分库分表和通过中间件选定 sharing key 进行水平分表。手动分库分表虽然直观简单，但缺乏灵活性和可扩展性。而基于中间件的分表方式，尽管在一定程度上简化了分片操作，但仍存在诸多局限性。例如，需要对业务进行改造，且这种改造具有倾向性；在查询复杂维度数据时，往往只能通过广播的方式，导致带宽消耗和数据准确性问题；对于分布事务的支持较弱，伴随较大的性能损失；难以利用底层数据库的高级特性如 MVCC；水平扩展能力有限，数据分布容易失衡，扩容时涉及数据重分布，操作复杂且容易出现失误；在进行表结构变更操作时，容易出现错误，尤其是在大规模分片的情况下。

三、第二代分布式数据库（NoSQL）

在 2014 年 -2015。我加入了妙资当时我们用的是 codis. 也由 codis 结识了 tidb 的创始人。在这个节点。为了应对传统数据库的瓶颈。我们在前端加入了很多缓存。尽量保护脆弱易碎的 mysql。

我们的订单数据放弃了脆弱的 mysql。转向了了 mongodb。维护 mongodb 的酸痛。我和存焉，兴隆都非常清楚。又一次 mongodb 因为服务配置太低导致数据异常。mongodb 需要人工干预分片。配置服务器的大小。并不会因为业务的增加而自动运维数据库。该解决的 mongodb 一点也没解决。用他是非常痛苦的。

这期间 codis 也没解决我们 mysql 性能薄弱的问题。一旦遇到秒杀场景如果 redis 覆盖不住。引起业务雪崩。只需要一点 redis 的流量打到 mysql。就会引起 mysql 的当机。

为应对传统数据库在扩展性方面的瓶颈，NoSQL 应运而生。它摒弃了传统关系型数据库的复杂结构，采用了更为简单和灵活的数据模型，如文档型、键值对型等。MongoDB 作为典型的文档型 NoSQL 数据库，其优势在于表结构灵活，适应业务快速迭代，且内部存储结构简单。然而，它在分布式能力上仍依赖中间件的分片方式，存在诸如跨分片事务、聚合能力不足、数据重分布导致的带宽拥堵等问题。HBase 作为基于 HDFS 的分布式键值对数据库，具有强大的水平扩展能力和动态数据切分能力，但在事务支持和性能方面存在短板，多了一层 HDFS 的存储抽象导致性能损失较大，且在金融级场景中的跨行事务支持不足。Cassandra 作为另一类 NoSQL 数据库，在单个键值操作上提供了多种一致性模型，但仍然面临业务基于键值编写的复杂性、运维难度以及在国内流行度相对较低等问题。

四、第三代分布式数据库

这时，TiDB 如同黑暗中的一盏明灯出现在我的视野里。我怀着好奇与期待，开始了与它的初次相遇。安装和配置 TiDB 的过程并非一帆风顺，我遇到了一些小麻烦，比如在配置网络参数时，总是无法正确连接到各个节点。但通过查阅大量的文档和在论坛上向高手请教，我最终解决了这些问题。当我第一次成功运行一个简单的测试查询，看到那快速而准确的结果时，我心中涌起了一阵惊喜。TiDB 高效的数据存储和快速的响应能力让我看到了希望，仿佛在茫茫大海中找到了一片新的陆地。

随着时间的推移，我逐渐深入了解 TiDB。在第三年，我们有一个重要的企业级应用开发项目。这个项目需要处理大量的实时交易数据，对数据的一致性和并发处理能力要求极高。我们决定将 TiDB 应用到这个项目中。记得有一次，在促销活动期间，我们面临着瞬间的高并发数据写入请求。传统数据库可能会在这种情况下出现卡顿甚至崩溃，但 TiDB 的分布式架构发挥了巨大作用。它自动将数据均衡地分配到各个节点，并且通过其强大的分布式事务处理能力，确保了每一笔交易数据的准确和完整。看着系统在高负荷下依然稳定运行，那一刻，我真正体会到了 TiDB 的强大。

第三代分布式数据库以 Google 的 Spanner 和 PingCAP 的 TiDB 为代表，它们在吸取了前两代数据库的经验教训基础上，实现了扩展性与事务支持的平衡。这类数据库采用了类似于 Share Nothing 的架构，继承了 NoSQL 的弹性水平扩展能力，同时解决了中间件带来的业务侵入性问题，使业务可以像使用单机数据库一样操作，无需指定分片策略。系统具备强一致性和分布式事务支持，能够满足金融级场景的需求，并且具备跨数据中心的故障恢复能力。

然而，这类新型数据库也并非完美无缺。它们并非百分之百兼容传统数据库的语法，例如 TiDB 不支持存储过程等传统特性。此外，由于支持事务，在分布式环境下的网络通信会带来额外的延迟，导致在某些性能测试中，单机数据库可能在延迟方面表现更优，但在吞吐方面，分布式数据库具有优势。

五、云数据库

随着公有云的兴起。我的职业生涯又维护了很多 mysql 公有云数据库

他们贵。非常贵同样的价格是 ec2 的三倍，备份要钱，存储要钱，iops 也要钱。公司就像是杨白劳。时不时的会被地主敲诈勒索。一整套架构搭建下来。满脑子的贵三倍。

随着公有云的兴起，出现了如 Amazon 的 Aurora 等新型的云数据库架构。Aurora 号称是 Cloud Native，但其本质是将 MySQL 的计算程序无状态化，并将数据文件存储在云盘上，实现了存储计算分离。Aurora 的优点在于公有云提供的开箱即用的便利性和对 MySQL 的高度兼容性，能够在一定程度上实现数据量的扩展。然而，其缺点也十分明显：它仍然是单机数据库，需要进行分库分表来扩展读写能力，存在主副本同步的延迟问题，内存与存储的比例不匹配导致随机访问时可能出现大量缓存未命中和性能抖动，不推荐开启 binlog 复制，否则性能会下降。

六、HTAP（混合事务 / 分析处理）

在第八年，随着公司业务在全球范围内的拓展，数据量呈爆炸式增长。TiDB 的水平扩展能力再次成为我们的救星。我们只需要简单地增加新的节点，就能够轻松应对不断增长的数据量。而且，TiDB 的跨数据中心同步功能也让我们在全球不同地区的数据保持一致，为我们的全球业务提供了坚实的基础。我记得有一次，我们在美国和亚洲的两个数据中心之间进行数据同步测试，尽管网络延迟存在一定挑战，但 TiDB 依然能够准确地将数据同步到各个节点，确保了全球用户都能获得一致的服务体验。

在第九年，我开始深入挖掘 TiDB 的高级功能。其中，它的 tifalsh 功能让我印象深刻。我们有一个数据分析的需求，需要同时处理多个版本的数据，以进行趋势分析。TiDB 的 tifalsh 使得我们可以轻松地实现这一点，而不需要进行复杂的数据备份和恢复操作。我们能够在不影响线上业务的情况下，进行数据分析，为公司的决策提供了有力的支持。例如，通过对用户购买行为数据的多版本分析，我们发现了一些潜在的用户需求趋势，从而调整了产品策略，取得了显著的业务增长。

新一代数据库的发展方向是实现 HTAP，即在同一个数据库中同时高效处理事务和分析查询，且两者互不影响。一个真正的 HTAP 数据库应具备无限水平扩展、事务支持、故障自恢复能力、高性能分析能力以及在混合负载下的稳定性能等特性。TiDB 在这方面进行了积极的探索和创新，通过采用多副本列存、实时数据同步等技术，实现了事务处理和分析查询的高效融合。然而，目前业界能够达到这些严格要求的数据库系统还相对较少。