- 综合排序
- 最热优先
- 最新优先
- 来自专栏咖啡拿铁
聊聊计算和存储分离
“计算和存储分离” 2.何为计算？ ，所以我们的计算和存储分离其实是一个伪需求，当然在未来的某一天如果我们的网络传输的时间可以忽略不计，计算和存储分离也就能真正的实现了。 3.为何需要计算和存储分离 计算和存储分离并不是现在才出现的一个新名词，在20年前就有NAS-网络附加存储这个东西，本质上也就是使用TCP/IP协议的以太网文件服务器。 由于计算和存储耦合的缺点越来越多，并且网络速度越来越快，现在架构又在重新向计算和存储分离这一方向重新开始发展。 4.谁在使用计算和存储分离 上面我们讲了很多理论相关的知识，相信大家已经对“计算和存储分离”已经有一定的认识了,那么其到底在哪些地方做了使用呢？
5.1K11发布于 2020-02-17 - 来自专栏沃趣科技
容器化RDS｜计算存储分离 or 本地存储
数据库服务的需求可以简化为: 实现数据零丢失的前提下,提供可接受的服务能力 因此存储架构的选型至关重要. 到底是选择计算存储分离还是本地存储? 回顾 : 计算存储分离, 本地存储优缺点 还是从计算存储分离说起, 计算存储分离 先说优点 : ●架构清晰 ●计算资源 / 存储资源独立扩展 ●提升实例密度, 优化硬件利用率 ●简化实例切换流程 本地存储 如果在意计算存储分离架构中提到的缺点, 本地存储可以有效的打消类似顾虑, 无需引入分布式存储, 避免Storage Verdor Lock In 风险, 所有问题都由DBA 闭环解决,. 性能对比3 : 本地存储 / 计算存储分离 为了对比本地存储和计算存储分离, 专门使用 MGR + 本地存储架构 和 基于分布式存储的计算存储分离架构做性能对比. 我们已有计划实现满足生产环境的 ●Docker + Kubernetes + PXC ●Docker + Kubernetes + MGC ●Docker + Kubernetes + MGR 并集成到 QFusion 来支持计算存储分离架构和本地存储架构混合部署
10.1K80发布于 2018-03-21 - 来自专栏鸿的学习笔记
计算应该与存储分离吗？
，计算与存储应该分离吗？ 注意，本文不牵扯到具体的技术细节和代码，要是被读者发现了有错误，请大胆指出。 计算与存储的关系 在聊计算与存储分离这个话题，先来看看计算与存储的关系。计算机语言中的计算和存储其实来源于数学。 计算与存储的探索 第一个搞出计算与存储分离的自然是 Hadoop 和其对应的数据分析领域。 有了论文和实际的产品，各种云厂商和开源数据库一拥而上，把计算与存储的概念发挥的淋漓尽致，终于形成了计算与存储分离的潮流。 读者感兴趣的话，可以拿 TiDB 和 CockroachDB 做一下严格的比较，而不是纯看论文和“宣传”文章，这样也能更好的理解计算与存储分离这个话题。
2.6K10发布于 2020-04-23 - 来自专栏MySQLBeginner
容器化RDS｜计算存储分离 or 本地存储？
因此存储架构的选型至关重要。到底是选择计算存储分离还是本地存储？ 本文就这个问题，从以下几点展开： 回顾：计算存储分离, 本地存储优缺点 MySQL 基于本地存储实现数据零丢失 性能对比 基于 Docker + Kubernetes 的实现 来分享个人理解。 回顾：计算存储分离，本地存储优缺点 ? 还是从计算存储分离说起。 计算存储分离 ? 性能对比3：本地存储 / 计算存储分离 为了对比本地存储和计算存储分离，专门使用 MGR + 本地存储架构和 基于分布式存储的计算存储分离架构做性能对比。 我们已有计划实现满足生产环境的： Docker + Kubernetes + PXC Docker + Kubernetes + MGC Docker + Kubernetes + MGR 并集成到 QFusion 来支持计算存储分离架构和本地存储架构混合部署
4K22发布于 2019-04-24 - 来自专栏腾讯云技术沙龙
尚博：CynosDB 计算存储分离架构的实现和优化
今天跟大家分享一下CynosDB for MySQL计算存储分离架构的实现和优化。 计算与存储分离架构，不仅在性能、扩展性和高可用方面有大幅提升，而且架构的解耦使得计算层和存储层都获得了很大的优化空间，接下来主要讲一下CynosDB架构的实现，以及在新架构上做了哪些方面的优化。 CynosDB则引入计算存储分离的架构，存储层使用共享的分布式块存储云服务，计算层则将不必要的IO全部卸载，实现计算与存储基于日志传输的新架构。 基于这三个特点，我们能获得很大的收益，比如数据的高可用，其实大部分是来自底层高可用的分布式存储；其次是扩展性，如无状态备机计算节点的启动和故障切换是非常快的，可以在5-15秒之内完成；最后，架构卸载掉很多很重的模块和机制 CynosDB计算层的恢复将变得无比简单，仅仅需要获取一个VDL即可，存储层的恢复过程和计算层是并行且异步进行的，和传统架构中恢复必须先完成才能进行事务回滚不同，CynosDB在获得VDL之后即刻进行事务回滚
2.4K21发布于 2019-03-27 - 来自专栏Hadoop集群运维-大数据平台运维实战
为什么说存储和计算分离的架构才是未来
为了解决数据的快速访问，Google 创造性地提出来了计算和存储耦合的架构，在同一个集群中实现计算和存储功能，并将计算的代码移动到数据所在的地方，而不是将数据传输到计算节点，有效解决了分散在各个弱连接的存储节点间的海量数据访问的困难 在数据本地化优化得很好的大数据计算集群中，大量网络带宽是闲置的，而因为存储和计算耦合在一个集群中，带来了一些其它问题： 在不同的应用或者发展时期，需要不同的存储空间和计算能力配比，使得机器的选型会比较复杂和纠结 后来 Facebook 就逐渐往计算和存储分离的架构迁移，也对所用的大数据软件做了些调整以适应这种新的架构，他们在今年的 Apache Spark & AI Summit 上做了主题为 Taking Advantage 针对公有云设计的大数据分析服务 Databricks 一开始就是采用了计算和存储分离的架构（直接使用 S3 作为存储），给产品带来了非常大的灵活性，按需创建和自动弹性伸缩的 Spark 集群是一大卖点（ 因为网络的高速发展，以及大数据计算框架对 IO 的优化，使得数据本地化已经不再重要，存储和计算分离的架构才是未来。
75421编辑于 2022-06-07 - 来自专栏CNCF
京东Elasticsearch使用ChubaoFS实现计算存储分离
此类日志化场景对写要求很高，查询性能及高可用等要求相对较低，大的业务写会达到数千万 / 秒，存储以 PB 为单位来计算。 ChubaoFS 是京东自研的、为云原生应用提供高性能、高可用、可扩展、 稳定性的分布式文件系统，设计初衷是为了京东容器集群提供持久化存储方案，同时也可作为通用云存储供业务方使用，帮助有状态应用实现计算与存储分离 基于这种假设以及对提高磁盘使用率的迫切需要，我们考虑引入了公司内部部署的 ChubaoFS 作为存储，将 Elasticsearch 作为无状态的实例进行存储计算分离。 Twitter：@ChubaoFS Mailinglist: chubaofs-maintainers@groups.io Slack: chubaofs.slack.com 作者简介： 王行行，京东零售计算存储平台架构部架构师 张丽颖：CNCF Ambassador，京东零售计算存储平台产品经理， 开源项目 ChubaoFS 的 contributor。
2.5K30发布于 2020-03-04 - 来自专栏大数据动态
从Snowflake看数据仓库演进方向：计算存储分离、弹性计算、统一存储和Serverless化
其次计算存储不分离，无法对计算资源进行有效复用。因此长期来看，大数据分析技术演进的方向一定是：支持数据实时处理、计算存储分离、Serverless 化、高性能低成本的数据仓库服务才能赢得未来。 2）存储计算分离 在云的环境下，网络传输能力已经超过本地磁盘的 IO 能力，存储计算分离带来的好处是存储量一定的情况下通过横向扩展计算可以带来更好的性能 ，同时在计算低峰的时候通过云的弹性能力进行扩缩容带来数据分析计算成本的进一步降低 3）按需付费 相比自建 IDC，云的最大优势是资源分钟级交付，最大程度降低硬件成本，企业用户可以根据实际计算量和存储量进行按需付费。 5）极致性能 基于云基础设施，在计算存储分离的模式下还必须保证现代数据架构下的零性能损失，性能的保证即是成本降低的保证。 总体趋势就是：计算存储分离、弹性计算、统一存储以及 Serverless 化。 InfoQ：在您看来，当前大数据计算引擎和存储分别处于什么样的发展阶段？为什么？
1.5K41发布于 2021-01-08 Pulsar存储计算分离架构设计之存储层BookKeeper（上）
一、前言 我们上文说过，Apache Pulsar 采用了一种典型的"存储计算分离"架构设计：消息内容持久化存储在 BookKeeper 分布式日志存储系统中，集群元数据由 ZooKeeper 协调服务统一管理 （当然2.10.0版本移除了ZK是题外话了），而 Broker 节点则专注于消息的路由、协议转换等计算密集型任务，完全解耦了存储与计算功能。 上一篇文章我们说了Broker无状态，这一篇我们来聊聊"存储计算分离"中的存储——BookKeeper。 索引分离：Entry Log 存储数据，RocksDB 独立存储 Ledger 和 Entry 的索引。 整个设计通过职责分离（内存操作与磁盘IO分离）和资源复用机制，在保证数据持久化的同时兼顾系统性能。
27310编辑于 2025-11-19Pulsar存储计算分离架构设计之存储层BookKeeper（下）
我们接着上一篇Pulsar存储计算分离架构设计之存储层BookKeeper（上） 继续讲： 六、Bookie的数据读取流程 我们继续跟着上一篇的server端的源码分析上来，直接看 org.apache.bookkeeper.proto.BookieRequestProcessor （可压缩账本存储） 含义：支持垃圾回收和压缩操作的账本存储抽象类 使用场景：需要定期清理过期数据的存储场景 SortedLedgerStorage（排序账本存储） 含义：基于排序索引的账本存储实现 使用场景 SlowSortedLedgerStorage（慢速排序账本存储） 含义：模拟慢速存储的排序账本存储实现，用于测试 使用场景：排序存储相关的性能测试、系统稳定性和容错性验证 八、存储层BookKeeper 但混合存储的特性导致其难以支持单个Topic的顺序读取和消息回溯，存在显著的读放大问题。 Bookie同时支持RocksDB（Pulsar默认选用）和自研KV引擎存储该映射，通过用户态缓存（优于PageCache）降低容器化环境中多POD间的IO干扰，确保读写性能稳定。
16010编辑于 2025-11-19- 来自专栏大数据成神之路
ClickHouse存储计算分离在腾讯云的实践
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
2.8K20发布于 2021-04-21 - 来自专栏腾讯云大数据
从Snowflake看数据仓库未来演进方向：计算存储分离、弹性计算、统一存储和Serverless化
其次计算存储不分离，无法对计算资源进行有效复用。因此长期来看，大数据分析技术演进的方向一定是：支持数据实时处理、计算存储分离、Serverless 化、高性能低成本的数据仓库服务才能赢得未来。 2）存储计算分离 在云的环境下，网络传输能力已经超过本地磁盘的 IO 能力，存储计算分离带来的好处是存储量一定的情况下通过横向扩展计算可以带来更好的性能 ，同时在计算低峰的时候通过云的弹性能力进行扩缩容带来数据分析计算成本的进一步降低 3）按需付费 相比自建 IDC，云的最大优势是资源分钟级交付，最大程度降低硬件成本，企业用户可以根据实际计算量和存储量进行按需付费。 5）极致性能 基于云基础设施，在计算存储分离的模式下还必须保证现代数据架构下的零性能损失，性能的保证即是成本降低的保证。 总体趋势就是：计算存储分离、弹性计算、统一存储以及 Serverless 化。 InfoQ：在您看来，当前大数据计算引擎和存储分别处于什么样的发展阶段？为什么？
1.5K20发布于 2020-11-30 - 来自专栏CloudBest
云数据仓库的未来趋势：计算存储分离
而通过分离存储资源、计算资源，可以独立规划存储、计算的资源规格和容量。这样计算资源的扩容、缩容、释放，均可以比较快完成，并且不会带来额外的数据搬迁的代价。 存储、计算也可以更好的结合各自的特征，选择更适合自己的资源规格和设计。 6 性能测试 本节将探究计算存储分离架构对AnalyticDB大数据量分析场景的查询吞吐影响。 测试环境 实例1：不分离模式，4组存储节点，存储节点负责数据扫描、查询计算。 粗看这个结果比较惊讶，计算存储分离后，性能更好了。我们可以仔细分析下，弹性模式与不分离模式具有相同的存储节点数，确保分离模式存储节点不会成为瓶颈。 对于计算层来说，只要存储层能够提供足够的数据吞吐，确保计算层的CPU能够打满，那么计算存储分离不会降低查询的处理吞吐，当然相比于不分离模式，会多消耗资源。
3.2K40发布于 2021-07-13 - 来自专栏公有云大数据平台弹性 MapReduce
看云上 ClickHouse 如何做计算存储分离
计算存储不分离 目前 ClickHouse 存储和设备强绑定，虽然支持 s3、hdfs 等外部存储，但是其核心存储引擎 mergetree并不能使用。 腾讯云云数仓 ClickHouse 计算存储分离实现 接下来我们看腾讯云云数仓 ClickHouse 计算存储分离实现，要实现 ClickHouse 的计算存储分离，我们首先来看 ClickHouse 通过规避 rename 大大的提高了数据写入和合并的速度，那在实现 ClickHouse 支持云存储后，我们来 看如何应用这些特性来达到数据自动沉降和存储计算分离。 ，我们在看另一种计算存储完全分离的场景。 总体技术架构上采用共享存储的架构设计，通过计算存储分离重复利用云的弹性能力，和无限存储扩 展能力，下面是目前腾讯云 ClickHouse 的一个产品截图： 16.png 在监控方面提供了从 IAAS 基础设计到
3.1K71发布于 2021-01-05 - 来自专栏腾讯云大数据
看云上 ClickHouse 如何做计算存储分离
计算存储不分离 目前 ClickHouse 存储和设备强绑定，虽然支持 s3、hdfs 等外部存储，但是其核心存储引擎 mergetree并不能使用。 腾讯云云数仓 ClickHouse 计算存储分离实现 接下来我们看腾讯云云数仓 ClickHouse 计算存储分离实现，要实现 ClickHouse 的计算存储分离，我们首先来看 ClickHouse 通过规避 rename 大大的提高了数据写入和合并的速度，那在实现 ClickHouse 支持云存储后，我们来 看如何应用这些特性来达到数据自动沉降和存储计算分离。 ? ，我们在看另一种计算存储完全分离的场景。 总体技术架构上采用共享存储的架构设计，通过计算存储分离重复利用云的弹性能力，和无限存储扩 展能力，下面是目前腾讯云 ClickHouse 的一个产品截图： ?
4.1K30发布于 2020-12-11 Pulsar存储计算分离架构设计之消息副本同步和故障转移机制
一、前言 我们继续来讲Pulsar存储计算分离架构设计系列，这篇我们来说说消息副本和故障转移机制。 Apache Pulsar通过多副本存储和智能故障转移机制，构建了多层次容错体系：其基于BookKeeper的持久化存储层采用多副本（通常3副本）机制，将消息数据分散存储在独立的Bookie节点上，通过 这种存储与计算解耦的架构设计，使Pulsar既能避免单点故障导致的数据丢失，又能实现业务无感知的故障恢复，特别适合金融交易、物联网等对可靠性要求严苛的场景。 三、核心操作时序图 Pulsar消息副本和故障转移机制的核心流程如下： 消息发布与本地存储：客户端向本地 PersistentTopic 发布消息，消息首先被持久化存储到本地 ManagedLedger 该方法首先通过 getAvailablePermits() 计算当前可读取的消息数量，考虑了生产者队列容量和限流设置等因素。
20010编辑于 2025-11-19- 来自专栏CSDN技术头条
容器化RDS｜计算存储分离架构下的IO优化
在基于 Kubernetes 和 Docker 构建的私有 RDS 中，普遍采用了计算存储分离架构。 计算存储分离架构 架构示意图如下： ? 存储层由分布式文件系统组成，以 Provisoner 的方式集成到 Kubernetes。 在我们看来，计算存储分离的最大优势在于： 将有状态的数据下沉到存储层，这使得 RDS 在调度时，无需感知计算节点的存储介质，只需调度到满足计算资源要求的 Node，数据库实例启动时，只需在分布式文件系统挂载 其实还有一个极其重要的问题，由于kubernetes 本身没有提供 Voting 服务和类似 Oracle Rac 的 Fence 机制，在计算存储分离架构下，当集群发生脑裂，并触发 Node Controller 原文地址：http://blog.mariadb.org/mariadb-introduces-atomic-writes/ 计算存储分离架构：关闭 DoubleWrite 所以，重点是我们需要测试一下在计算存储分离架构下
1.6K60发布于 2018-02-06 - 来自专栏沃趣科技
容器化RDS｜计算存储分离架构下的 IO 优化
在基于 Kubernetes 和 Docker 构建的私有 RDS 中，普遍采用了计算存储分离架构。 计算存储分离架构 架构示意图如下： ? 存储层由分布式文件系统组成，以 Provisoner 的方式集成到 Kubernetes. 在我们看来, 计算存储分离的最大优势在于： 将有状态的数据下沉到存储层，这使得 RDS 在调度时，无需感知计算节点的存储介质，只需调度到满足计算资源要求的 Node，数据库实例启动时，只需在分布式文件系统挂载 计算存储分离架构的缺点 俗话说的好： 上帝为你关上一扇窗的同时，再关上一扇门。 如下图所示 ? 其实还有一个极其重要的问题，由于kubernetes 本身没有提供 Voting 服务和类似 Oracle Rac 的 Fence 机制，在计算存储分离架构下，当集群发生脑裂，并触发 Node Controller
1.5K40发布于 2018-03-26 - 来自专栏IT大咖说
容器化RDS｜计算存储分离架构下的 IO 优化
摘要 在基于 Kubernetes 和 Docker 构建的私有 RDS 中，普遍采用了计算存储分离架构。 计算存储分离架构 架构示意图如下： ? 存储层由分布式文件系统组成，以 Provisoner 的方式集成到 Kubernetes. 在我们看来, 计算存储分离的最大优势在于： 将有状态的数据下沉到存储层，这使得 RDS 在调度时，无需感知计算节点的存储介质，只需调度到满足计算资源要求的 Node，数据库实例启动时，只需在分布式文件系统挂载 计算存储分离架构的缺点 俗话说的好： 上帝为你关上一扇窗的同时，再关上一扇门。 如下图所示 ? 其实还有一个极其重要的问题，由于kubernetes 本身没有提供 Voting 服务和类似 Oracle Rac 的 Fence 机制，在计算存储分离架构下，当集群发生脑裂，并触发 Node Controller
1.3K80发布于 2018-04-04 - 来自专栏深度学习与python
作业帮检索服务基于 Fluid 的计算存储分离实践
通过对检索系统运行和数据更新流程的分析，当前面临的关键问题是由于计算和存储的耦合所带来的，因此我们考虑如何去解耦计算和存储，只有引入计算存储分离的架构才能够从根本上解决复杂度的问题。 计算存储分离最主要的就是将每个节点存储本分片全量数据的方式拆分开，将分片内的数据存储在逻辑上的远程机器上 但是计算存储分离又带来了其他的问题，比如稳定性问题，大数据量下的读取方式和读取速度，对业务的入侵程度等等问题 2计算存储分离架构解决复杂度问题 为了解决上述计算存储分离所需要考虑的问题，新的计算存储分离架构必须能达到以下目标： 1、读取的稳定性，计算存储分离终究是通过各种组件配合替换掉了原始文件读取，数据加载方式可以替换 5落地实践 1、缓存节点和计算节点的分离: 虽然使用 fuse 和 worker 结合部署可以获得更好的数据本地性能，但是在在线场景下，我们最终选用了缓存和计算节点分离的方案，原因是通过延长一定的启动时间换来更优的弹性是值得的 7展望 计算和存储分离的模式使得以往我们认为非常特殊的服务可以被无状态化，可以像正常服务一样被纳入 devops 体系中，而基于 Fluid 的数据编排和加速系统，则是实践计算和存储分离的一个切口，除了用于检索系统外
77310编辑于 2021-12-13
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号