数据库选择指南：如何为你的项目选择合适的数据库

选择数据库是技术架构中最关键的决策之一。选错了，轻则性能瓶颈，重则数据丢失。问题在于，市面上的数据库种类繁多，每种都声称自己高性能、高可用，但实际上它们的设计目标完全不同。

本文的目标是帮你建立一个清晰的决策框架：先理解每类数据库的核心特性，再根据业务需求做出选择。

核心概念：一致性与性能的权衡

数据库选型的本质是在一致性和性能之间做权衡。

强一致性（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。

做选择时，按以下顺序问自己：

数据库选型没有银弹。关键是理解每类数据库的设计目标，然后匹配你的业务需求。

几个原则：

最后一点：选型只是开始，运维才是长期成本。选择团队熟悉的技术栈，往往比选择最先进的技术更重要。