企业官网建设流程全解析

【DB】数据库分类与选型：关系型，键值缓存型，文档与图，时间序列与监控，列式分析，搜索与向量
【DB】数据库分类与选型：关系型Mysql，键值缓存型Redis，文档与图MongoDB-Neo4j，时间序列与监控Prometheus，列式分析 ClickHouse，搜索与向量 ES-VexDB

数据库不是“把数据存进去”的同一种软件。它们对数据的组织方式、查询语言、事务能力、扩展方式和运维成本都不同。选型时如果只看“谁的性能更高”，很容易把缓存当主库、把搜索引擎当事务库，或者用分析型数据库承载高频订单写入。

本文不按厂商或产品名称罗列数据库，而是先建立一张“类型地图”，再把常见产品放回各自适合的位置。你会看到，数据库并不是互相割裂的几十个物种：很多产品共享同一类数据模型，只是在事务能力、查询方式、扩展策略和运维成本上有所不同。文中提到的“集群”属于部署和可靠性方案，不代表一种新的数据模型。

一、数据库到底有几类

什么是数据库？

数据库管理系统（Database Management System，DBMS）是负责持久化、组织、查询、并发控制、权限管理和恢复数据的软件。数据库本身是数据集合，DBMS 才是提供服务的程序。Redis、Elasticsearch、Prometheus 等虽然常被叫作数据库，但它们的主要目标分别是高速数据结构访问、搜索和监控时序存储，不能简单地和关系型数据库互换。

为什么不能只按产品名称分类

同一个产品可以同时属于多个维度。例如 ClickHouse 是列式数据库，也是分析型数据库；Redis 是键值数据库，也常被用作缓存；OceanBase 是关系型数据库，同时提供分布式扩展能力。因此选型至少要回答四个问题：

先按工作负载分成六个大类

同一大类内还要继续细分

这六个大类是从“工作负载”角度做的第一层分组，并不是六个互不相容的盒子。列式说的是存储方式，OLAP说的是分析型负载，集群说的是部署方式，开源/商业说的是产品和授权方式，它们本来就不在同一个维度。一个产品可以同时拥有多个标签：ClickHouse 是列式数据库和 OLAP 数据库，Redis 是键值数据库也常被当作缓存，OceanBase 是关系型数据库同时具备分布式扩展能力。

再往下看，同一大类里的产品也不是完全相同：MySQL、MariaDB、GreatSQL 更接近“兼容 MySQL 生态”的路线，PostgreSQL 更强调标准 SQL 和扩展能力；Redis、KeyDB、Valkey 都理解 Redis 协议，但线程模型、治理方式和兼容性不同；ClickHouse 与 StarRocks 都能做 OLAP，却分别在存储、导入、联邦查询和并发模型上有侧重。选型的正确顺序是：先确定大类，再比较同类产品的差异，最后用真实数据和查询压测验证。

有三个原则值得先记住：主库负责事实，缓存负责加速，搜索和数仓负责派生数据；先根据查询模式选模型，再比较具体产品；集群是部署和可靠性问题，不是新的数据模型。只要把这三点分开，数据库选型会清晰很多。

二、六大类数据库的产品差异

1. 关系型交易数据库：优先承载核心事实（MySQL，PostgreSQL，SQL Server）

关系型数据库把数据放在表中，用主键、外键、唯一约束和事务保证业务规则。典型事务要满足 ACID：原子性、一致性、隔离性和持久性。对于“扣库存、写订单、记账”这类必须正确的操作，关系型数据库通常是第一选择。

这几种产品不是越“高级”越好。小型业务优先考虑 MySQL 或 PostgreSQL；已经绑定微软生态就选择 SQL Server；需要分布式事务、跨节点扩展时再评估 OceanBase。GreatSQL 和 MariaDB 都要先做应用、驱动、SQL 方言及备份恢复的兼容性测试。

MySQL-Cluster、PostgreSQL-Cluster不是全新的数据库类型，而是对应数据库的复制/高可用部署形态。常见的一主多从方案由主库处理写入，从库提供只读能力或灾备。它们能提升读吞吐和故障切换能力，但不会自动解决跨库事务、主从延迟和写入单点问题。生产环境还需要故障探测、选主、备份、演练和连接层路由。

2. 键值数据库与缓存：用速度换取模型简单（Redis，Memcached，KeyDB）

Redis、KeyDB、Valkey 适合承载“可重建的状态”。例如商品详情可以从 MySQL 重建，验证码过期后没有价值；而账户余额不能只放在 Redis。Memcached 更简单，适合纯缓存和大规模横向扩容，不适合需要列表、集合、发布订阅或持久化的场景。

3. 文档、图、目录与无代码数据库：模型随业务而变（MongoDB，Neo4j）

• MongoDB：文档型数据库，以 BSON/JSON 文档为中心，字段可逐步演进。适合商品属性、CMS 内容、用户行为事件等结构差异较大的数据。需要跨文档强事务、严格外键和复杂联表时，关系型数据库通常更稳妥。
• Neo4j：图数据库，用节点、关系和属性表达数据，擅长多跳遍历，例如“朋友的朋友”“设备经过哪些网关”“某个风险账户关联了哪些主体”。如果主要查询是按主键取一行，使用图数据库会增加不必要的复杂度。
• NocoDB：无代码数据库平台，把表格界面、权限和 API 叠加在底层数据源上。它适合内部管理台、项目协作和原型验证，价值在于快速让非研发人员维护数据；它不是自动替代 MySQL/PostgreSQL 的高并发交易内核。
• OpenLDAP：LDAP 协议的开源目录服务，数据通常是层级化的 DN、组织、用户和组。适合统一认证、通讯录和组织架构查询；它的查询和更新模型与业务数据库不同，不应用来存订单明细。

4. 时间序列与监控数据库：时间是第一索引（InfluxDB，TDengine，Prometheus）

时间序列库的共同点是写入通常按时间追加，查询常见“最近一小时平均值”“按设备聚合”。不要把每个用户 ID、请求 ID 都当作标签，否则标签基数会爆炸。Prometheus 的instance、pod等标签适合监控维度，但用户行为明细更适合日志系统或分析型数据库。

5. 列式分析和 MPP：让聚合扫描跑得快（ClickHouse，StarRocks）

• ClickHouse：列式存储、压缩率高、向量化执行，适合埋点、日志、广告和财务报表的海量聚合。它对批量写入和追加友好，对频繁单行更新、复杂事务和强外键约束不友好。
• StarRocks：新一代极速全场景 MPP 数据库，强调实时数仓、联邦查询和高并发分析。适合需要较低延迟报表、明细加聚合混合查询的场景。上线前应按数据导入方式、分区、分桶和并发模型做压测。

ClickHouse 和 StarRocks 都能做分析，但不能只凭基准分数选择。数据是否持续更新、是否需要多表关联、查询并发和运维团队经验，往往比单次扫描速度更重要。常见做法是：事务库保存事实，CDC 或消息队列把变更同步到 OLAP，再由 OLAP 服务报表。

6. 搜索与向量数据库：为“找得准、找得快”建索引（Elasticsearch，Typesense，VexDB）

搜索索引通常是主库的派生数据。正确流程是“先写主库，再通过 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

常见场景的推荐组合

一个可落地的电商数据架构

浏览器 / 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;UPDATEinventorySETavailable=available-1WHEREsku_id=1001ANDavailable>0;-- 检查受影响行数为 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, ttl=300s) return value 更新： db.transaction(update) cache.delete(key) # 删除而不是直接写缓存，减少并发覆盖

需要额外防护缓存击穿、缓存穿透和雪崩：热点 key 加互斥锁或 singleflight；不存在的数据写入短 TTL 的空值；TTL 增加随机抖动并准备限流和降级。分布式锁要设置过期时间、唯一 token 和释放校验，不能把SETNX当成完整的锁服务。

搜索、分析和向量：明确“最终一致”

主库提交事务 → 可靠消息/CDC → 搜索索引或 OLAP 导入 → 记录 offset 和失败原因 → 可重放、可校验、可重建

搜索索引要有全量重建方案，OLAP 表要有分区和数据校验，向量索引要记录模型版本。任何派生库都应能从主库或原始事件重新生成，否则数据损坏后只能人工修复。

运维检查清单

常见问答

问：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。

最后可以用一句话复盘选型：数据的事实在哪里，最常见的查询是什么，允许多大的一致性延迟，预计如何扩容，团队能否长期运维？能回答这五个问题，数据库类型通常已经确定；具体产品则交给兼容性验证、容量压测和故障演练来决定。