【DB】数据库分类与选型关系型键值缓存型文档与图时间序列与监控列式分析搜索与向量【DB】数据库分类与选型关系型Mysql键值缓存型Redis文档与图MongoDB-Neo4j时间序列与监控Prometheus列式分析 ClickHouse搜索与向量 ES-VexDB文章目录一、数据库到底有几类什么是数据库为什么不能只按产品名称分类先按工作负载分成六个大类同一大类内还要继续细分二、六大类数据库的产品差异1. 关系型交易数据库优先承载核心事实MySQLPostgreSQLSQL Server2. 键值数据库与缓存用速度换取模型简单RedisMemcachedKeyDB3. 文档、图、目录与无代码数据库模型随业务而变MongoDBNeo4j4. 时间序列与监控数据库时间是第一索引InfluxDBTDenginePrometheus5. 列式分析和 MPP让聚合扫描跑得快ClickHouseStarRocks6. 搜索与向量数据库为“找得准、找得快”建索引ElasticsearchTypesenseVexDB三、按业务场景做数据库选型先问业务再看产品常见场景的推荐组合一个可落地的电商数据架构上线前的容量估算四、实践、运维边界与常见问答关系型数据库事务和索引先行缓存使用 Cache-Aside并处理三类故障搜索、分析和向量明确“最终一致”运维检查清单常见问答数据库不是“把数据存进去”的同一种软件。它们对数据的组织方式、查询语言、事务能力、扩展方式和运维成本都不同。选型时如果只看“谁的性能更高”很容易把缓存当主库、把搜索引擎当事务库或者用分析型数据库承载高频订单写入。本文不按厂商或产品名称罗列数据库而是先建立一张“类型地图”再把常见产品放回各自适合的位置。你会看到数据库并不是互相割裂的几十个物种很多产品共享同一类数据模型只是在事务能力、查询方式、扩展策略和运维成本上有所不同。文中提到的“集群”属于部署和可靠性方案不代表一种新的数据模型。一、数据库到底有几类什么是数据库数据库管理系统Database Management SystemDBMS是负责持久化、组织、查询、并发控制、权限管理和恢复数据的软件。数据库本身是数据集合DBMS 才是提供服务的程序。Redis、Elasticsearch、Prometheus 等虽然常被叫作数据库但它们的主要目标分别是高速数据结构访问、搜索和监控时序存储不能简单地和关系型数据库互换。为什么不能只按产品名称分类同一个产品可以同时属于多个维度。例如 ClickHouse 是列式数据库也是分析型数据库Redis 是键值数据库也常被用作缓存OceanBase 是关系型数据库同时提供分布式扩展能力。因此选型至少要回答四个问题判断维度要回答的问题典型选项数据模型一条数据如何组织和关联表、文档、键值、图、时间序列、向量工作负载主要是读写交易还是聚合分析OLTP、OLAP、搜索、缓存、监控一致性是否需要事务、约束和强一致强一致事务、最终一致、允许丢失的缓存扩展方式数据增长后如何扩容垂直扩容、读写分离、分片、MPP、集群先按工作负载分成六个大类大类共同特征代表产品主要解决的问题关系型交易OLTP表结构、SQL、事务和约束MySQL、PostgreSQL、MariaDB、Microsoft SQL Server、OceanBase、GreatSQL订单、账户、库存、权限等核心事实键值与缓存通过 key 快速访问部分产品提供丰富数据结构Redis、KeyDB、Valkey、Memcached热点数据、Session、限流、排行榜和短期状态文档、图与数据平台用文档、关系、层级对象或界面组织数据MongoDB、Neo4j、OpenLDAP、NocoDB结构灵活的内容、多跳关系、身份目录和内部工具时序与可观测性按时间追加强调标签、窗口聚合和保留策略InfluxDB、TDengine、Prometheus指标、设备测点、告警和运行监控分析型OLAP列式存储、压缩和并行聚合ClickHouse、StarRocks埋点、日志、报表和实时数仓检索型倒排索引或向量近邻检索Elasticsearch、Typesense、Manticore Search、VexDB全文搜索、联想、语义召回和推荐同一大类内还要继续细分关系较近的产品共同点主要差异MySQL、MariaDB、GreatSQL兼容 MySQL 协议和常见 SQL迁移成本相对较低版本分支、优化器、存储引擎、高可用和商业支持不同Redis、KeyDB、Valkey兼容 Redis API提供内存数据结构访问线程模型、社区治理、模块生态、持久化和集群工具不同InfluxDB、TDengine、Prometheus都保存带时间和标签的指标或测点写入模型、查询语言、采集方式、长期存储和高基数处理不同ClickHouse、StarRocks都面向列式分析和大规模聚合数据导入、更新语义、联邦查询、Join 能力和并发模型不同Elasticsearch、Typesense、Manticore Search都通过索引加速全文、过滤和排序分词与相关性、资源占用、运维复杂度和 API 生态不同这六个大类是从“工作负载”角度做的第一层分组并不是六个互不相容的盒子。列式说的是存储方式OLAP说的是分析型负载集群说的是部署方式开源/商业说的是产品和授权方式它们本来就不在同一个维度。一个产品可以同时拥有多个标签ClickHouse 是列式数据库和 OLAP 数据库Redis 是键值数据库也常被当作缓存OceanBase 是关系型数据库同时具备分布式扩展能力。再往下看同一大类里的产品也不是完全相同MySQL、MariaDB、GreatSQL 更接近“兼容 MySQL 生态”的路线PostgreSQL 更强调标准 SQL 和扩展能力Redis、KeyDB、Valkey 都理解 Redis 协议但线程模型、治理方式和兼容性不同ClickHouse 与 StarRocks 都能做 OLAP却分别在存储、导入、联邦查询和并发模型上有侧重。选型的正确顺序是先确定大类再比较同类产品的差异最后用真实数据和查询压测验证。有三个原则值得先记住主库负责事实缓存负责加速搜索和数仓负责派生数据先根据查询模式选模型再比较具体产品集群是部署和可靠性问题不是新的数据模型。只要把这三点分开数据库选型会清晰很多。二、六大类数据库的产品差异1. 关系型交易数据库优先承载核心事实MySQLPostgreSQLSQL Server关系型数据库把数据放在表中用主键、外键、唯一约束和事务保证业务规则。典型事务要满足 ACID原子性、一致性、隔离性和持久性。对于“扣库存、写订单、记账”这类必须正确的操作关系型数据库通常是第一选择。数据库类型与特点什么时候用MySQL开源关系型数据库生态成熟、使用广泛读写性能和运维工具丰富Web 业务、内容系统、电商主库团队希望快速交付且使用成本可控时PostgreSQL开源关系型数据库SQL 标准、事务、扩展类型和复杂查询能力强地理信息、复杂报表、数据分析前置处理或对约束和 SQL 能力要求高的系统MariaDBMySQL 的社区分支协议和使用方式相近已有 MySQL 经验、需要社区分支或发行版支持并且应用兼容性已验证时Microsoft SQL Server微软的商业关系型数据库和 Windows、.NET、BI 工具集成紧密企业内部系统、微软技术栈、需要 SSIS/SSRS/Power BI 等配套能力的场景OceanBase兼容 MySQL 的分布式关系型数据库支持多副本和水平扩展数据量或可用性超过单机边界又希望保留 MySQL 生态和 SQL 使用习惯时GreatSQL面向 MySQL/Percona Server 的增强分支关注高可用、安全和国产化生态已经使用 MySQL希望在兼容基础上获得增强特性、技术支持或国产替代方案时这几种产品不是越“高级”越好。小型业务优先考虑 MySQL 或 PostgreSQL已经绑定微软生态就选择 SQL Server需要分布式事务、跨节点扩展时再评估 OceanBase。GreatSQL 和 MariaDB 都要先做应用、驱动、SQL 方言及备份恢复的兼容性测试。MySQL-Cluster、PostgreSQL-Cluster不是全新的数据库类型而是对应数据库的复制/高可用部署形态。常见的一主多从方案由主库处理写入从库提供只读能力或灾备。它们能提升读吞吐和故障切换能力但不会自动解决跨库事务、主从延迟和写入单点问题。生产环境还需要故障探测、选主、备份、演练和连接层路由。2. 键值数据库与缓存用速度换取模型简单RedisMemcachedKeyDB数据库主要能力什么时候用关键边界Redis单线程事件循环部分版本包含多线程 I/O、丰富数据结构、Lua/事务、持久化缓存、Session、排行榜、延迟队列、限流、分布式锁内存成本高不要把未持久化的数据当唯一事实Redis-ClusterRedis 的分片和故障转移部署按 slot 分布 key数据量或吞吐超过单节点需要水平扩展时多 key 操作要遵守同一 hash slot集群不等于强一致事务KeyDBRedis 协议兼容的多线程分支擅长提高单节点并发已有 Redis 客户端希望利用多核降低延迟时版本、模块和持久化行为要单独验证不要默认完全等价ValkeyRedis 协议兼容的开源数据结构服务器由社区维护需要开放治理、兼容 Redis API 的缓存或数据结构服务时仍要评估版本兼容、集群工具和云厂商支持Memcached极简的分布式内存缓存key-value、无持久化、易横向扩展只需要缓存热点结果且允许缓存失效或丢失时不支持复杂数据结构、持久化和可靠消息语义Redis、KeyDB、Valkey 适合承载“可重建的状态”。例如商品详情可以从 MySQL 重建验证码过期后没有价值而账户余额不能只放在 Redis。Memcached 更简单适合纯缓存和大规模横向扩容不适合需要列表、集合、发布订阅或持久化的场景。3. 文档、图、目录与无代码数据库模型随业务而变MongoDBNeo4jMongoDB文档型数据库以 BSON/JSON 文档为中心字段可逐步演进。适合商品属性、CMS 内容、用户行为事件等结构差异较大的数据。需要跨文档强事务、严格外键和复杂联表时关系型数据库通常更稳妥。Neo4j图数据库用节点、关系和属性表达数据擅长多跳遍历例如“朋友的朋友”“设备经过哪些网关”“某个风险账户关联了哪些主体”。如果主要查询是按主键取一行使用图数据库会增加不必要的复杂度。NocoDB无代码数据库平台把表格界面、权限和 API 叠加在底层数据源上。它适合内部管理台、项目协作和原型验证价值在于快速让非研发人员维护数据它不是自动替代 MySQL/PostgreSQL 的高并发交易内核。OpenLDAPLDAP 协议的开源目录服务数据通常是层级化的 DN、组织、用户和组。适合统一认证、通讯录和组织架构查询它的查询和更新模型与业务数据库不同不应用来存订单明细。4. 时间序列与监控数据库时间是第一索引InfluxDBTDenginePrometheus数据库适合的数据使用建议InfluxDB指标、事件和带 tag 的时间序列应用监控、IoT 采集、按时间窗口聚合注意高基数 tag 会造成内存和索引压力TDengine工业物联网中的设备测点和高频时序数据设备数量大、写入持续、需要降采样和保留策略时建模时区分设备表、超级表和标签Prometheus监控指标采用拉取模型内置本地 TSDB 和 PromQLKubernetes、服务监控和告警短期高效可靠长期保存应接远程存储不承担业务明细时间序列库的共同点是写入通常按时间追加查询常见“最近一小时平均值”“按设备聚合”。不要把每个用户 ID、请求 ID 都当作标签否则标签基数会爆炸。Prometheus 的instance、pod等标签适合监控维度但用户行为明细更适合日志系统或分析型数据库。5. 列式分析和 MPP让聚合扫描跑得快ClickHouseStarRocksClickHouse列式存储、压缩率高、向量化执行适合埋点、日志、广告和财务报表的海量聚合。它对批量写入和追加友好对频繁单行更新、复杂事务和强外键约束不友好。StarRocks新一代极速全场景 MPP 数据库强调实时数仓、联邦查询和高并发分析。适合需要较低延迟报表、明细加聚合混合查询的场景。上线前应按数据导入方式、分区、分桶和并发模型做压测。ClickHouse 和 StarRocks 都能做分析但不能只凭基准分数选择。数据是否持续更新、是否需要多表关联、查询并发和运维团队经验往往比单次扫描速度更重要。常见做法是事务库保存事实CDC 或消息队列把变更同步到 OLAP再由 OLAP 服务报表。6. 搜索与向量数据库为“找得准、找得快”建索引ElasticsearchTypesenseVexDB数据库特色什么时候用Elasticsearch分布式倒排索引、全文检索、聚合、日志生态成熟日志检索、商品搜索、复杂过滤和可观测性平台Typesense轻量、低延迟、容错搜索接口相对简单中小规模站内搜索、自动补全、拼写容错团队希望降低运维复杂度Manticore Search高性能全文搜索和分析支持多种存储与 SQL 风格访问需要搜索性能、SQL 接入或与已有关系型数据配合的场景搜索索引通常是主库的派生数据。正确流程是“先写主库再通过 CDC/消息更新索引”而不是只写 Elasticsearch。需要接受短暂的一致性延迟并设计重建索引、删除同步、版本切换和查询降级。搜索结果涉及权限时必须在索引阶段或查询阶段做权限过滤。VexDB可以理解为融合关系数据能力与多路语义检索能力的向量数据库。这类数据库把文本、图片或其他对象转换为向量使用余弦相似度、内积或 L2 距离查找近邻适合知识库问答RAG、语义搜索、相似商品和推荐召回。向量检索得到的是候选集合通常还需要结合关键词、权限、时间和业务规则做过滤与重排。向量库的关键设计包括嵌入模型版本、向量维度、距离函数、分片索引、元数据过滤和删除策略。更换嵌入模型时旧向量不能和新向量直接混查最好通过版本字段和双索引平滑切换。订单、余额、库存等结构化事实仍应放在关系型数据库中。三、按业务场景做数据库选型先问业务再看产品可以按下面的顺序缩小范围是否需要事务、约束和准确更新 ├─ 是MySQL / PostgreSQL / SQL Server │ └─ 单机边界不够评估 MySQL-Cluster、PostgreSQL-Cluster 或 OceanBase └─ 否主要需求是什么 ├─ 热点 key 和短期状态Redis / Valkey / KeyDB / Memcached ├─ JSON 文档MongoDB ├─ 多跳关系Neo4j ├─ 时间窗口聚合InfluxDB / TDengine / Prometheus ├─ 海量报表分析ClickHouse / StarRocks ├─ 关键词和全文Elasticsearch / Typesense / Manticore Search ├─ 语义相似度VexDB └─ 组织身份目录OpenLDAP快速内部表格NocoDB常见场景的推荐组合场景主数据加速或派生数据说明电商下单MySQL / PostgreSQL / OceanBaseRedis、Elasticsearch、ClickHouse主库保证订单和库存缓存防热点搜索和报表异步构建SaaS 多租户PostgreSQL 或 MySQLRedis、Typesense租户字段、索引和权限模型先设计清楚再决定分库分表IoT 设备平台MySQL 保存设备与配置TDengine/InfluxDBPrometheus 做平台监控测点数据和业务配置分离按时间分区和保留策略治理Kubernetes 可观测性业务库按需选择Prometheus、Elasticsearch、ClickHouse指标、日志、链路分别建模避免一个系统包打天下企业统一认证OpenLDAP关系库保存业务授权映射LDAP 保存身份目录订单和业务权限仍由业务系统管理知识库问答PostgreSQL/MySQL 保存文档元数据VexDB Elasticsearch/Typesense关键词和向量召回结合最终回答前校验权限和版本内部协作原型NocoDB根据增长情况接入 MySQL/PostgreSQL先验证流程达到并发、审计或事务要求后再工程化一个可落地的电商数据架构浏览器 / App │ ├─ 订单、库存、支付 ── MySQL 或 OceanBase唯一事实来源 ├─ 热点商品、Session ── Redis / Valkey缓存和短期状态 ├─ 商品检索 ────────── Elasticsearch / Typesense异步索引 ├─ 经营报表 ────────── ClickHouse / StarRocks批量或实时同步 ├─ 运行监控 ────────── Prometheus日志检索可用 Elasticsearch └─ 语义推荐可选 ── VexDB这套架构的重点不是组件越多越好而是每个组件只有一个清晰职责。主库写入成功后再发布领域事件消费者失败可以重试或补偿缓存失效可以回源搜索和报表不可用时核心下单链路仍然能够工作。上线前的容量估算至少估算五组数字峰值读 QPS、峰值写 QPS、单条数据大小、保留周期、查询并发。以时间序列为例设备数乘以每秒采样点数决定写入量保留 30 天和保留 3 年会直接改变存储规模。以 Redis 为例除了 value 大小还要计算 key、对象编码、复制和集群预留内存不能只看业务字段长度。四、实践、运维边界与常见问答关系型数据库事务和索引先行CREATETABLEorders(idBIGINTPRIMARYKEY,user_idBIGINTNOTNULL,statusVARCHAR(20)NOTNULL,amountDECIMAL(18,2)NOTNULL,created_atTIMESTAMPNOTNULL,UNIQUEKEYuk_user_order(user_id,id),KEYidx_user_created(user_id,created_at));STARTTRANSACTION;UPDATEinventorySETavailableavailable-1WHEREsku_id1001ANDavailable0;-- 检查受影响行数为 1 后再写订单INSERTINTOorders(id,user_id,status,amount,created_at)VALUES(90001,42,PAID,99.00,CURRENT_TIMESTAMP);COMMIT;表结构要表达业务约束金额使用定点类型而不是浮点数扣库存要检查更新行数。读写分离后刚写入的数据可能在从库不可见需要强一致读取的请求应回主库或携带位点等待从库追平。缓存使用 Cache-Aside并处理三类故障读取 value cache.get(key) if value ! nil: return value value db.query(id) if value ! nil: cache.set(key, value, ttl300s) return value 更新 db.transaction(update) cache.delete(key) # 删除而不是直接写缓存减少并发覆盖需要额外防护缓存击穿、缓存穿透和雪崩热点 key 加互斥锁或 singleflight不存在的数据写入短 TTL 的空值TTL 增加随机抖动并准备限流和降级。分布式锁要设置过期时间、唯一 token 和释放校验不能把SETNX当成完整的锁服务。搜索、分析和向量明确“最终一致”主库提交事务 → 可靠消息/CDC → 搜索索引或 OLAP 导入 → 记录 offset 和失败原因 → 可重放、可校验、可重建搜索索引要有全量重建方案OLAP 表要有分区和数据校验向量索引要记录模型版本。任何派生库都应能从主库或原始事件重新生成否则数据损坏后只能人工修复。运维检查清单方面至少要做什么备份恢复明确 RPO/RTO定期做全量与增量备份真实环境演练恢复高可用验证故障探测、选主、脑裂保护、连接重试和读写路由数据安全最小权限、传输与静态加密、敏感字段脱敏、审计留痕性能记录慢查询、命中率、P95/P99 延迟、写入滞后和磁盘水位容量设置内存、磁盘、连接数、分片和标签基数的告警阈值变更版本升级、表结构、索引和分词模型都要可回滚一致性标明主库、缓存、搜索和数仓之间允许的延迟范围常见问答问MySQL 和 PostgreSQL 应该怎么选答业务以常规 Web 事务为主、团队和云服务更熟悉 MySQL 时MySQL 是稳妥起点需要复杂 SQL、丰富类型、地理信息或更严格约束时优先 PostgreSQL。最终以真实 SQL、数据量和团队运维能力压测不要只看排行榜。问Redis、Memcached 和 Valkey 是替代关系吗答它们都能做缓存但能力范围不同。Memcached 最简单Redis/Valkey 提供集合、列表、脚本和持久化等能力Valkey 重点是开源社区治理。若应用只使用基础 GET/SET三者都可评估若依赖 Redis 特性要逐项检查兼容性。问Prometheus 能不能存所有业务数据答不能。Prometheus 面向带标签的监控指标和告警适合短中期时间序列。订单明细、用户行为原文和长期数仓数据应放在对应的关系型、日志或分析型系统中。问为什么已经有 Elasticsearch还需要 Typesense 或 Manticore Search答它们解决的仍是搜索问题但运维模型、查询接口、资源占用和功能侧重点不同。中小规模站内搜索可以选更轻量的 Typesense需要 SQL 风格接入或多存储组合时可以评估 Manticore Search复杂日志、聚合和生态集成通常选择 Elasticsearch。问向量数据库是不是可以替代关系型数据库答不能。向量库负责近邻召回关系库负责可验证的结构化事实。RAG 系统通常同时保存文档元数据、权限和版本再把分块向量写入 VexDB并在召回后回查主库。问什么时候应该上“集群”答当单节点的容量、吞吐或故障恢复目标确实不够时再上。集群会引入分片键、复制延迟、网络故障、运维和成本。先通过索引、读写分离、缓存和归档解决单机问题再根据明确的容量和 RTO/RPO 指标选择MySQL-Cluster、PostgreSQL-Cluster、Redis-Cluster或 OceanBase。最后可以用一句话复盘选型数据的事实在哪里最常见的查询是什么允许多大的一致性延迟预计如何扩容团队能否长期运维能回答这五个问题数据库类型通常已经确定具体产品则交给兼容性验证、容量压测和故障演练来决定。