Shopee的数据库选型之路

Shopee 于 2015 年底上线，是东南亚地区领先的电子商务平台，覆盖东南亚和台湾等多个市场，在深圳和新加坡分别设有研发中心。

本文系 Shopee 的分布式数据库选型思路漫谈。因为是“漫谈”，可能不成体系，但会着重介绍一些经验以及踩过的坑，提供给大家参考。

1Shopee 的数据库使用情况

Shopee 在用哪些数据库?

先说一下当前 Shopee 线上在用的几种数据库：

• 在 Shopee，我们只有两种关系数据库：MySQL 和 TiDB。目前大部分业务数据运行在 MySQL 上，TiDB 集群的比重过去一年来快速增长中。

• Redis 在 Shopee 各个产品线使用广泛。从 DBA 的角度看，Redis 是关系数据库的一种重要补充。

• 内部也在使用诸如 HBase 和 Pika 等多种 NoSQL 数据库，使用范围多限于特定业务和团队。不在本次讨论范围内。

数据库选型策略

过去的一年里，我们明显感觉到数据库选型在 DBA 日常工作中的占比越来越重了。随着业务快速成长，DBA 每周需要创建的新数据库较之一两年前可能增加了十倍不止。我们每年都会统计几次线上逻辑数据库个数。上图展示了过去几年间这个数字的增长趋势（纵轴表示逻辑数据库个数，我们把具体数字隐去了）。

历史数据显示，逻辑数据库个数每年都有三到五倍的增长，过去的 2019 年增长倍数甚至更高。每个新数据库上线前，DBA 和开发团队都需要做一些评估以快速决定物理设计和逻辑设计。经验表明，一旦在设计阶段做出了不当决定，后期需要付出较多时间和人力成本来补救。因此，我们需要制定一些简洁高效的数据库选型策略，确保我们大多数时候都能做出正确选择。

我们的数据库选型策略可以概括为三点：

• 默认使用 MySQL。

• 积极尝试 TiDB。

• 在必要的时候引入 Redis 用于消解部分关系数据库高并发读写流量。

在使用 MySQL 的过程中我们发现，当单数据库体量达到 TB 级别，开发和运维的复杂度会被指数级推高。DBA 日常工作会把消除 TB 级 MySQL 数据库实例排在高优先级。

“积极尝试 TiDB”不是一句空话。2018 年初开始，我们把 TiDB 引入了到 Shopee。过去两年间 TiDB 在 Shopee 从无到有，集群节点数和数据体积已经达到了可观的规模。对于一些经过了验证的业务场景，DBA 会积极推动业务团队采用 TiDB，让开发团队有机会获得第一手经验；目前，内部多数业务开发团队都在线上实际使用过一次或者多次 TiDB。

关于借助 Redis 消解关系数据库高并发读写流量，后面会展开讲一下我们的做法。

分布式数据库选型参考指标

在制定了数据库选型策略之后，我们在选型中还有几个常用的参考指标：

• 1TB： 对于一个新数据库，我们会问：在未来一年到一年半时间里，数据库的体积会不会涨到 1TB？如果开发团队很确信新数据库一定会膨胀到 TB 级别，应该立即考虑 MySQL 分库分表方案或 TiDB 方案。

• 1000 万行或 10GB： 单一 MySQL 表的记录条数不要超过 1000 万行，或单表磁盘空间占用不要超过 10GB。我们发现，超过这个阈值后，数据库性能和可维护性上往往也容易出问题（部分 SQL 难以优化，不易做表结构调整等）。如果确信单表体积会超越该上限，则应考虑 MySQL 分表方案；也可以采用 TiDB，TiDB 可实现水平弹性扩展，多数场景下可免去分表的烦恼。

• 每秒 1000 次写入： 单个 MySQL 节点上的写入速率不要超过每秒 1000 次。大家可能觉得这个值太低了；许多开发同学也常举例反驳说，线上 MySQL 每秒写入几千几万次的实际案例比比皆是。我们为什么把指标定得如此之低呢？首先，上线前做估算往往有较大不确定性，正常状况下每秒写入 1000 次，大促等特殊场景下可能会陡然飙升到每秒 10000 次，作为设计指标保守一点比较安全。其次，我们允许开发团队在数据库中使用 Text 等大字段类型，当单行记录长度增大到一定程度后主库写入和从库复制性能都可能明显劣化，这种状况下对单节点