Marico's space

先说几句

这是一个系列，记录的是正在进行的工作的阶段性成果，不是已经完结的故事。不是什么学术论文，就是实实在在的工程经验总结，过程中踩过的坑、积累的心得，我都写下来。

为什么项目还没结束就急着写？因为细节容易消散——那些技术决策、那些中间观察、当时做决定的上下文，都会随时间模糊。趁还在做就写下来，也是我保存这些上下文的方式。这些上下文很重要，提醒我过去每个决策——不管是我的还是别人的——在当时都是有原因的。

还有一点：这个优化工作没有耽误产品开发。一切都是在开发新功能、修 bug 的同时进行的—— roadmap 从没为此停过。

关于保密：我不提客户的名字，避免任何可能被竞争对手利用的个人数据或细节。出于同样原因，我不用真名指代任何人，同事只以职位称呼。虽然不点名，但我要提前感谢与我并肩作战的伙伴们。数据是四舍五入的近似值——重点是数量级和背后的逻辑，不是精确数字。

还有贯穿整个系列的基调：在这个规模下，优化更像马拉松而不是百米冲刺——是的，这可能是被用烂的比喻，但在这里确实贴切：稳定节奏比冲刺更重要，一步一步小心前行才能到达终点。

我怎么走到这里的

我是软件工程师，职业生涯大部分时间都在做后端和数据库相关的工作。也当过技术团队的 Tech Lead，不过后来主动退回更靠近一线的技术岗位，因为那才是我最有效率、最自在的状态。我不是科班 DBA，但数据库一直是让我感兴趣的方向。即使通过 ORM（比如 .NET 里的 Entity Framework）来操作，仍然需要理解底层发生了什么：读执行计划、权衡取舍、什么时候方便的选择并不是正确的选择。整个系列里会有具体的例子。

在团队里大家会自然形成分工，数据库是我比较擅长的领域，所以在这个项目——跟之前的项目一样——我成了最接近数据层的那个人。慢慢地，这个数据库成了我最关注的——这是份我欣然接受、在团队信任下逐步适应的职责，也是我把它当作自己的数据库来对待的：它的性能、成本、长期健康。

我的协作方式

这些工作不是一个人能完成的。我主要负责找出并定位数据库层面的问题，往往也自己动手修复，一路积累了大量项目的技术细节和业务逻辑。但没有人能掌握全貌，我需要依赖比我更了解各个部分的同事。我们团队熟悉应用本身、相关的系统还有业务逻辑，经常能把原始的数据库观察转化为正确的技术决策，特别是我们 Team Leader 一直信任我、给我空间去研究和行动。数据分析团队了解数据的实际使用方式和业务含义，我依赖他们所有人。

我的工作方式

有几个原则贯穿我的一切工作：

• 稳定性优先。 业务和应用的连续性永远优先于优化。优化是改进系统的手段，绝不是冒险的理由。

• 先解决低垂的果实。 在做任何其他事情之前，先追查低垂的果实——最小投入最大回报的那种。没有道理放着每月能节省一百万 CPU 秒的改动不做，去折腾一个只能省一千秒的。

• 经济效率。 优化必须经济上说得通。花一百个小时节省一百块没有任何意义。每个改动都需要有清晰的技术和财务依据。

还有一件事——与其说是技巧，不如说是心态。当我遇到过去的技术决策、今天的我可能会做不同选择时，我几乎从不把它当作别人的错误。每个决策都有它自己的上下文、约束和权衡——技术的、业务的、有时候是组织层面的——这些我通常无法完全看清。在大多数情况下，它就是当时能做出的最优选择。重构不是修补别人的失误，而是任何长期系统正常生命周期的一部分。所以在整个系列中，无论我描述什么改动，请理解为演进，而不是批评。

最后还有一个原则——与其说是方法论，不如说是在说为什么这一切重要。这项工作不只是为了眼下削减账单。客户的业务正在快速增长，数据库的负载也在随之增加。现在优化规模和计算，既是为了应对这种增长，也是为了省钱——这样才能避免以后遇到瓶颈时同样的问题会更加昂贵和更具破坏性。成本是看得见的收益，为未来预留空间才是真正的收获。

系统概览

这项工作是为我们重要的客户做的——一家运营大型物联网（IoT）平台的公司，由多个互联系统组成，承受着巨大的负载，数据主要以时间序列为主。这是一个责任重大、风险高的项目，也是我真心喜欢参与的项目。我负责其中一个关键组件——平台中非常重要、高度负责的部分，虽然远不是唯一的一部分。整个系统由许多协同工作的组件构成，这个只是更大整体中的一个重要部分。其核心是一个已经增长到约 18 TB 的数据库。（为什么用关系型数据库处理时间序列数据是个合理的问题，但不在这里讨论范围——客户端和后端优化也是如此，除非数据库调查牵出了这些。）

旅程的起点

我加入时，这个组件运行在 Azure SQL 托管实例（Managed Instance）上。当时数据库还比较小——只有几 TB——规模还不是问题。但它一直在增长，我们知道随着业务扩展，增长会加速。问题在于结构层面：在这个模式下，存储上限与计算层和 vCore 数量绑定，所以更多数据最终意味着为了空间而购买我们不需要的 vCore。我们决定在这个依赖开始增加成本之前打破它，迁移到 Azure SQL Database Hyperscale 来解耦存储增长与计算。这次迁移本身并非完全小事——这样的迁移有其自身的技术挑战——但它确实达到了我们的目的。这次迁移才是优化之旅真正的起点。

下一部分：平滑 CPU 峰值，以及我们如何将这个数据库从 32 vCore 降低到 16——小心翼翼，分几步走，还有更多工作要做。