直奔主题，一图胜千言。
存算分离的背景
存储和计算的边界其实是不清晰的，计算过程中计算和存储实际上是分离不开的，不过网络带宽和性能提升的当下，提供了一定程度分离的讨论基础。
讨论的前提：“存储”是需要持久化的东西，计算”就是计算过程需要的CPU和内存等。
移动数据->移动计算之后的再思考：存算分离。
为什么要计算和存储分离
不是一个全新的名词，NAS就是某种形式上来说，最早的存算分离。
谷歌GFS “移动计算到数据的观念”，带来新的计算和存储耦合方式。计算和存储融合的架构也出现了机器资源浪费的新方式：
无论是计算先达到瓶颈，还是存储先达到瓶颈，两种状况虽然不同，时间点也不一致。但通常不管那种情况都是加机器，因此就会存在不少浪费。
扩展不容易：计算和存储耦合模式下，存储扩展通常迁移大量数据，不方便。
谁在使用计算和存储分离： 数据库和消息队列
一个是数据库，另一个是消息队列。
数据库存储引擎存算分离：数据库2014年AWS首次推出了Aurora，阿里在2017年推出了PolarDB，华为云在2020年推出了GaussDB for MySQL，华为存储也在2021年针对企业自建数据中心，推出OceanData分布式数据库存算分离方案。
消息队列存储引擎的存算分离： 不管是Kafka仍是RocketMQ其设计思想都是利用本地机器的磁盘来进行保存消息队列，但也存在弊端：可保存的数据量有限，通常只保存最近几天的消息。目的是节约存储空间，可是可能就会导致追溯一些历史数据的时候没法查询。扩展成本高，和在数据库中的情况类似。
存算分离的两面性
存算分离的好处：资源优化：解决数据快速移动，实现计算、存储弹性扩展，按需分配【按需/弹性】
存算分离的挑战： 目前的存算分离基本都是在云原生数据库和消息队列上下文中讨论的，依赖其自身的存储引擎实现，没有统一计算框架，实现也是五花八门。如何管理计算层和存储的映射关系；计算层和存储层通信传输开销和异常处理；读写一致性等都面临工程上的挑战。
以上，都是个人不成熟的看法，是我基于已知信息作出的“有限理性”判断。如有异议，你是对的。如觉有益，请帮助转发或者点个“在看”，让更多人看到。
