最佳实践_云原生数据库 PolarDB(PolarDB)-阿里云帮助中心

适用场景

需要对接分布式数据库的用户的应用场景总是多种多样的。PolarDB-X 2.0结合新老应用的库表使用、SQL复杂情况以及对性能吞吐的要求，将用户的应用场景大体上划分为四种典型类型，如下表所示：

应用类型	示例	总体概况	SQL 特点
大量存量业务的应用	某医疗公司或医院已使用10+年的业务系统，系统存在大量旧业务。	存量业务的库表非常多。库数目≥10或表数目≥100。业务SQL查询的种类复杂多样。应用遇到单机资源瓶颈，业务查询响应时间的越来越慢，需要优化。	数据库要服务大量的老旧应用，存在众多历史业务的数据库或业务表，并且库表数量很大。存在大量业务老旧复杂SQL，且不能修改。
混合存量业务与新业务的应用	某经营多年的商家订单管理系统，且系统要开发新功能。	存量业务库表众多。库数目≥2或表数目≥10。新业务：业务有大表且数据增长快，单机资源即将不足，需要扩展。	业务库表数目偏多。存在大量存量业务SQL，且大部分不能修改。新业务的部分大表及SQL接受改造及优化。
基于单机MySQL 开发的新业务应用	某摄影公司新开发的业务系统，需要快速上线。	库表数目较少，业务规模较小。库数目<2或表数目<10。预期未来的数据增量较大，需要扩展性。	业务初期追求快速上线，后期会快速迭代优化。新业务的库表及SQL能接受改造及调整优化。
高性能高吞吐的业务应用	某大型电商的核心交易系统。	库表数目不多，但数据规模大，高并发。应用对SQL查询RT极为敏感。非常重视业务整体的吞吐性能。	SQL查询种类不多，且相对固定。 SQL查询的并发高，且要求查询性能稳定。

上述不同应用类型的用户所面对的业务场景及挑战各有不同，因此，他们在给改造应用并对接分布式数据库时各种取舍就自然不同。

为了让上述几种典型应用类型的用户更便捷高效地利用分布式数据库的红利解决来业务的问题， PolarDB-X的透明分布式功能便提供不同的工作模式，供初次对接PolarDB-X数据库的用户根据自己应用的特点进行合理选择。

各场景下推荐模式

PolarDB-X的透明分布式所提供的几种工作模式及其能带来的效果，如下表所示：

应用类型	优化目标	改造挑战点	推荐工作模式	给应用带来的业务效果
大量存量老业务的应用	突破单机资源瓶颈（主要是CPU/IO）。优化SQL查询RT。	历史存量业务的库表数目过多（库表数目可能达百级或千级），库表的JOIN关系错综复杂。业务原来的SQL查询复杂多样，不允许修改，对分布式数据库的SQL兼容性高。	单表打散	最大限度地保持对原有从多存量业务库表及其 SQL的兼容性与查询性能。众多单表被打散到不同的DN节点，突破单机资源瓶颈，实现负载均衡与性能提升。
混合存量业务与新业务的应用	突破单机资源瓶颈（主要是CPU/IO/DISK瓶颈）。业务SQL查询性能尽量不回退。大表的磁盘空间扩展。	历史存量业务的库表很多，库表JOIN关系错综复杂。存量业务原有SQL查询复杂多样，大部分不允许修改。部分新业务库表，尤其是大表，数据量增长快。	单表打散+手动分区	最大限度地保持对原有从多存量业务库表及SQL 的兼容性与查询性能。众多单表被打散到不同的DN节点，突破单机资源瓶颈，实现负载均衡与性能提升。业务大表手动分区，在解决扩展性的同时，保证读写性能。
基于单机 MySQL开发的新业务应用	需要扩展性。业务性能要求不高。	业务要尽量减少改造成本，需要快速上线。	自动分区	所有表自动分区，能突破单机资源瓶颈。所有索引默认全局索引，保证非主键维度查询的基本性能。
高性能高吞吐的业务应用	需要线性扩展。高性能。	业务并发量大（几万或几十万QPS），并要求线性扩展。业务对性能敏感，SQL查询要求快且稳定。	手动分区	所有表均按业务场景，手动选择最合理的分区方案。业务查询SQL能改造，满足线性扩展性。