企业在进行IT基础设施建设时，基本都会面临一道选择题，到底是存算分离架构还是存算一体架构？更具体的来说，在进行云化的IT基础设施建设时，是用超融合架构好？还是计算和分布式存储分离的架构更好？
在回答这个问题之前，我们首先明确存算分离和存算一体都是基于存储层是“分布式”共享存储的架构进行讨论，而计算节点则是直接使用本地盘来运行业务的情况，这个不属于完整意义上的云化架构，没有相同场景上的可对比性。
我们来看一个实际的客户需求，该需求是要用一个统一的数据库承载平台来实现如下目标：
1、由于核心系统的数据库是Oracle RAC，暂时未进行国产化替换，所以还需要在新平台上承载该套数据库，数据量大约为10TB。稳定可靠、高性能是该套数据库的承载要求。该套数据库需要用物理机来运行。
2、一套2节点Oracle RAC承载着数据仓库EDW，数据量大约为80TB。需要非常高的存储性能和计算性能。该套数据库需要用物理机来运行。
3、一套重要的系统完成了信创改造，使用的是达梦数据库，由于比较重要，所以还是希望用更稳定可靠，性能好的物理机来运行。
4、部分相对重要的MySQL数据库，使用主从+HAProxy+VIP的高可用架构，但是数据量相对较小且负载不高。
5、还有一些数据库，包括openGauss、Kingbase、MySQL等，承载了边缘的业务系统，负载不高，数据量不大（50GB-500GB之间），业务连续性要求不高，但也需要主机级别的高可用，若主机故障后，需要在10分钟之内在其他主机上把数据库拉起来。
6、基于信创和国产化要求，服务器的硬件配置，在满足业务需求的基础上，需要尽可能使用国产CPU服务器。
要满足上述需求，一套“存算分离”的多元数据库承载平台就可以实现，部署架构如下：
1、核心系统Oracle RAC和数据仓库EDW的Oracle RAC运行在物理机上。核心系统Oracle RAC运行在海光物理服务器上，而由于EDW系统数据库需要有足够多的CPU计算能力，所以该套数据库使用了4路Intel CPU的物理服务器来运行。
2、重要系统的达梦数据库运行在海光CPU的物理机上。
3、相对重要但负载不高的MySQL运行在虚拟机上（宿主物理机是海光服务器），并通过主从架构实现更高的业务连续性。
4、边缘系统的数据库如openGauss，Kingbase运行在虚拟机上（宿主物理机是海光服务器），通过虚拟机来实现多套数据库整合，节省资源。如果计算节点出现故障，虚拟机可以漂移到其他计算节点上拉起，而数据库的数据由于是在分布式存储上，数据不会丢失。
5、为满足EDW业务的大容量（80TB）和Oracle RAC数据库的共享存储需求，同时也要满足其他多种数据库弹性的容量需求，以及为实现数据库的虚拟机在不同物理机上漂移的需求，我们使用基于高性能全闪存的分布式存储来满足这样的存储需求。
6、基于该单位的信创要求，同时要使用海光和ARM CPU的服务器，而存储节点选择了使用ARM CPU的服务器。
上述的客户需求和解决方案，看起来显得过于灵活。但实际上，这样的需求场景在大型企业和组织上是客观存在的：
1、虽然国产化替代进入了深水区，但是核心系统的替代还需要时间，当前还需要Oracle数据库来承载核心业务。
2、在开源和国产时代，多种数据库并存，商业、开源、国产等存在多种类型数据库。以及对应的计算资源即服务器，也存在多种类型，Intel x86、海光和ARM等多种CPU的服务器。
我们看到存算分离架构在满足数据库承载需要的稳定可靠、业务连续、性能提升、成本降低以及“国产信创”等多个需求上得到了“统一”的满足。而如果是存算一体的架构，几乎不可能实现上述的需求。
接下来，我们再来看一下存算一体和存算分离两种架构的示意图：
以上这两种架构，有各自的优缺点。这个世界上有非常多的优秀的产品和解决方案，我们应该从不同的场景下来看待架构的优缺点。
对于生产环境的IT基础设施资源的使用，根据在基础设施上运行的软件，基本上可以抽象分为“计算密集型”和“数据密集型”两种场景。
资源使用场景 |
场景举例 |
资源需求 |
计算密集型 |
业务软件，通常由Java语言开发，主要进行数据展示、业务逻辑的处理； 中间件软件，如Redis。 |
计算资源：主要进行业务逻辑处理和一些数据的处理，主要消耗CPU和内存。 存储资源：只有少量的数据如配置文件存放在本地，其他大量数据和访问都由数据库系统来处理。 |
数据密集型 |
数据库系统，大数据系统等，对数据提供查询、存储、计算处理 |
计算资源：大量数据的查询、关联、汇总处理而消耗CPU和内存。 存储资源：根据业务不同需要大量的IO吞吐或者是低延迟IO访问时间；同时需要存储大量数据而需要很多存储空间。 |
总的来说，业务软件和中间件软件，以消耗计算资源(CPU和内存)为主；数据库系统（关系型数据库、非关系型数据库、大数据等），同时消耗计算资源和存储资源。
我们再从存算一体和存算分离两种架构提供的资源能力来进行分析。这两种架构，存储容量和内存容量对单台服务器都是弹性的，（这意味着可以配置不同容量和数量的磁盘，也可以配置更多内存来提升可用内存），但是服务器的CPU资源是相对固定（当前主流的Intel 4代CPU为2路CPU共64核）。下表展示了各组件主要的计算资源即CPU的消耗比例：
组件 |
计算密集 |
计算和数据均衡 |
数据密集 |
| 分布式存储 | 10% | 20% | 30% |
宿主机 操作系统层 |
1% | 1% | 1% |
| Hypervisor层和虚拟机操作系统 | 10% | 7.5% | 5% |
而根据上表数据，可以计算出存算一体和存算分离两种架构可用计算资源比例：
架构 |
计算 密集 |
计算和 数据均衡 |
数据密集 |
计算方式 |
| 存算一体 | 79% | 71.5% | 64% | 上表中3个部分的消耗之和 |
| 存算分离（计算用物理机） | 99% | 99% | 99% | 只有宿主机操作系统层的消耗 |
| 存算分离（计算用虚拟化） | 89% | 92.5% | 94% | 宿主机操作系统层+Hypervisor层+虚拟机操作系统，共3个部分的消耗 |
根据上表数据，我们可以看出：
对于存算一体架构：如果是以运行业务软件或中间件软件为主，即计算密集型，CPU的有效利用率仅有79%；但如果是以中小型数据库为主，即计算和数据均衡型，CPU的有效利用率仅为71.5%；如果是以中大型数据库为主，即数据密集型，CPU的有效利用率仅为64%。
而对于存算分离架构：如果是数据密集型的中大型数据库，计算节点用物理机，计算节点CPU的有效利用率高达99%；如果是中小型数据库，计算节点也可以用虚拟机，CPU利用率可以达到92.5%。
这意味着在数据库场景下，只有采用存算分离架构，计算节点才有可能提供足够多的CPU即计算资源给到数据库运行。中大型数据库如重要业务系统数据库、数据仓库使用存算分离架构下的物理机，而中小型用存算分离架构下的虚拟机来整合多数据库。而在计算密集型场景下，存算分离架构（计算用虚拟化）的CPU资源利用效率比存算一体提升不是很大（89% vs 79%）。
1、为什么数据密集型场景（中大型数据库或多套中型数据库整合场景），分布式存储的CPU占用率更高？
这是因为在大规模存储容量和高并发低延迟IO请求场景下，分布式存储需要更多的CPU来进行处理。而在计算密集型（业务软件非数据库场景），存储容量小而IO访问量不高，分布式存储只需要分配较少的CPU资源即可以满足。
在数据密集型场景下，分布式存储占用较多的CPU，除了大容量存储本身的资源消耗，更多的CPU也会用在数据压缩等功能上，这样实际上会大幅节省存储成本。2、为什么计算密集型场景存算一体架构，虚拟化占用的资源更多？
这是因为在大量实际的环境中，计算密集型场景通常会分配更多的虚拟机，虚拟机的调度管理、虚拟机操作系统本身占用更多的资源。三种类型CPU资源从10%递减到5%，是基于大多数情况的数据逻辑，而不是精确的或者是所有场景都一定是这样。比如计算密集场景中，一台物理机只分了2台虚拟机来跑业务软件，这个时候Hypervisor层和虚拟机操作系统肯定不会占用到10%的资源。
1、数据库场景需要存算分离架构：
存算分离架构更为灵活，计算节点可以使用物理机，也可以使用虚拟机。
中大型数据库计算节点使用物理机才有足够资源支持性能需求以及可能稳定可靠运行，同时存算节点有足够资源支撑数据库的高容量高吞吐的存储需求和高并发低延迟的IO访问需求。
对于中小型数据库计算节点使用虚拟机能够在计算资源、性能和存储容量进行平衡。
计算资源层可以根据需要使用多种CPU架构的服务器，包括Intel x86、海光和ARM CPU的多种服务器。
2、非数据库场景适合存算一体架构
由于没有密集的数据访问需求，主要消耗的是计算资源，因此存储层占的资源不多，有足够多的CPU资源供应用软件使用。当然如果是小型企业和单位，数据库的数据量和访问量比较小，对高性能、高并发以及存储容量没有需求，则存算一体架构也是没问题的。