在数据库和大数据领域，“存储计算一体化”和“存储计算分离”的架构之争从未停止。有人质疑“存储计算分离真的有必要吗？本地磁盘性能不够吗？”答案并非非黑即白，技术选型的关键在于业务场景与资源需求的精准匹配。本文以Apache Doris为例，分析两种架构的本质差异、优缺点及实施场景。

存储计算一体化与存储计算分离

存储计算一体化：紧密耦合的“全能选手”

定义：数据存储和计算资源绑定在同一节点（如本地磁盘 + 服务器），利用本地读写减少网络开销。典型例子包括早期 Hadoop 架构和传统 OLTP 数据库。
历史起源：在 IT 系统早期，数据量小（如 20 世纪 60 年代的 IBM 大型机），单台机器能满足存储和计算需求，自然形成存储计算一体化架构。

存储计算分离：解耦的“完美搭档”

定义：存储层（如对象存储、HDFS）和计算层（如云服务器、容器集群）可独立扩展并通过高速网络连接实现数据共享。典型代表包括云原生数据库 Snowflake 和Doris的存储计算分离模式。
驱动因素：数据量的指数增长、云计算的弹性需求和精细的成本控制。

架构对决：性能、成本和弹性的终极博弈

存储计算一体化的优缺点

优点

• 部署简单：无需依赖外部存储系统，可在单机上运行，适合快速试验或中小规模场景（如 Doris 的存储计算一体化模式只需部署 FE/BE 进程）。

• 性能极致：本地读写减少网络延迟，适合高并发低延迟场景。（如在 YCSB 场景中，Doris 的存储计算一体化可达到 30000 QPS，99 百分位延迟低至 0.6ms）

  缺点

• 扩展不灵活：存储和计算需同时扩展，可能导致资源浪费（如 CPU 空闲而磁盘已满）。
• 成本高：本地 SSD 磁盘价格高，冗余备份增加硬件投入（如 Doris 的存储计算一体化版本需三份以确保高数据可靠性）。

存储计算分离的突破与挑战

优点

• 弹性扩展：计算资源可按需扩展，存储可独立扩容（如 Doris 的计算组可动态增减节点）。
• 成本优化：共享存储（如对象存储）成本低至本地磁盘的 1/3，支持冷热数据分层管理。

• 高可用性：存储层有独立的灾难恢复，计算节点故障时无数据丢失风险。

  挑战

• 网络瓶颈：远程读写可能引入延迟（依赖智能缓存优化）。
• 运维复杂：需要管理共享存储（如 HDFS、S3）和网络稳定性。

场景决定：如何选择最适合的架构？

存储计算一体化的“主战场”

• 中小规模实时分析：数据量在 TB 级别以内，追求低延迟（如 Doris 的高并发查询场景）。
• 独立业务线：无专职 DBA 团队，要求简单运维（如初创企业尝试数据分析）。
• 不依赖云环境：本地化部署，无可靠共享存储资源。

存储计算分离的“杀手锏场景”

• 云原生和弹性需求：在公有云/混合云环境，按需付费（如 Doris 的云原生版本支持 K8s 容器化）。
• 大规模数据湖仓库：PB 级数据存储，多个计算集群共享同一数据源（如金融风控、电商用户画像）。
• 成本敏感业务：归档历史数据，低成本存储冷数据（如 Doris 的冷热分层技术）。

Doris 的实践见解：能否鱼与熊掌兼得？

作为新一代实时分析数据库，Apache Doris 支持存储计算一体化和存储计算分离模式，成为架构灵活性的标杆：

存储计算一体化模式

适用场景：开发测试、中小规模实时分析。

存储计算分离模式

技术亮点

• 共享存储：支持 HDFS/S3，将主数据存储与计算节点解耦。
• 本地缓存：BE 节点缓存热数据以抵消网络延迟。

结论：没有绝对最优，只有最适合的匹配

存储计算分离不是“万能药”，存储计算一体化也不是“过时产品”。技术决策应回归业务本质：

• 选择存储计算一体化：对性能敏感、数据规模可控、运维资源有限时。
• 拥抱存储计算分离：当成本和弹性是核心需求且有云原生技术栈时。
  未来，随着存储网络（如 RDMA）和智能缓存技术的突破，存储计算分离的“性能天花板”将进一步被打破。Doris 等开源技术的不断演进为这场架构之争提供了更多可能性。