《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL开源路线图（1） https://developer.aliyun.com/article/1232547?spm=a2c6h.13148508.setting.14.5e4f4f0ecmbIFO

（四）业务痛点分析

下面我们来分析一下当前看到的传统数据库或者集中数据库的业务痛点。

虽然有这些痛点，这些数据库仍然能够服务用户的很多需求。但是随着互联网移动IoT还有人机交互方式的不断演进，数据量和并发量不断地增加，逐渐超过了单机数据库或集中式数据库的吞吐，比如超高并发，每秒上千上万的病房，对于大部分单机数据库来说是很难处理的，要么就牺牲性能，延时极大，并且伴随着大量的超时查询，要么系统可能就会被击垮。

集中式通过读写分离和存储计算分布式，有限地提升了应对这种并发的能力，但是仍然存在单点处理能力不足的瓶颈。同样的，业务通过ETL产生的数据，对存储容量的需求逐渐超越单机或集中式能够提供的限制，这些其实都可以通过分布式化的Shared Nothing的产品架构来应对。比如将查询事务分摊到多个计算节点，来成倍地提升吞吐，加入更多节点来实现存储容量的水平扩展等。

不仅如此，通过复杂大数据查询的分布化，在各个计算节点上并行运行，可以大大提升单机或集中式对这些查询的处理效率。另外一方面，对于MySQL这样的IoT表来说，单表太大，也将影响查询性能。水平分区有效减少单个数据库内的表的大小，避免查询性能受到比如说像缓存命中下降；Scan效率降低的影响。这些业务痛点其实都是提出了对分布式和水平扩展的需求，也是考虑我们技术路线图的一个因素。

（五）技术趋势：云化，分布式，资源共享

背景方面，我们最后主要讨论一下数据库的技术趋势背景，但数据库技术很多，我们不可能每一个点都覆盖，因此主要从云化的角度去理解，因为毕竟数据库产品现在的主要方向是云化

从云化角度来看，首先数据库需要云化的技术是什么呢？

我们得看云化的核心是什么，云化的核心就是要极大地减少用户使用数据库的代价，或者叫TCO（Total Cost of Ownership）。这个代价主要包括管理、运维、软件、硬件代价。基于这个核心，目前公有云数据库服务首要提供的就是管控功能，帮助用户减少和避免管理和运维的投入。同时，云化服务支持按需的软硬件配置，发挥软硬件的最大效率，并保留实时的弹性，保证用户能够最有效的支持负载水平所需的资源。云化技术目标可以总结为简单易用，性价比最高。

其次数据库还需要分布式技术，不管是存储的分布式还是计算层，还是事务一致性层，甚至是故障恢复和数据冗余方面，都需要分布式的技术。

业务层面上，现在的数据库系统需要支撑海量的数据业务所带来的高并发负载和混合负载。从云化角度，分布式能力是实时弹性所需要的核心能力，所以也是云化的必要条件。

最后的技术趋势是资源要共享，资源要隔离，实现按资源或按系统分层的独立扩展。比如计算和存储的分离，就可以实现数据库计算按需扩展，相应的如果存储容量需要增加，则只需要增加存储层的资源和节点、这种隔离和独立扩展能力可以扩展到内存，扩展到计算、存储网络，甚至数据数据库的一些核心处理能力，比如事务处理和复杂查询处理等等。

在上述的趋势下，我们来看云化数据库需要发展的一些核心技术和特性。

首先数据库的高可用将成为重点发力的地方，因为这关系到云数据库的核心能力，即简化用户运维和管理的代价。如果一款数据库产品在任何故障下，用户都不掉线，查询都不受影响，那将极大提升用户对产品的信心，简化背后管理的复杂度。同时如果数据库任何运维操作，比如备份恢复、增删节点、Scale up节点等等都不会中断负载，不仅用户在使用体验上更上一层楼，也为数据库调优、提供更加自由和更多维度的方便。比如Scale up操作，就可以更加动态地进行，使得硬件能力更加贴近负载。

其次另外一个技术趋势就是扩展性，包含各种能力的扩展，存储/计算事务和复杂查询。比如事务存储是否可以按需扩展，比如并发数是否可以扩展，比如复杂查询能否根据数据量扩展分布式计算能力，从而减少查询延时。另外一方面，这种扩展是否有瓶颈？比如为提升事务吞吐，我们一般会采用MVCC机制，也就是所谓的多版本并发控制。在分布式下，MVCC需要全局时钟或者全局排序的数列，产生全局数列将对扩展规模形成约束，因为产生全局序列的服务可能就成为扩展的瓶颈。Google Spanner的Truetime就是为解决这个瓶颈而设计的，我们也设计了自己的时钟机制来应对这样的约束。

在具备了极高的高可用和多层次的扩展性以后，弹性地引入将会为产品带来云化所必须的按资源使用的特性。以什么样的弹性颗粒度来进行弹性操作，以多快的速度提供资源的扩缩，用户负载和性能是否受到影响等等，都是弹性技术所需要面对的。

另外一个层面的弹性叫Serverless，大家可能都听说过，或者看过别的产品在实现这方面的技术。所谓的Serverless实际上就是一个自动化的弹性，按需使用，不用时自动回收，这需要上述这些技术的综合，并且能够提供自动化的资源管理能力。

最后回到对用户应用性上的支持，用户经常已经有很多应用跑在传统数据库或者跑在开源数据库产品上，但是它没有云化的基础，没有云化的这些技术的支持，比如应用和高效的管控，极致的高可用，分布式扩展以及Serverless弹性等。如何让用户的这些应用可以顺利简单地以较低的代价迁移到云化产品上，将是产品应用性的首要考虑。这其中维持SQL和生态的兼容性至关重要，比如用户应用的SQL程序都不需要改动，可以直接切换到云化的数据库，是否可以减少大量的用户投入，来改造应用。比如用户的应用仍然可以使用相同生态类的工具，那么用户就不需要购买新的工具，省去为适配这些工具而需要的开发工作。

往往这些方面的一些应用性的缺失，是造成用户迁移的主要阻力。那么兼容性和易迁移性也将是我们考虑的重点。

所以概括起来，我们对云化数据库技术趋势就是4个方面，高可用、扩展性、弹性和兼容性。

（六）背景小结

基于以上背景，最后我们总结出开源Polar DB应该走哪些路线，然后实现哪些目标，如上图所示。

在架构上我们要支持分布式，技术上我们要云化，同时解决客户的业务痛点，在生态上拥抱开源。

《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL开源路线图（3） https://developer.aliyun.com/article/1232545?spm=a2c6h.13148508.setting.16.5e4f4f0ecmbIFO