数据库类型

关系型数据库把数据锁在二维表里，这事儿从1970年代Codd提出模型就没怎么变过。库类我上周排查一个线上问题，数据订单表orders和用户表users做JOIN，库类数据量刚过两千万，数据查询跑了4.7秒。库类加索引？数据早加了。问题出在业务需要同时按用户地区、库类下单时间、数据商品类目三个维度筛选，库类B+树索引只能高效覆盖最左前缀。数据这种场景下，库类关系模型的数据行存储结构就是瓶颈——它把整行数据连续放在磁盘上，哪怕你只需要其中两列。库类

所以有了列式数据库。数据ClickHouse、Doris这些东西不是凭空冒出来的。它们把每一列单独存，同一列的数据类型一致，压缩比能到10:1甚至更高。我试过把一份用户行为日志导入ClickHouse，同样的聚合查询，原来在MySQL上要扫全表，这里直接读列存文件，0.3秒出结果。但别高兴太早——列存不适合高频单行更新。你改一个用户的状态，得把整列重写一遍，代价高得离谱。这就是典型的“读写分离”思路在存储层的体现。

键值数据库更极端。Redis把数据全放内存，GET和SET的延迟在微秒级。我见过一个电商大促场景，用Redis存购物车，QPS冲到12万，单节点稳稳扛住。但内存贵啊，1GB内存能存的数据量，磁盘上能放100GB。所以Redis适合做缓存、会话、排行榜，不适合当主存储。持久化？RDB快照和AOF日志都有丢数据的窗口，别指望它当银行账本。

文档数据库是另一条路。MongoDB的BSON格式允许嵌套，一个订单文档里直接塞商品列表、收货地址、支付记录。开发时爽，不用JOIN，一次查询全拿到。但数据一致性得自己兜底。我见过一个项目，用户表和订单表分两个文档集合，结果用户注销后订单还挂着，查出来一堆孤儿数据。MongoDB 4.0之后支持多文档事务，性能嘛……比单文档操作慢一个数量级。所以文档库适合那种“聚合根”清晰的场景，比如CMS的内容管理，一篇文章连带评论、标签全在一个文档里。

图数据库解决的是关系深度问题。社交网络里“找二度人脉”这种查询，关系库要写递归CTE或者多次JOIN，图数据库用MATCH (a)-[:FRIEND]->(b)-[:FRIEND]->(c)直接遍历。Neo4j的存储引擎对指针跳转做了优化，几跳之内性能稳定。但图库的坑在于：它不擅长做全量聚合。你让它统计所有用户的平均好友数，它得遍历所有节点，比关系库的AVG()慢得多。工具是拿来用的，不是拿来拜的。

时序数据库这两年火得不行。InfluxDB、TimescaleDB、TDengine，名字一堆。核心就一件事：按时间分区，自动降采样。我部署过一套TDengine监控服务器指标，每10秒采集一次CPU、内存、磁盘，一年下来几十亿条数据。查询“过去7天每5分钟的平均CPU使用率”，它直接命中预聚合的物化视图，毫秒级返回。关系库做同样的事，得建分区表、写定时任务、维护汇总表，麻烦得多。但时序库的查询语言通常只支持时间范围过滤和简单聚合，你想做个多表关联分析？没门。

还有搜索型数据库，Elasticsearch算代表。倒排索引让它对全文检索快得离谱。我帮朋友查一个法律文书库，几百万份判决书，搜“劳动合同 违约金 竞业限制”，ES 200毫秒返回相关度排序的结果。换PostgreSQL的tsvector？也能做，但中文分词、同义词扩展、相关性调优，工作量差一个量级。不过ES的写入性能一般，而且它默认近实时——数据写入后1秒才能搜到。对日志分析无所谓，对订单搜索就是事故。

选数据库这事，没有银弹。我自己的判断标准就三条：数据模型匹配度、读写比例、一致性要求。关系库依然是默认选项，因为大部分业务的数据关系天然适合二维表。但当你发现某个查询反复拖慢系统，而业务逻辑又绕不开那个瓶颈时，就该考虑换一种存储引擎了。别为了技术而技术，也别死守一种工具。数据库类型这么多，本质上是不同场景下的权衡产物。用对了，系统稳如老狗；用错了，天天救火。