第3章选型评估框架

3、选型评估框架：业务需求分析、性能指标与成本模型

说实话，数据库选型这件事，我见过太多团队踩坑了。

有的上来就追新，选了个时髦的分布式数据库，结果业务量连单机MySQL都喂不饱。有的死守老一套，业务都冲到百万QPS了，还在用单库硬扛。说白了，选型不是技术竞赛，是匹配游戏。

我个人习惯，先搭一个评估框架。把业务需求、性能指标、成本模型这三块掰开揉碎了分析，再做决定。今天我就把这个框架拆给你看。

我见过最离谱的选型，是技术团队拍脑袋说「我们要上NewSQL」，结果一问业务场景，就是个简单的CRUD后台。嗯，这里要注意：业务需求是选型的起点，也是终点。

我一般会从四个维度去梳理业务需求：

数据模型：是结构化、半结构化，还是非结构化？关系型、文档型、图模型，各有各的擅长领域。我在项目中遇到过，一个社交关系业务硬要用MySQL存图数据，结果JOIN了八层表，查询慢到怀疑人生。
一致性要求：强一致性还是最终一致性？金融交易和用户发帖，要求完全不同。你想想看，银行转账少一分钱试试？但朋友圈点赞数延迟几秒，没人会投诉你。
读写比例：读多写少，还是写多读少？这直接影响存储引擎和缓存策略的选择。我曾经帮一个电商团队做选型，他们80%是读请求，结果选了写优化的LSM-Tree引擎，白白浪费了性能。
数据生命周期：数据需要保留多久？有没有冷热分层？很多团队忽略这一点，结果存储成本爆炸。

核心原则：业务需求决定技术选型，而不是反过来。别为了用某个数据库，去强行改造业务逻辑。

性能指标是选型的硬通货。但很多人只看QPS，忽略了其他维度。我习惯用「三驾马车」来评估：

指标	定义	我的经验值
QPS	每秒查询数，衡量读能力	单机MySQL轻松扛1-2万QPS，但到5万以上就要考虑分片或上缓存了
TPS	每秒事务数，衡量写能力	TPS比QPS更难优化。我见过一个系统，QPS能到10万，TPS只有2000，因为写冲突太严重
延迟	请求响应时间，P99/P999是关键	平均延迟是骗人的。P99延迟超过100ms，用户就能感知到卡顿

为什么会这样？因为很多数据库在低并发下表现完美，一上压力就原形毕露。我记得有一次做压测，某个号称「高性能」的数据库，在100并发时延迟只有5ms，但到1000并发时P99直接飙到500ms。这种坑，不压测根本发现不了。

避坑指南：我曾经只看了厂商提供的TPC-C跑分就做了选型，结果上线后业务场景和测试场景完全不同，性能直接腰斩。后来我学乖了：用自己的业务数据、自己的查询模式，做真实的压测。厂商的跑分，看看就好。

选型时最容易忽略的就是成本。我见过太多团队，选型时只看性能，上线后才发现成本根本扛不住。成本模型要算三笔账：

说白了就是CPU和内存的钱。云原生环境下，计算资源通常是按需付费的。但要注意：

存储成本往往被低估。我习惯用「每GB每月多少钱」来算：

云原生环境下，网络成本是个隐形杀手。我踩过这个坑：

跨AZ流量：同一个Region内，跨可用区传输数据是要收费的。如果你的应用和数据库不在同一个AZ，每笔查询都要付网络费。
跨Region流量：这个更贵。我建议，能不跨Region就不跨。如果非要跨，考虑用CDC（Change Data Capture）做异步同步，别让业务查询走跨Region链路。
API调用次数：有些云数据库按API调用次数收费。你以为自己在用免费套餐，结果一个月下来API调用费比计算费还高。

注意：我曾经帮一个客户做成本审计，发现他们30%的数据库成本花在了跨AZ的网络流量上。解决方案很简单：把应用和数据库部署到同一个AZ，网络成本直接降为零。有时候，架构上的小调整，能省下大笔钱。

我习惯用加权评分法做最终决策。举个例子：

你看，数据库A虽然性能不是最强，但综合得分最高。这就是评估框架的价值——帮你做理性的决策，而不是凭感觉。

我的建议：选型不是一锤子买卖。我习惯先做POC（概念验证），用真实业务跑一周，看性能、看成本、看运维体验。POC期间暴露的问题，比任何文档都更有说服力。

好了，选型评估框架就聊到这里。下一章，我会讲具体的迁移策略——怎么把数据从老库搬到新库，不停机、不丢数据。到时候见。