分布式数据库概念已经诞生几十年，早期更多只是作为研究对象，直到2000 年左右才真正走向应用，主要用于各大企业尤其是互联网企业解决扩展性、高并发、高吞吐等访问问题。直到近几年，分布式数据库才真正在商业化应用中投入使用。
如今分布式数据库有效解决了很多问题，比如在新零售、电商、在线教育等场景下，解决了在线交易系统高并发读写问题；在传统行业制造业、政企、交通、能源等场景下，解决了海量数据大集中问题；在对于容灾有着非常高要求的金融领域场景下，解决了跨地域高可用问题。
商业化应用过程中，分布式数据库仍然面临着很多问题，主要包括以下几个方面：
第一，兼容性。能否与传统数据保持兼容。
第二，使用门槛。是否必须要有足够大体量才用使用？能否像使用单机数据库一样简单方便？
第三，扩展能力。数据扩展以后，面临跨数据分片，分布式事务是能否保持高性能？
第四，运维复杂度。分布式数据结构较复杂，涉及到集群化部署以及多个节点之间交互，如何控制运维复杂度？
PolarDB-X是非常典型存储计算分离分布式架构。GMS是元数据管理中心；CN是状态计算节点，负责解析与执行；DN用于存放数据节点；CDC是全局一致 Binlog组件负责输出，与 MySQL 兼容、全局一致的日志内容。整个PolarDB-X架构在云平台上，因此称为云原生分布式数据库。
PolarDB-X具有三个显著特点：
第一，兼容原生MySQL生态。
第二，一体化透明分布式，可以像使用单机数据库一样使用，无需了解过多分布式概念。
第三，具有非常强大企业级能力。比如高可用能力，RPO=0情况下也可实现跨地域高可用；比如HTAP能力，可同时支持两种负载；另外，针对企业对于数据安全要求也做了大量工作。
实际上要做到一个产品100%兼容另外一个产品难度极大，因为原有产品会不断地发展迭代。因此我们做兼容性的原则主要针对企业级用户需求和侧重点对大部分能力和语法实现了兼容。另外还实现了生态上的兼容，以保证原有使用MySQL数据库的用户能够非常方便地、透明地迁移到分布式数据库上，无需修改应用，也无需修改数据结构，可以完整无缝对接到原有生态上。
为了实现生态兼容，我们开发了CDC全局一致Binlog组件，能够提供完全兼容单机MySQL的Binlog，无缝接入现有生态工具同步到下游生态。同时，PolarDB-X也可以作为MySQL的备节点，利用MySQL Replication组成高可用架构。
一体化的重要方向是集中分布式一体化。分布式数据库在商业应用过程中，并不是所有用户都在一开始就具有大体量、高并发的需求，大多是随着业务发展逐渐出现大体量的需求。
因此，PolarDB-X提供了两种不同形。一种为标准版，集中式形态，100% 兼容单机MySQL，具有更低的使用成本，另一种为企业版，用户可以从标准版平滑升级到分布式企业版形态。
为了在分布式层面提供更好的单机体验，我们提出了透明式的概念，其中的重要能力为AUTO 模式，可以在创建数据库时指定数据库为自动模式，数据库会根据容量大小做自动分区，无需主动干预。但同时也保留了手工分区的能力，更好地契合业务。
另外，PolarDB-X提供了在线与历史归档数据一体化，可以通过事先设置数据过期规则，自动将历史数据归档存储到OSS。在线数据与历史数据可以通过统一的SQL语法、统一的接入点进行访问。目前历史归档数据相对在线数据存储成本最多下降了有20倍。这个功能目前已经在公有云版本上线。
分布式架构并不是银弹，无法解决所有问题，也存在设计上的相应代价。
从架构上来看，即便是在单机系统上，即便只有2个NUMA节点，跨NUMA Node的访问也会使性能下降至少1倍。而到了分布式系统上，总线变为网络，一旦涉及到远程访问，性能更是会出现急剧下降，比如单个全局二级索引，写入性能下降30%。这个是分布式系统带来的非常显著的代价。想要透明式的体验必然会导致性能不达预期，要想保持性能需要精心设计数据分布规则，小心地限制使用特性。
为此，PolarDB推出了表组的概念。根据业务特点，自动将有相近统一的分区键组合到同一个表组中。具有相同业务属性的表往往具有事务关联性，原本需要做分布式跨数据分片的事务处理变为可以在单机上进行，有效消除了分布式事务带来的开销。
且我们实现了自动化表组聚合，无需过多的人工干预。当然也支持人工指定规则，更好地利用特性，更好地优化。
数据分区以后带来的显著问题在于数据分布不均，包括数据量不均衡以及访问不均衡导致出现局部数据热点。识别到热点以后，PolarDB-X可以通过一些操作在不影响业务运行的情况下打散热点，让系统变得更平缓，从而实现分布式系统处理高并发的请求。
要做好分布式系统的运维，对运维人员以及数据架构均有极高的要求，必须了解服务系统的概念，而且分布式系统本身的系统复杂性较高，分析异常时面临的链路较长。
PolarDB-X构建了可实时观测的运维平台，能够对异常数据进行非常密集的监控，通过分析实时洞察SQL执行过程中的耗时、线程瓶颈，并显示热力图，运维人员可以直观地查看每个分区上的访问热度如何。还可进行诊断分析，包括规划分析、空间分析以及死锁分析。还会做系统关联，分析全链路每个阶段的耗时、性能指标以及系统整体运行情况，最后根据系统运行情况做实时优化，比如对性能有瓶颈的问题自动推荐索引。
通过以上手段，能够更有效地定位问题，更有效地分析数据，从而得到更平滑的体验。
对于分布式系统，在运维过程中的一个非常典型的问题是能否做实时的数据字典定义。对于数据量非常庞大的数据表而言，对表结构做定义往往会牵涉到大规模的数据迁移工作，会对系统造成极大冲击。
因此，我们设计了Online DDL，所有DDL均在线，不影响业务运行。同时尽可能做并发的数据结构修改、数据搬迁以及复制，有效降低对系统的冲击，提升整个数据搬迁的过程。
