不同行业的数据库选型决策框架：OLTP/OLAP/HTAP的选择矩阵

不同行业的数据库选型决策框架OLTP/OLAP/HTAP的选择矩阵一、所有需求都用MySQL然后发现跑不动分析几乎所有技术团队都走过这条路创业初期MySQL承担一切——用户的CRUD、运营的报表、数据的聚合。当数据量突破5000万行运营月报的查询从2秒变成200秒团队开始寻找OLAP方案。但这时候发现业务已经深度耦合了MySQL的Schema和查询语法迁移成本高得惊人。数据库选型的本质是在知道自己一年后会面临什么问题的前提下做决策。但大多数人做选型时并不知道一年后会面临什么。因此选型框架的价值在于提供预见性。二、OLTP/OLAP/HTAP的三角决策模型决策矩阵决策因素OLTP(MySQL)OLAP(ClickHouse)HTAP(TiDB)单行查询延迟1ms10-50ms1-5ms聚合扫描(1亿行)30s1s3-10s写入TPS1万-5万10万-50万3万-10万数据量上限数TBPB级数十TBSQL兼容性完整MySQLMySQL子集MySQL兼容运维复杂度低中中高成本低中高三、行业场景的选型示例class DatabaseSelectionFramework: 数据库选型决策框架 def recommend(self, requirements: dict) - list: requirements { query_pattern: oltp | olap | mixed, data_volume_gb: 500, peak_qps: 10000, consistency: strong | eventual, availability: 99.99, budget: low | medium | high, team_skill: mysql | distributed | all, growth_rate_gb_month: 50, } score {} # MySQL评分 mysql_score self._score_mysql(requirements) if mysql_score 0: score[MySQL] mysql_score # ClickHouse评分 if requirements[query_pattern] in (olap, mixed): ch_score self._score_clickhouse(requirements) if ch_score 0: score[ClickHouse] ch_score # TiDB评分 if requirements[growth_rate_gb_month] 100: tidb_score self._score_tidb(requirements) if tidb_score 0: score[TiDB] tidb_score # 排序 推荐 ranked sorted(score.items(), keylambda x: x[1], reverseTrue) recommendations [] for db, s in ranked: if s 60: recommendations.append({ database: db, score: s, suitable: YES if s 80 else CONDITIONAL, risks: self._get_risks(db, requirements) }) return recommendations def _score_mysql(self, req: dict) - float: MySQL适用性评分 score 0.0 if req[query_pattern] oltp: score 40 elif req[query_pattern] mixed: score 20 if req[data_volume_gb] 500: score 30 elif req[data_volume_gb] 2000: score 15 if req[team_skill] mysql: score 20 if req[budget] low: score 15 # 超大单表减分 if req[data_volume_gb] 5000: score - 30 return score def _score_clickhouse(self, req: dict) - float: ClickHouse适用性评分 score 20.0 # 基础分 if req[query_pattern] in (olap, mixed): score 30 if req[data_volume_gb] 500: score 20 if req[peak_qps] 100: score 15 # ClickHouse适合低QPS高复杂度的查询 if team_skill not in req or req[team_skill] ! mysql: score - 10 # 需要学习成本 return score四、选型后必须回答的三个问题在选定数据库方案后有10个案例中至少有6个最终会部分推翻初始选型真正稳固的方案回答了以下三问问题一单表最大数据量是多少3年后如果从现在的5000万增长到3年后的5亿单机MySQL可能撑不到那时候。选型应该基于3年后的数据量做预判。问题二最复杂的查询SQL长什么样如果最复杂的是SELECT * FROM orders WHERE user_id ?——OLTP即可。如果是多个CTE 窗口函数 跨月聚合——OLAP或者至少是MySQL 8.0的CTE窗口函数。问题三数据一致性丢失的代价是多少金融资金损失 监管处罚→ 强一致必须。电商少部分超卖可以事后退款补偿→ 最终一致可接受。IoT少几条传感器数据无所谓→ 弱一致即可。五、总结数据库选型的框架不是给出一份正确答案而是让你在选型时知道自己放弃了什么。选择MySQL意味着放弃了水平扩展选择ClickHouse意味着放弃了事务支持选择TiDB意味着接受更高的运维成本。在实际的工程实践中80%的场景用MySQL(OLTP) ClickHouse(OLAP) Redis(缓存) Kafka(消息)的标准组合就能满足需求。剩下20%的特殊场景才需要引入NewSQL/HTAP/时序数据库等专业引擎。本文属于「行业场景与项目复盘」系列第4周收官提供跨行业的数据库选型决策框架与评估矩阵。