选择数据库是技术架构中最关键的决策之一。选错了，轻则性能瓶颈，重则数据丢失。问题在于，市面上的数据库种类繁多，每种都声称自己高性能、高可用，但实际上它们的设计目标完全不同。
本文的目标是帮你建立一个清晰的决策框架：先理解每类数据库的核心特性，再根据业务需求做出选择。
核心概念：一致性与性能的权衡
数据库选型的本质是在一致性和性能之间做权衡。
强一致性（ACID）意味着每次写入都会立即对所有读取可见，适合金融、订单等不能出错的场景。代价是性能受限，因为需要等待多个节点确认。
最终一致性意味着写入后可能有短暂延迟才能读到最新数据，但换来的是更高的写入吞吐量和更好的水平扩展能力。适合日志、监控、社交动态等允许短暂延迟的场景。
数据库类型速查表
数据库类型
一致性
核心优势
典型场景
MySQL/PostgreSQL
强一致性
成熟稳定，生态完善
订单、财务、ERP
PolarDB
强一致性
云原生，读写分离
电商核心、金融支付
TiDB
强一致性
分布式事务，水平扩展
高并发事务、HTAP
Hadoop/HDFS
最终一致性
海量存储，批处理
数据湖、离线分析
HBase
最终一致性
高吞吐读写，低延迟
时序数据、日志存储
Cassandra
最终一致性
高写入吞吐，无单点
消息存储、推荐系统
ElasticSearch
最终一致性
全文搜索，实时索引
日志分析、搜索引擎
Lindorm
最终一致性
多模存储，一站式
IoT、时序、宽表
按场景选择
场景一：核心业务系统
电商订单、金融交易、库存管理——这类场景的特点是不能出错。一笔订单扣款成功但库存没减，或者两个用户同时抢到最后一件商品，都是灾难。
选择：MySQL/PostgreSQL（单机）、PolarDB（云原生）、TiDB（需要水平扩展时）
选择依据：必须支持 ACID 事务。如果数据量在单机承受范围内，MySQL/PostgreSQL 是最稳妥的选择；如果需要弹性扩展，考虑 PolarDB 或 TiDB。
场景二：大数据分析
用户行为分析、报表生成、机器学习训练数据——这类场景的特点是数据量大、查询复杂、对实时性要求不高。
选择：Hadoop/HDFS + Hive/Spark
选择依据：批处理能力强，成本低。不适合实时查询，但非常适合 T+1 的分析场景。
场景三：实时监控与日志
服务器监控、应用日志、IoT 设备数据——这类场景的特点是写入量极大、需要快速查询最近的数据。
选择：HBase（时序数据）、ElasticSearch（需要全文搜索）、Lindorm（多模数据）
选择依据：写入吞吐量是第一优先级。HBase 适合纯时序场景，ElasticSearch 适合需要复杂查询的日志分析，Lindorm 适合同时有时序、文档、宽表需求的场景。
场景四：高并发写入
社交平台消息、用户动态、设备状态上报——这类场景的特点是写多读少、需要水平扩展。
选择：Cassandra
选择依据：Cassandra 的架构设计就是为高写入吞吐量优化的，无单点故障，线性扩展。代价是查询能力较弱，不支持复杂 JOIN。
决策流程图
做选择时，按以下顺序问自己：
- 是否需要事务？ 是 → MySQL/PostgreSQL/TiDB/PolarDB
- 是否需要全文搜索？ 是 → ElasticSearch
- 是否是时序数据？ 是 → HBase/Lindorm
- 是否需要海量存储+批处理？ 是 → Hadoop/HDFS
- 是否需要高写入吞吐+水平扩展？ 是 → Cassandra
总结
数据库选型没有银弹。关键是理解每类数据库的设计目标，然后匹配你的业务需求。
几个原则：
- 核心业务优先选择强一致性数据库
- 不要用关系型数据库存日志
- 不要用 NoSQL 做复杂事务
- 如果不确定，先用 MySQL，等遇到瓶颈再迁移
最后一点：选型只是开始，运维才是长期成本。选择团队熟悉的技术栈，往往比选择最先进的技术更重要。