4、选型方法论：业务需求分析、读写比例评估、数据量预估、一致性要求、成本考量

好，咱们进入正题。选型这件事，说白了就是「匹配」。你手里有什么牌，业务要什么结果，中间怎么搭桥，这就是方法论。我见过太多团队，一上来就追热点，Redis 火就用 Redis，TiDB 新就上 TiDB，结果呢？业务跑起来各种别扭。嗯，咱们今天就把这五个维度掰开揉碎讲清楚。

4.1 业务需求分析：别急着看技术，先看业务

我个人习惯，拿到一个实时系统需求，第一件事不是翻文档，而是拉着产品经理聊半小时。问清楚三个问题：

• 数据从哪里来？ 是 IoT 传感器、用户点击流、还是金融交易？来源决定了写入模式。
• 数据到哪里去？ 是给大屏展示、给算法训练、还是给下游做实时风控？去向决定了查询模式。
• 延迟容忍度是多少？ 毫秒级？秒级？还是分钟级？这直接决定了能不能用批处理。

我在项目中遇到过一件事：有个团队要做实时推荐，选了 Apache Flink，结果发现业务场景其实是小时级更新，根本不需要流处理。最后换成了 Spark 批处理，成本降了 60%。你想想看，这就是典型的「杀鸡用牛刀」。

4.2 读写比例评估：读多写少还是写多读少？

这个比例，我建议你直接用生产环境的监控数据说话。别靠猜。我见过有人拍脑袋说「我们读写比 10:1」，结果一上 Prometheus 一看，实际是 1:10。尴尬不？

不同比例对应不同选型：

读写比例	典型场景	推荐方向
读远大于写（10:1 以上）	内容缓存、商品详情页	Redis、Memcached、CDN 配合
写远大于读（1:10 以上）	日志采集、IoT 数据上报	时序数据库（InfluxDB、TimescaleDB）、Kafka
读写均衡（1:1 ~ 3:1）	实时风控、在线交易	分布式数据库（TiDB、CockroachDB）

4.3 数据量预估：别只看当前，要看半年后

数据量预估，我一般按「日增数据量 × 保留周期 × 冗余系数」来算。举个例子：

日增数据：100 GB
保留周期：30 天
冗余系数：1.5（副本 + 索引）
总存储需求 = 100 GB × 30 × 1.5 = 4.5 TB

嗯，这里要注意：很多人只算原始数据，忘了索引和副本。我曾经有个项目，预估 2TB 就够了，结果索引占了 3 倍空间，最后不得不紧急扩容。你说冤不冤？

另外，数据量预估还要考虑峰值。比如双十一、618 这种大促，写入量可能是平时的 10 倍。如果选型时没考虑弹性扩展，到时候只能干瞪眼。

4.4 一致性要求：强一致还是最终一致？

这个问题，我建议你直接问业务方：「如果读到旧数据，会出事故吗？」

• 强一致性： 金融交易、库存扣减、订单状态。必须用支持分布式事务的数据库，比如 TiDB、MySQL + XA、或者 NewSQL。
• 最终一致性： 用户动态、评论数、点赞数。稍微延迟几秒，用户根本感觉不到。用 Cassandra、DynamoDB 这类 AP 系统就行。
• 因果一致性： 比如用户必须先发帖才能评论。这个可以用逻辑时钟或者版本向量来解决。

我个人习惯，能选最终一致就别选强一致。为什么？因为强一致带来的性能开销和复杂度，真的不是闹着玩的。你想想看，一个分布式系统要保证强一致，意味着每次写入都要做两阶段提交，延迟至少翻倍。

4.5 成本考量：不只是钱，还有运维成本

成本这东西，很多人只盯着「软件授权费」或者「云服务账单」。其实还有三块隐性成本：

1. 学习成本： 团队会不会用？要不要培训？我见过一个团队选了 CockroachDB，结果没人会调优，最后性能还不如 MySQL。
2. 运维成本： 扩缩容方不方便？备份恢复怎么做？有没有成熟的监控工具？
3. 迁移成本： 如果以后要换数据库，数据怎么迁？业务代码改多少？

举个例子：MongoDB 免费，但如果你要做强一致、跨机房部署，那运维复杂度直接拉满。而 TiDB 虽然要花钱，但它的自动扩缩容和在线 DDL，能省下大量 DBA 的人力成本。算总账，可能 TiDB 更划算。

4.6 综合决策矩阵：五个维度一起看

好了，五个维度都讲完了。怎么综合决策？我一般画一个矩阵：

维度	权重（1-5）	评分（1-5）	加权得分
业务需求匹配度	5	4	20
读写比例适配	4	5	20
数据量扩展性	4	3	12
一致性满足度	3	5	15
成本可控性	3	4	12
总分			79

权重怎么定？看业务场景。比如金融系统，一致性权重拉满；IoT 场景，数据量扩展性权重最高。别死板，灵活调整。

嗯，最后说一句：选型没有银弹。每个数据库都有它的「甜蜜点」。你只要把这五个维度吃透了，选出来的方案至少不会出大错。剩下的，就是压测和迭代了。