常见的数据库类型有哪些

```html

关系型数据库可能是据库大多数人接触到的第一种数据库。MySQL、类型PostgreSQL、据库Oracle、类型SQL Server，据库这些名字在招聘要求里反复出现。类型它们的据库共同点是数据以行和列的形式存放在表里，表与表之间可以通过外键关联。类型银行转账是据库最典型的例子：从A账户扣钱、给B账户加钱，类型这两个操作必须在一个事务里完成，据库要么都成功，类型要么都回滚。据库关系型数据库用ACID（原子性、类型一致性、据库隔离性、持久性）来保证这类场景不出乱子。我见过一个电商团队在订单量突破千万级后，仍然用MySQL单库硬扛，结果每次大促都出现超卖。后来他们把订单拆到分库分表，才缓过来。关系型数据库适合结构清晰、一致性要求高的业务，但水平扩展确实是它的软肋。

键值数据库走的是另一条路。Redis、Memcached、RocksDB，数据就是一个键对应一个值。没有表结构，没有外键，查询只能靠键。这听起来简陋，但速度极快。Redis单机每秒能处理十万次以上的读写，很多互联网公司拿它做缓存、会话存储、排行榜。我印象很深的是一个社交App的“附近的人”功能，早期用MySQL的经纬度范围查询，慢得让人想砸手机。换成Redis的GEO数据结构后，响应时间从几百毫秒降到几毫秒。键值数据库的短板也很明显：你没法根据值的内容来查数据，只能按设计好的键去取。如果业务需要多维度查询，它就不合适了。

文档数据库在键值的基础上往前走了一步。MongoDB、Couchbase、Firestore，存的是类似JSON的文档。每个文档可以有自己的字段，不需要提前定义表结构。一个用户文档可以包含姓名、地址、订单列表，甚至嵌套的评论数组。这种灵活性对快速迭代的产品很友好。我参与过一个内容管理系统，文章类型经常变，今天加个“作者简介”，明天加个“相关阅读”。用MongoDB的时候，直接往文档里加字段就行，不用改表结构、不用停机迁移。但文档数据库的坑在于：嵌套太深会让查询变复杂，而且跨文档的事务支持直到近些年才逐渐成熟。如果你的数据关系复杂，还是得回到关系型数据库。

列式数据库是为分析场景设计的。ClickHouse、HBase、Cassandra，数据按列存储，而不是按行。这有什么好处？做聚合查询的时候，比如“统计过去一年每个月的销售额”，列式存储只需要读取“销售额”这一列，不用把整行数据都拉出来。ClickHouse在这类查询上能比MySQL快几百倍。我见过一个广告公司，每天要分析几十亿条曝光日志，用ClickHouse做实时报表，查询响应在秒级。但列式数据库不适合频繁的单行更新，也不适合事务型操作。它天生就是为读多写少、大批量分析准备的。

图数据库比较特殊。Neo4j、JanusGraph、Amazon Neptune，节点和边是核心概念。社交网络里的“好友的好友”、风控系统里的“资金环路”、推荐引擎里的“相似用户”，这些用关系型数据库写SQL会非常痛苦，多层JOIN能把人逼疯。图数据库用遍历的方式查关系，几跳之内性能依然可控。我试过用Neo4j查一个三度人脉，语句直观得像在画图。但图数据库的生态和人才储备远不如关系型数据库，选它之前得想清楚：你的业务真的需要频繁遍历关系吗？如果只是偶尔查一次，用关系型数据库加缓存也能凑合。

时序数据库是近几年物联网和监控系统带火的。InfluxDB、TimescaleDB、Prometheus，专门处理带时间戳的数据。温度传感器每秒钟上报一次，服务器CPU使用率每五秒采集一次，这些数据写多读少，而且总是按时间范围查询。时序数据库做了很多针对性优化：高压缩比、自动过期删除、时间窗口聚合。一个智能电表项目，每天新增两千万条读数，用InfluxDB存储和查询都很顺畅。换成MySQL的话，光索引维护就能把写入拖垮。不过时序数据库通常不支持复杂的关联查询，业务逻辑太复杂就别硬套。

选数据库不是选最好的，是选最合适的。我见过不少团队跟风上MongoDB，结果发现业务需要多表事务，又灰溜溜改回MySQL。也见过有人用Redis存全量数据，内存成本高得吓人。先搞清楚你的数据长什么样、怎么查、一致性要求多高、写入量多大，再去看对应的数据库类型。没有银弹，只有权衡。