在百词斩的众多数据库中，学习记录的数据库是最为核心的业务数据库之一，也是百词斩数据量最大的一个数据库，它需要记录所有用户的全部学习过程。伴随着用户持续上线学习和新用户的不断增加，百词斩的数据库数据量和节点数的持续剧增。
“百词斩诞生在 2011 年，作为一个互联网 APP，我们选择的也都是当时主流的技术栈。MySQL 当时在互联网公司非常流行，所以学习记录系统的数据库选的也是 MySQL。”百词斩 CTO 敬宓表示。
敬宓是一位技术大咖，曾在百度、迅雷等多家公司从事软件开发和架构设计工作。2021 年进入百词斩，全面负责公司的技术工作，包括基础架构的搭建、云服务的改进和优化以及 AI、多基础设施等新技术的探索。
“因为数据量一直在增长，我们的数据库节点数一直在增加。前两年因为线上学习业务的兴起，百词斩学习记录等核心业务增长很快，每年需要新增 3-4 个节点。”敬宓说。
百词斩的系统部署在公有云上，数据库采用的也是云服务商的 MySQL RDS 服务，其最大数据存储量为 3TB 左右，当数据量增加到超过节点最大承载能力时就要扩容。对于新增用户，扩容比较容易，直接路由到新的节点就可以了。但对于老用户的数据，扩容相对就比较麻烦，此时需要对旧数据重新进行分片，过去完全靠 DBA 的经验人工来完成。随着业务的发展,到目前为止这个数据库的节点数已经扩展到 30 个。这个办法越来越难以继续了。
第一，要保证如此多的节点都正常运行、不宕机，非常不容易。尽管当今云服务商的基础设施已经非常好了，但仍然有可能因为软硬件等各方面的原因，让设备宕机，一旦一个节点宕机会直接影响业务的正常进行，这个系统的维护和容灾、备份都带来相当大的压力。
第二，人工拆库拆表需要付出很高的人力成本。比如，需要去监控哪些节点快要达到上限了，然后在快要达到上限之前赶紧把这个节点上的数据分开，运维成本很高。同时，开发成本也很高，因为开发人员需要知道到哪个节点去读取数据。
第三，从技术上的角度上来说，这种单纯靠手工做数据的分布式部署不是真正的分布式解决方案。
“因为通过人工去进行数据的分布经常会出现这样的问题：虽然拆分出来的节点满足了数据的分布式部署需求，但是各个节点它的冷热是不均匀的。比如，因新增节点上通常是新用户或者是最近很活跃的用户在使用，压力会很大，即使人为地做些优化，也不能做到动态的平衡，很容易会出现压力不均的情况，很难解决。”敬宓说。
另外，大量的独立 RDS 导致与大数据平台的数据进行同步时需要创建大量的 DTS 同步链路，同步链路的运维复杂度和成本随着 RDS 实例数的日渐增多变得居高不下。
