传统关系型数据库（RDBMS）经过数十年工程实践检验，在事务一致性保障、SQL 表达力、工具生态等方面建立了难以替代的优势。然而，当现代应用场景向 HTAP 混合负载、向量语义检索、高频时序写入等方向演进时，传统架构的设计假设正面临根本性挑战。本文从架构层面剖析限制所在，并给出可操作的工程权衡框架。
一、OLTP 与 OLAP 的资源竞争困境
传统 RDBMS 的核心优化目标是将短查询、低延迟的写入事务与大规模扫描的分析查询分离执行。这一设计在纯 OLTP 或纯 OLAP 场景下效率出色，但当两者混合运行时，资源竞争成为首要瓶颈。事务处理需要行式存储的随机读写能力与严格的锁机制，而分析查询更依赖列式压缩与批量扫描。当两类负载共存于同一数据库引擎时，CPU 与 I/O 资源会在查询规划阶段产生激烈争夺 —— 长耗时分析查询会阻塞事务路径，反之，高频写入也会导致分析查询的缓冲区频繁失效。
工程实践中，常见的妥协方案是为 OLTP 配置主从复制架构，将只读分析查询导向备库。这种方式虽能缓解争用，但引入了数据复制延迟，且备库的查询无法看到最新事务结果。对于需要实时数据分析的场景，复制延迟往往成为业务硬伤。
二、模式刚性与水平扩展的天然矛盾
关系型数据库强制执行固定模式（Schema），这在事务型业务中提供了数据完整性保障，却与现代应用的快速迭代需求产生摩擦。业务需求频繁变动时，模式迁移涉及表结构变更与全量数据重写，在大表场景下成本极高。复杂 JOIN 操作在高度规范化的表结构中性能优异，但当数据规模突破单机存储上限时，跨节点 JOIN 的网络开销与分布式事务的协调成本急剧上升。
水平扩展能力是传统 RDBMS 的另一软肋。尽管现代云数据库通过分库分表实现了逻辑水平扩展，但分布式事务的 ACID 保障与跨分片查询优化仍依赖复杂的中间件层，增加了运维复杂度与故障排查难度。许多团队最终被迫在应用层实现数据路由逻辑，将数据库的透明性优势消耗殆尽。
三、向量检索的场景错配与集成路径
向量检索是 AI 应用的核心能力，传统 RDBMS 在此领域的支持极为有限。高维向量数据的相似度搜索依赖近似最近邻（ANN）索引，而传统 B 树索引对此类查询几乎无效。即使通过扩展插件（如 pgvector）引入向量索引，其性能也难以与专用向量数据库比拟 —— 在百万级向量规模下，查询延迟与吞吐量通常存在数量级差距。
向量检索与传统 SQL 查询的混合场景带来了额外挑战：需在事务一致性保障下完成向量相似度计算与属性过滤的联合查询。传统 RDBMS 的执行器未针对此类混合负载优化，往往将向量搜索结果回传给应用层后再做 JOIN，产生了大量无效数据传输。
工程团队的典型应对策略分为三派：一是坚持使用专用向量数据库（Milvus、Pinecone 等），通过数据同步机制与主数据库保持一致；二是采用具备向量能力的现代化 HTAP 数据库（如 TiDB、ClickHouse），以架构统一换取运维简化；三是利用 pgvector 等插件实现轻量级向量搜索，接受一定性能损失以换取单一数据库的运维便利。选择哪条路径，取决于业务对查询延迟的容忍度与团队运维多系统的成本承受力。
四、时序数据的写入放大与存储成本
时序数据场景（如监控指标、IoT 传感器、金融行情）的特征是写入远多于查询，且数据具有明显的时间局部性。传统 RDBMS 的行式存储在持续高频写入时面临严重的页分裂与索引维护开销，每秒数万次写入即可导致 B 树索引的性能退化。压缩效率低下是另一问题：时序数据的时间戳高度重复，传统行式存储无法利用这一特性实现高效压缩，导致存储成本随数据留存周期线性增长。
分区表（Partitioning）是当前主流的缓解手段，通过按时间范围将大表拆分为物理子表，实现写入与查询的局部化。但分区策略需要预先规划，分区数量过多会增加元数据开销，分区过少则无法有效分散负载。更关键的是，跨分区的时间范围查询仍需扫描多个分区，查询性能随时间跨度恶化。
专用时序数据库（TimescaleDB、InfluxDB）通过列式存储、向量化执行、自动化分区等机制在此场景建立了显著优势。若业务强依赖关系型 SQL 语法与既有事务能力，可考虑 TimescaleDB 这类在 PostgreSQL 基础上扩展的混合方案；若性能瓶颈无法容忍，则需评估向专用 TSDB 迁移的迁移成本与数据一致性保障。
五、架构选型的工程决策框架
面对上述局限，工程团队不应盲目追逐新锐技术，而应基于具体业务负载特征做出理性决策。以下决策矩阵可作为初步筛选工具：
| 业务特征 | 推荐架构 | 关键参数 |
|---|---|---|
| 纯 OLTP + 有限报表 | 优化型 RDBMS + 只读备库 | 备库复制延迟 < 1 秒 |
| HTAP 混合负载 + 实时性要求高 | HTAP 数据库（TiDB/ClickHouse） | 查询延迟 < 500ms |
| 向量检索为核心 + 规模大 | 专用向量库 + 主 DB 同步 | 同步延迟可接受 < 5 秒 |
| 时序写入量 > 10 万条 / 秒 | 专用 TSDB 或列式引擎 | 压缩比 > 10:1 |
需要强调的是，架构不存在银弹。引入 HTAP 数据库意味着接受更复杂的运维体系与潜在的学习曲线；选用专用向量库则需解决跨系统数据一致性问题。工程团队应优先进行小规模原型验证，在真实负载下测量延迟与吞吐量指标，而非依赖供应商的基准测试数据做决策。
传统 RDBMS 的架构局限并非技术缺陷，而是设计年代与目标场景的必然结果。在选择拥抱新技术还是坚守成熟方案时，唯一可靠的判断依据是业务当前与可预见的负载特征，以及团队对系统复杂度的承载能力。
资料来源：本文技术要点参考 ArXiv 关于 HTAP 数据库的综述研究，以及 Hacker News 社区对数据库架构限制的讨论。