服务器|云原生数据库的幕后英雄—浅谈分布式数据库的计算和存储分离( 四 )

其实这只是架构导致的问题之一。如果对比一下企业数据库，Hadoop，和MySQL的主从同步方案就会发现：前两个都有专门的本地可靠性方案（一般是同机房），而MySQL的主从同步方案是在CAP中优先保证性能，牺牲一致性。加上MySQL的增强半同步很容易在大事务等情况下退化成异步复制，因此即使是同机房内，仍然有很大丢失数据风险。前面分析过，Hadoop因为有独立的HDFS存储层，它的可靠性是构建在HDFS存储层之上，而不是像MySQL构建在主从同步或MGR之上。相对来说，前者的效率要更高，可靠性更好。业界大佬们采用存算分离，就是因为架构变化能带来事半功倍甚至从0到1的改变，从而“让数据库替换的代价变小”。

纵观业界的数据库存算分离方案，除了之前提到的云原生之外，一般会从这几方面入手。

可靠性

存储本身就有非常好的本地和灾备可靠性能力，反倒是服务器的可靠性偏弱。存储可以实现本地盘很多无法实现或难以实现的可靠性功能：

本地可靠性冗余：基于本地盘实现冗余有丢数据风险，有些则很困难，如对 NVMe盘的RAID，或者效率上不如在存储上实现。不过必须指出同样由于像MySQL这样的数据库缺少专业的本地可靠性方案，本地可靠性切换接管需要专门的适配改造才能发挥出更大价值。

数据校验：这个功能在存储上是标配，但在服务器系统层则很少考虑，如果数据库想做，那得自己开发这部分功能。

高可用：以MySQL为例，大事务或批处理业务都可能导致半同步退化。相对来说存储层实现容灾对数据库压力的敏感性要低。

备份：数据库备份恢复要依靠全量副本+增量日志，恢复时间会相当长。而存储一般都有快照复制能力，AWS和阿里更是把云备份的功能就建立在存储上了，在数据库实现存算分离后，直接将这部分功能用起来就可以了。

性能

解决可靠性问题时，一些性能消耗可以避免或降低，如增强半同步对性能的影响。

存储对性能的优化，如对SSD介质的优化催生了全闪存存储，采用端到端NVMe over Fabric降低IO路径和时延，专用的缓存算法等提升性能。

新技术的应用，如对SCM，FPGA的应用。

QoS实现对存储 IO的隔离在操作系统层面很困难

总结

云原生分布式数据库的高速发展，必然带来计算、存储的分离，“存算分离”是当前网络技术发展和社会经济进步的时代产物，是最适合当前时代发展需求的一种架构。数据库的存算分离是存储、云计算、数据库的技术的综合，对于数据库使用者和IT规划师，可以关注这一技术方向和其中的技术实现，来解决面临的问题。