开发者学堂课程【关系型数据库 ACP 认证课程：【视频】云关系型数据库架构方案】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/927/detail/14628
【视频】云关系型数据库架构方案
（7）游戏案例-心动
游戏的案例——心动，是一个多区多服的一个场景，通过PolarDB的优异的读写能力，可以保证高速增长，游戏体验更顺畅。PolarDB能够支持基本上三倍于 MYSQL的性能。第二，PolarDB采用了三副本一致性的存储，保证了数据的可靠性即使是实例发生故障，我们也可以快速的切换。一般来说可以做到30到60秒，保证数据的在线和业务的在线。同时PolarDB的分布式存储的这个特性可以分钟级弹升业务，比如说用户量突然变大，可以快速五分钟到十分钟，就可以把数据库给弹上去，保证用户的访问体验。
3.运营商行业数据架构特点
如上图：整个可以看到他的产品是比较多的，技术战略也比较复杂，不同的厂商的产品交互性也比较差，维护的成本比较高。核心业务系统就是对运营商来说，几大运营商大的核心业务系统，其实更多的在使用传统的集中式数据库架构。那对于分布式改造来说由于最近几年的这个趋势，很多运营商是有分布式改造的诉求的，但是改造成本比较大。同时也需要提供运化的能力符合运营商未来的发展思路。
（1）运营商行业OLTP数据库自主可控解决方案
对于运营商来说数据库的自主可控的解决方案，从客户需求的角度来看很多运营商的业务系统已经运转十年以上，新的数据库引擎需要具备兼容原有的开发习惯，降低改造成本。第二是希望实例数据量能够支撑的比较大，包括这个链接数、活跃会话数都应该较好的支持。第三能够有比较完善的生态工具，那整个周边能够做到自闭化又可视化工具，那某一个运营商是采用了PolarDB O来做这个新版本的技术迭代。利用亚当——是阿里云为了迁移用户做了一个兼容性适配的工具产品。通过亚当和 DTS可以数据迁移到 PolarDB O。同时亚当会给客户提供兼容性的验证的报告，告诉客户兼容性能达到百分之多少，有多少这个功能需要去修改。根据报告可以极大的降低我们开发成本。
PolarDB O是我们的云原生数据库，提供了数据的集群可视化能力，快速扩容和性能监控告警，满足这个日常的发布和管理诉求。最后，阿里云也提供轻量级的管控组建DBS stack支持线下的输出，集成了我们的这个DTS、DMS、DBS。 完成生态工具的自闭环，提升了 PolarDB O使用的环境的稳定性。
可以看到从 oracle迁移到国产的PolarDB O，其实保证了应用的最小化改造，而且最大的兼容的Oracle不低于现代网的性能支持的能力，同时提供了云原生的数据库管理能力，也是支持自动化改造和迁移工具同步工具的。
（2）运营商行业构建实时数仓数据库解决方案
运营商关于实时数仓的一个方案。对于运营商来说，不光是需要保证日常数据、交互系统的数据能够高并发读写，还要保证分公司包括这种交互式探索、一些运营报表的诉求包括业务分析、实施标签、固定报表这个场景下，其实原有的运营商业务可能是采用了不同的mp p方案，或者有些业务采用Oracle来支持的。
技术占用太统一，开发难度大，缺乏数据治理能力。而且不同的数据存储在多个系统会有冗余。在这个场景下已有的系统不能满足整个业务发展诉求，海量数据处理的效率也不好，在这个场景下给运营商提供了基于阿里云的云原生数仓 Analytic DB这样一个解决方案。
AnalyticDB支持采用DTS将数据从OLTP库实时写入到OLAP库，采用多并发技术确保传输效率，正常情况下可以做到秒级到毫秒级的延迟。利用分层存储技术，在保障核心数据查询效率的前提下，进一步为客户降低存储成本。通过资源池隔离技术，实现了多个分公司数据统一管理，能够保证不同分公司查数据时不受影响。降低技术栈复杂带来的运维管理成本，同时依赖多种计算能力的支持(离在线、 Spark等)，实现一个引擎一份数据多种计算场景的支持。
采用阿里云自研的云原生实时数仓引擎AnalyticDB，在成本为原有的50%情况下，在自助工具实时查询场景性能提升一倍，异步取数场景性能提升40%，AnalyticDB在性能及稳定性上均满足生产要求。
4.传统制造行业数据库挑战与解决方案
（1）石油行业面向亿级用户的数据库挑战与解决方案
业务挑战：是关于石油行业面向亿级用户的数据库挑战和方案，对于石油行业来说，整个有一个比较典型的特点是要支持全国的业务，典型的中石化中石油，全国有很多具有亿级的用户，整个体量比较大。同时数据库要快速支撑加油支付和便利店的营销活动。
解决方案：基于PolarX给加油站提供了分控分表的方案，一共有八个集群来支撑全国的业务，而且PolarX支持透明的扩缩容应对一些运营活动、营销活动。然后通过 DTS将PolarX的数据同步到AnalyticDB，提供业务运营和实时展示。
用户收益：稳定可靠的支持了五亿的用户，单个集群的节点能够承载了六十多万。整个设计容量其实百万QPS，实际上在这个场景除了能够支持石油这样的业务之外，还支持了中国邮政的更大的PolarX集群。同时PolarX加 DTS加AnalyticDB的解决方案能够一次性提供在线和营销的OLAP结算业务。
（2）使用PolarDB全球分布式数据库帮助传统企业实现海外部署
业务需求：通过PolarDB帮一些传统的企业实现海外的部署，实际上用了PolarDB的全球数据库，有一些企业有跨区域部署诉求，传统的数据库的容灾在跨国的同步，延迟是比较大的。一致性难以保证，如果要做单元化的话，改造的成本和时间费用比较高。
解决方案：通过引入PolarDB的全球数据库GDN网络，能够实现跨区域跨国的数据的同步，对于客户来说可能就在控制台上操作，就实现了全球的数据库的数据复制。
方案收益：对于某些客户来说容灾需求是能够快速落地的，而且快速交付。对于业务使用方来说，是零侵入的成本也比较低。
5.交通行业的行业特点和解决方案
（1） 申通核心系统上云案例
业务痛点：对于申通来说，目前客户的巴枪、订单、分单等业务每天都产生大量的数据，巴枪业务数据量数亿每天，订单&分单数据量数千万每天，总数据量超百TB。客户业务有面向不同场景的查询需求，既有根据订单号的点查，也有其他多种不同维度的范围甚至模糊查询的需求。而且每年双十—大促客户业务都会面临大幅度上涨。
解决方案：给客户提供是基于Lindorm为云原生多模数据库，可同时支持宽表引擎和搜索引擎，并且可通过LindormTunnel Service(LTS)实时将写入宽表引擎的数据同步至搜索引擎，并可保证搜索引擎和宽表引擎数据的一致性。同时Lindorm具备动态升&降配、扩&缩节点能力，轻松应对客户双十一大促的极致弹性需求，Lindorm采用存储计算分离架构，可以按需扩容存储或计算节点，扩容&缩容操作对应用透明,业务无需任何代码改动,数据和业务请求自动均衡，零运维。
客户价值：整个Lindorm对于客户来说有一个很好的价值，就是多存储介质支持、高压缩比、完全线性扩展能力，成功帮助客户完成去Oracle，实现可扩展、低成本、高性能上云。Lindorm宽表引擎配合搜索引擎完美的满足了业务对于订单/运单/分单的快速点查及多维度范围&模糊查找，实现︰宽表引擎支撑10万包裹/秒的高速查询，性能较原始方案提升5倍;搜索引擎支持上万网点的随机多维查询，并支持结果集的实时导出下载功能。通过LTS实现宽表引擎向搜索引擎的实时、高效，并且保证双引擎数据一致性，无需业务系统双写并保证数据一致性。
（2） 交通物流行业冷热数据分离及多维查询案例
标准版：能够支持多维查询和支持归档存储。我们利用HBase的存储原理优势达到控制存储成本和兼顾多维查询的目的，但也可以做归档。
进阶版：下一步做一体化冷热分离功能,在一张表内全透明实现数据的冷热分离，业务0改造便可获得极致成本降低。原生二级索引搭配Search服务还可大幅降低查询层容量。
业务最小改造版:X-Engine提供LSM存储形式，压缩率相比传统行存数据库大幅度提升，能够保证数据快速压缩。
（3） 交通物流行业车辆轨迹系统案例
在线业务超高并发，轻松解决：上图是交通物流行业的一个轨迹案例，如在城市公交场景下，涉及大量的车辆和车型、多样的计费方式，不仅要求数据库系统具有海量存储的能力，还需满足复杂查询计算。基于PolarDB-X存储海量数据，通过AnalyticDB进行数据分析，可构建智能化的城市公交系统,满足路线规划、站点查询.公交预报、业务报表结算、公交调度等需求，提升运营效率和服务水平。
能够提供
弹性扩容：PolarDB-X采用分层架构可确保在并发、计算、数据存储三个方面均可线性扩展,可根据业务潮汐特点灵活升降配PolarDB-X，应对业务需求。
即开即用：基于PolarDB-X可轻松从单机数据库升级到分布式架构，同时提供丰富的运维功能,相比自建分布式架构，大幅降低研发成本。·生态兼容。
高度兼容MySQL，可以比较容易实现迁移，打通大数据生态，通过将数据实时同步至云原生数据仓库AnalyticDB，实现对海量数据的实时分析，保证业务的智能化。
（4） 航空领域实时数仓案例
支持完整的事务以及并发增删改查
上图是航空领域的数仓案例，航空领域有完整事物要求，而且希望能够做实时的数据探索、业务报表。可以看到在这个场景下给航空领域的客户提供的是AnalyticDB PG这样的能力，支持行存分区，还有支持历史的列存分区。通过这种数据集市的方式给前端的实时分析实时报表和数据应用提供了快速查询的能力，同时也支持数据的增删改，我们这种mp p的引擎可以保证PB级数据的秒级响应。
（5）PolarDB自研空天（航空航天）大数据处理引擎GanosBase
实现了一个高维的数据查询能力，是全球首个云上移动对象数据库（ Moving Objects Database , MOD），支持人员、物流、航空器原生时空轨迹模型以及高达（ x,y,z,t)四维时空计算。支持多模的查询能力，原生支持矢量、轨迹、影像、点云、拓扑网络等10多大类新型空天多维多模数据的存储、查询和分析计算。在新场景下，航班轨迹高效压缩存储、商品配送、飞行器起降/盘旋检测。当前的能力是非常准的，能够支持非常准全球25亿航班轨迹秒级时空回放，同时也支持“亿级规模”地物10分钟构建矢量金字塔，秒级全图显示。
6.电力行业的特点及数据库解决方案
（1）电力行业数据架构演变
演变路径：传统IOE架构->开源分布式自建->引入成熟云平台
电力指的就是用户去某一个小区租的房子或者买了房子，要去交电费，就是电力主要提供的服务。电力的服务是非常复杂，上层有这个网上国网、用采、计费、财务计量、业务扩展、报表。中间的数据层，网上国网包含了用户中心、订单中心。用采乐包含用户的日常电量、日月的冻结、客户档案。计费和财务这块包含计费和费用的控制。财务包含交费和财务，像账单、交费、财务。综合业务包含业务扩展、计量、客户、资产。那实时报表包含账单、用户的购电明细这些。
在电力行业的前期还是用传统的Oracle数据库来支撑的，那架构演变目前是从传统的IOE架构到开源的分布式自建，对他们来说电力行业其实整体也是依赖于第三方的服务商来做开发的，第三方服务商再选择开源分布式自建的时候，在稳定性性能的扩展性上其实也会遇到一些瓶颈。最终电力行业会考虑引入成熟的云平台，包括云数据库来支持电力行业提供的数据库的底层能力。
（2）基于阿里云平台的电力营销业务架构
电力的营销业务架构，它分成了数据的采集区、营销数据的共享区、核心的业务平台。在营销2.0上给客户提供了时序类的查询数据，高并发的失误控制的能力，快速的去O业务的能力，还有实时分析统计的能力。在整个下层给客户提供离线计算的能力，还有缓存的能力。
整个方案里面，可以看到用TSDB时序数据库，也就是当前的领动时许引擎来替代了传统的Oracle和HBase给客户提供了非常好的量测存储的能力。通过PolarDB-X做分布式改造替代Oracle来提供高并发读写和海量数据存储的能力。通过PolarDB-X替换某些场景下的Oracle，保证国产化去O的能力。
（3）电力营销算费业务数据库解决方案
算费业务场景：通过实施数仓来支持营销类数据查询的诉求。营销的算费业务的数据库解决方案是这样的，整个场景是依据用户的基础档案、电量采集结果、电价参数三类信息，核算用户电费，控制用户停/复电;智能电表每15分钟采集一次，每个设备每天96个采集值;智能电表用户超过4500W，数据要求保存180天,总数据量超过30T ;
客户需求：对于电力的用户来说希望支持更多用户设备数;支持更高数据采集频率;支持更大数据存储量;支持高并发的数据读写和计算。
客户痛点：智能电表设备增长了，怎么办?这是一个扩展性的问题。采集频率提高了，怎么办?这是一个高并发读写的问题。还有就是数据保存时间变长了，怎么办?
传统的方式是用采和费用控制，包括费控测算、采集监控，费控策略、用户策略、档案服务、台账服务，这些其实都是把数据存到了Oracle上。包括这个档案数据、日月冻结数据和事件。
（4）电力营销算费业务数据库解决方案
对于新一代算费的业务架构来说，希望能够支持很好的扩展能力，给客户推荐PolarDB-X支持高并发的数据读写，还可以做到水平扩展。那PolarDB-X现在在正式的业务环境里面，最大的一个集群应该是一百多个节点，这一百多节点之前是测算过的。能够支持10万级的t PS，比如每秒写入量，包括支持百万级的 QPS，就是每秒的查询量。
一百个节点的话估一下可以支持到几百 TB，难点是我们要对整个业务做一个数据拆分，那数据拆分其实是电力的业务适配的时候，需要帮客户做的比较难的点。在这个场景下缓存其实是能够做临时表和内存库的，能够提升访问性能，减少业务层对底层关系型数据库的依赖做结耦。
二、回顾与总结
云关系型数据库的架构方案包括新零售、游戏、运营商、传统制造、交通行业、电力行业这样的一些解决方案，还有整个的业务痛点。
三、课后习题
样题1
在一个RDS实例下创建的逻辑单元，以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合，可以简单理解为存放数据的仓库。可以解决海量订单需要分库分表问题的数据库产品是()。
A.PolarDB-X
B.PolarDB MysQL.
C.PolarDB O
D. PolarDB PostgresQL
答案：A
样题2
传统容灾架构主从之间数据延迟较大,且难以控制,导致异常情况下数据一致性很难保障，需要通过引入PolarDB全球数据库网络( )实现全球多地区跨地域部署容灾低成本构建数据库容灾体系。
A.GDN
B.VPN.
C.CCN.
D.VPC
样题3
PolarDB兼容多款流行的关系型数据库引擎，完全兼容MySQL和PostgreSQL，高度兼容Oracle语法，下列不是PolarDB优势的是().
A．新增只读节点时需支付存储费用
B.存储空间无需手动配置，根据数据量自动伸缩
C.深度优化数据库内核，同时采用物理复制、RDMA高速网络和分布式共享存储，大幅提高性能
D.基于共享存储的一写多读集群，数据只需要一次修改，所有节点立即生效
答案：A
PolarDB其实是一个共享的分布式存储的一个数据库，上层计算节点和底层存储节点是分离开来的，所以其实在只读节点的时候不需要额外支付存储费用，因为存储是一份但这一份存储是三个副本。
样题4
PolarDB-X的架构继承了(―)和()技术的稳定性，结合了PolarDB的云原生技术，融入了NewSQL对于分布式数据一致性的能力，为用户提供新的“云原生+分布式"的产品体验。
A. DRDS
B. Online DDL
C. X-DB
D.HTAP
答案：A、C
Polar x的架构继承了DRDS和XDB技术的稳定性，PolarDB的云原生技术，在最早的时候Polar x是在阿里内部由天猫淘宝分化出来一个分布式数据库的解决方案，叫DRDS就是分布式数据库服务。Polar x是新的品牌名字，同时Polar x现在最初背后的这个数据库的存储引擎就是的XDB，提供了非常好的技术稳定性。
样题5
运营商目前核心业务系统OLTP所采用的数据架构设计是().
A.集中式数据架构设计
B.分布式数据架构设计
C.横线式数据架构设计
D.纵向式数据架构数据
答案：A
运营商在初期的时候整个运营商的整个体系，这样的商业数据库其实本身的架构是偏集中式的，当前的运营商实际上核心业务系统，在线交互系统采用的数据库架构是集中式的数据库架构设计。在整个过程中我们来回顾一下这里是集中式的架构，运营商采用的是集中式架构，对于运营商来说他的这个用户量和数据量是非常大的，包括并发读写量。
比如说移动联通的用户可能是亿级的，原有的集中式的数据库架构目前随着用户量和业务的不断复杂，已经不能满足她的业务的发展当前的扩展了。那其实下一个阶段其实要从集中式的数据库架构转到分布式的数据库架构的设计。
