现在都有哪些数据库 各自区别和应用场景

做选型时最常卡住的不是「不知道有哪些数据库」，而是知道一堆名字却说不清它们各自为什么长这样。这篇按数据形状、访问模式、一致性要求、扩展方向四条线把主流类型摆开，再给一套从写清单到压测验证的顺序；读完你能自己判断某个业务该落到哪一类，而不是照抄别人的技术栈。

做选型时最常卡住的不是「不知道有哪些数据库」，而是知道一堆名字却说不清它们各自为什么长这样。你去看对比文章，往往一半在讲数据模型，一半在讲某家产品的部署形态，还有一半在讲某个垂类场景的封装，三者根本不在同一个维度上，所以越查越乱。

这篇换个做法：按数据形状、访问模式、一致性要求、扩展方向四条线把主流类型摆开，再给一套从写清单到压测验证的顺序。读完你应该能自己判断某个业务该落到哪一类，而不是照抄别人的技术栈。需要注意的是，如果你所在的组织已经绑死了某类引擎（合规要求、团队只会一种运维栈），选型空间其实很小，先确认约束再谈技术，别浪费时间去比较用不上的选项。

为什么「有哪些数据库」这个问题越查越乱

市面上的名字是按不同维度混在一起卖的：有的是数据模型（关系、文档、图），有的是部署形态（单机、分布式、托管），有的是用途封装（向量、时序、搜索）。不在同一层，就永远对不上号。你要做的第一件事是把名字拆成两层看：一层是引擎类型，它决定能力边界；另一层是某家的产品名，它决定运维方式和账单形态。

引擎类型

数据模型加上存储与查询方式，决定了它能做什么、不能做什么，换产品也改不了

产品形态

同一类引擎有自建、云托管、兼容层等不同包装，影响的是运维人力与成本，不影响能力上限

用途封装

向量、时序、搜索这类往往是为主库打补丁的专用引擎，通常并存而不是替代

第一刀：你的数据长什么样

这一刀最好切，因为数据形状基本改不了。你先拿出一张真实的表或一条真实的记录，看它是规规矩矩的列，还是一条自带完整结构的文档，还是一堆点和边，还是一串高维数字。形状不对，后面所有优化都是在跟引擎打架。

• 结构化且关系多、要跨表关联和事务：关系型是默认起点，多数业务不需要绕过它
• 字段不固定、一条记录自带完整结构、读多写少：文档型更顺手
• 天然是点与边、要按路径跳几层：图数据库，用关系型硬写多层递归会很痛苦
• 高维向量、要按相似度找最近的几条：向量型，它通常和主库并存而不是替换主库

第二刀：访问模式和一致性要求

形状对了还要看怎么用。同样是结构化数据，一天写几条和每秒写几万条，落到的基础设施完全不是一回事；同样要求毫秒返回，按主键查和按任意字段组合查，难度也差着量级。这一刀的重点是把「读多写少还是写多读少」「查询条件是固定几种还是任意组合」写清楚。

• 写下为主、量极大、按时间顺序追加：时序或列族方向，关系型在写入吞吐上会先顶不住
• 读放大严重、要求毫秒级按主键取：键值型，代价是查询维度几乎锁死在主键上
• 必须强一致且跨多行多表：优先关系型的事务能力，换成最终一致的库要自己在业务层补补偿逻辑
• 一致性只影响日志、埋点、推荐结果这类可重算的数据：最终一致完全够用，不必硬上强一致

第三刀：扩展方向选纵向还是横向

先量清楚当前数据量和增长曲线。多数项目在单机加索引加缓存这一层就能撑很久，过早分布式会先输在运维复杂度上：分片键选错、跨分片查询变慢、扩容时数据重分布，每一项都是实打实的人力。判断标准不是「大厂用了什么」，而是你的查询里有几张表参与、能不能接受跨分片查询。

1. 先量数据量和增长曲线取当前数据量、近几个月的月增量、单条记录的平均大小，算出大约多久会到单机上限；这一步不做，后面全是拍脑袋。
2. 列出典型查询的形状把线上最常跑的十几条查询写出来，标注涉及几张表、返回多少行、有没有排序和聚合；查询形状决定了你能不能接受分片键带来的限制。
3. 确认横向扩展的代价如果需要横向扩，先确认分片键、跨分片查询频率、扩容时是否需要停机；能接受这些限制，再选键值、列族或部分文档型。
4. 确认纵向还能撑多久如果查询复杂、跨表多，又必须横向扩，分布式关系型或兼容层是折中，但要实测跨节点事务和延迟的实际表现。

还有一条容易被忽略：扩展方向一旦定了，数据模型往往要跟着改。所以第三步要放在写代码之前，而不是上线之后才发现分片键选错。

向量、全文、时序这几类特殊库什么时候必须上

这三类经常被当成「下一代数据库」来推，其实它们多数是补充引擎，不是替代主库。判断要不要上，看的是主库有没有明确的短板，而不是别人都在用。常见做法是主库照旧，专用引擎异步同步一份过去，不一致时以主库为准。

决定上之前，先把数据怎么同步、不一致时以谁为准、回滚时怎么把专用引擎摘掉写进方案。这三件事没写清楚，上线后就是事故来源。

一套能照着走的选型顺序

把前面几刀收成一条能执行的流程。核心思路是先用约束砍掉大部分选项，再用真实数据做一次压测验证，最后确认退路。不要一上来就列十几项的对比表，那样你只会在参数里迷路。

1. 写清三件事数据形状（结构化/半结构化/图/向量）、核心查询（按什么字段、什么条件、返回多少）、一致性底线（能接受最终一致吗）；写成一段话，发给团队里的人看能不能看懂。
2. 交叉筛到一到两类按数据形状、访问模式、扩展方向三刀交叉，通常只剩一到两类引擎；剩下的再看产品形态（自建还是托管）和运维成本。
3. 用真实数据压测拿真实数据量和真实查询做压测，看写入吞吐、按典型查询的延迟、数据膨胀后索引是否还生效；具体基准数值到 /tools/speed-test 按当时口径核对。
4. 确认退路数据怎么导出、能不能双写并行跑一段、迁移失败怎么回滚；这三条写进方案，再开始动手。

新手最容易踩的几个坑

这些坑之所以常见，是因为它们在短期看起来都是「先进做法」，长期才暴露成本。下面几条，小团队尤其要克制。

• 为了「先进」上多套存储，结果同步链路成了事故来源，可用组件越多，出错面越大
• 把缓存当数据库用，重启后数据没了才想起没有持久化策略
• 忽略运维成本：备份、扩容、版本升级、监控指标这些在自建时都是人力，托管则体现为账单，两边都要算
• 用别人的基准数字做决策，而不是用自己数据的压测结果
• 没想好回滚路径就动手迁，真出问题时无法退回原方案

如果你已经踩进了第一条，别急着再加一套工具去补救，先把数据流画出来，看看哪一步是真正必要的。多数情况下，减少一个环节比增加一个监控更有效。至于各家产品的价格和当前口径，去 /price-watch 和 /sites 核对当时的数字，不要用旧印象做判断。

上线前对照清单

选型本身不是终点，上线前还需要把运维和数据安全的事确认一遍。下面这份清单可以直接拿去对，缺哪条补哪条。

这份清单不用一次全绿，但每一条都要有明确的负责人和完成时间。没有负责人的检查项，等于没检查。