开发者学堂课程【关系型数据库 ACP 认证课程：快速学习云关系型数据库架构方案】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/927/detail/14628
云关系型数据库架构方案
内容介绍
一、 阿里云数据库解决方案及案例
二、 回顾与总结
三、 课后习题
课程目标：了解云数据库在新零售、游戏、传统政企、运营商、金融行业、传统制造、交通行业、电力行业的应用及各个行业的特性。云数据库关于关系型数据库这一部分的一些重点的能力，以及能力的一些场景。
一、 阿里云数据库解决方案及案例
主要包含六个行业：
新零售、传统制造、游戏、交通行业、运营商、电力行业
主要将这些行业中，关于对数据库解决方案的痛点、场景做一些介绍。同时在这些痛点和场景下，应该提供怎样的数据库解决方案来应对，这些解决方案给这几大行业的客户带来的哪些收益和好处。
1.新零售行业数据库需求与挑战
在过去很长的一段时间里，阿里云主要服务的行业就是新零售行业。新零售行业包含的范围其实非常广，包含电商其实是新零售的一大领域，同时包含比如像大润发这样的零售商，以包含像安踏、特步这样的品牌商，所以对于这个行业来说，有六个关键点：运维、ISV、海量数据、弹性、稳定和安全。
第一部分运维便捷，要对新零售行业的客户提供快速诊断数据库实例异常、自动诊断优化 SQL/SQL 限流、便捷的数据备份恢复、大促智能压测。
第二部分要去应对新零售的 ISV，这里所谓的 ISV 就是软件开发所谓的服务商，因为新零售的很多企业实际上是偏传统的企业，在 IT 研发的资源投入相对没有那么多，很多的零售企业的IT系统用的是第三方的，这里提到的 ISV 就是第三方的企业IT 的服务商。对于新零售的企业来说，更依赖 ISV 提供的服务，比如 CRM、ERP 等 SAAS 软件服务。
第三部分零售的企业分为生产和销售两大端，生产和销售尤其是对于快销类和服饰类特别明显，因为销端的数据非常明显。例如：安踏是阿里云的客户，他的渠道和门店是非常多的，业务也非常广泛，订单和库存流水包括会员支付物流客服是非常多的，同时为了跟踪他的业务其实在业务系统里面会有埋点的日志。
第四部分新零售领域存在非常突出的弹性特点，比如618、双11、双12这些大促活动等需要充足资源，但在日常的情况下需要降到正常的水平。日常场景下资源降配到正常水平，比如在双十一当天可能是平时的十倍百倍，对后端、数据库的资源需求量是非常大的，也需要数据库支持平滑扩缩容。
第五部分所有的IT系统都希望服务足够稳定。
第六部分业务系统非常重要，数据就是命脉，数据库的安全包括全链路数据库安全访问控制和审计，敏感数据脱敏都是非常关注的。
（1）安全可靠∶数据安全解决方案
给新零售行业的客户提供了这样一个解决方案，要保证业务需求上相权限的拦截、高危操作拦截、敏感数据的脱敏和识别，还有数据库操作审计、数据库加密存储、还有异地备份。那整体上来说需要通过 DMS，前面洪斌老师介绍了 DMS 能够做什么事情， DMS 可以数据库做访问控制，通过安全高效拦截的高危操作，并且识别敏感数据做脱敏。同时也支持这个审计，审计如果所服务的公司或者之前了解过，其实对于一些上市公司或者对数据要求严格的公司是非常重要的。也支持这个数据库内核比说 RDS，对于这个 TTE 加密也就是说存储加密是支持的，而且对于 SSL 的传输加密也支持的很好。通过 DBS 可以对数据做异地备份，从访问控制、数据传输、存储、审计合规多个维度能够保证企业零售企业的数据安全。
上图是阿里云整个的数据库的安全体系。从不同的维度，账号安全、链路安全、存储安全、容灾容错、运维合规、数据安全不同角度，去给零售企业提供了安全解决方案。
（2）服务稳定:RDS服务高可用解决方案
服务的稳定性，包括数据库的容灾能力要求是非常高的。那我们的业务，比如说零售企业用户，或者是一些客户提供服务服务的稳定性，包括服务的可用性要求非常高的，希望支持机房级的容灾宕机的时候，能够快速恢复。
RDS 其实是支持主备实地的跨可用区，那这个可能就是说 AZ 是支持这个跨区的部署的同时，在发生高可用切换的时候可以在很快很短的时间内，切换到这个备库上。同时也支持这个数据库的备份，刚才了解到其实 DBS 就是用来支持数据库备份的。
而 RDS 本身也自带了备份能力，支持全量和增量的数据库备份。机房级中在能够保障数据库的可用性和数据的安全性，同时通过这种实时的日志备份保证在异常情况，举个极端的例子：这个服务器宕机了，那备份其实是通过全量和增量的备份，能够保证数据可以恢复到宕机前的一个时间点，尽量减少企业的这个数据的损失。
（3）海量数据&快速弹性:大促营销解决方案
对于零售企业其实对弹性和海量数据是有非常大的要求的。在大促的时候其实需要提供非常好的这个弹性方案，对于这种零售企业举个例子：特步是民族的服饰的企业，是一个典型的零售的品牌商家零售商，又有品牌的属性，又有自己的门店，有不同的渠道。但特点就是门店多订单多，然后库存的流水多，需要支持高并发协助，而且要支持海量的数据。
在大促的时候这个订单可能翻几十倍，数据库要能够快速弹。同时零售类的企业有一类企业，有典型的特点就是它的交易类过程类数据非常多，门店包括店长、区域的负责人、老板，是希望看到销售、财务、包括日常支付单子的一些报表。报表其实是需要有数据库来支撑报表的快速分析，对于特步的这个场景下，其实数据量可能已经到十亿级了，有一些十亿级的数据报告跟其他的数据做这种数据的关联，访问时候其实对性能要求比较高。这个方案是通过 polar-X。前面学过 polar-X 是可以这样水平拆分的，支持客户的这种高并发读，写同时可以线性扩容。
RDS 也支持热点更新，保证了秒杀场景的性能要求，通过 DTS 把 polar-X 的这个数据同步到我们的 ADB MYSQL。可以做实时分析和这个场景可以提升这个整个业务系统的吞吐能力，通过 polar-X 和 RDS 的快速弹性升降配，满足大促场景的诉求。
同时也降低了 IT 成本，只需要在大促前一天或者前一段时间，把实力的规格升上去，然后用完后再降下来。同时我们的 ADB 对于事实分析的这种十亿级，甚至百亿级甚至更大的数据可以做秒级的分析，保证我们的业务和业务决策能够平滑对接。
（4）ISV 支持: SaaS 多租户解决方案
ISV 支持这部分，在阿里云云上有一类，专门给零售类的服务提供企业服务，比如毅昌科技给客户提供这种类似于 ERP 和 CM 这样的服务的时候，可能会为了降低自己的这个 it 预算，保证单课的成本比较低，会走这种多租户的模式，这种多租户的模式其实是可以降低 IT 成本。但是会出现资源会发生抢占，业务高峰的时候可能会有一些压力。同时希望业务能够支持这个批量的 dl，支持快速的在线升降配这样的能力。通过 polarDB MYSQL 来支持这个百万到千万级表的数据存储，同时polarDB MYSQL 也支持这个热备节点能够快速切换。
最近还上了列存索引，能够保证一些复杂查询能够快速查询，可以支持多租户多写的能力，未来 ISV 的支撑会很好。这个方案里面最大的优势就是：第一是弹性，第二是写能力比较好，第三也支持快速的 SQL 迁移，最后就是可以支持列存索引，来保证复杂的数据能够快速的查询。
（5）运维便捷:数据库自动化运维解决方案
关于运维的便捷性，通过刚才洪斌老师介绍的 DAS 来保证客户的不同的数据库实例，能够自动的发现一些异常，对异常的数据库做报警还有异常 SQL 识别，还有限流保证数据库的稳定性，同时也支持完整的审计，包括我们可以做压测。智能压测其实在最近两年，在云上的企业客户里面，其实已经应用很广泛了。客户要坐搬栈、要做上云、要做数据库的内核的升级，都可以用这个智能压测来做。这个是零售这一部分的一些方案和行业特点。
2.游戏行业数据库痛点及挑战
游戏现在已经是一个全民行业了，但游戏的特点跟新零售的特点会稍微不同。运维便捷其实是整个这个行业里都会诉求的。
第一是游戏在做发版升级的时候能够快速读取全量数据，降低停服时间。开服、和服能够快速的备份恢复，还可以做这个归档还有回档。
第二就是游戏有一个典型的特点，要去做一些投放这个广告和一些运营分析，叫做玩家的群体分析，同时有千人千面的这个推荐诉求。
第三游戏行业的日志量是非常大的，玩家的行为日志等数据体量很大，同时支付交易会员登录聊天也是数据量非常大。
第四对于游戏体验，玩过游戏的同学有可能会比较了解，游戏一旦卡了用户就会非常不满。同时游戏的响应速度要求快而且支持高并发，比较火的例如王者荣耀，并发的量是百万级的。
第五同时游戏对长时间的稳定要求也比较高，希望长时间在线不掉线，异常宕机的情况下也能够快速恢复。
第六游戏有这种开服、运营活动需要充足的资源，日常情况下系望资源能够降费的。
(1) 游戏场景-单服
在游戏场景里面首先来看单服的场景。单服实际上要求架构简单部署，能稳定，同时保证这个游戏娱乐性。在选型情况下一般的游戏客户会选择 polarDB 或 RDS 加上 Tair 或者 redis 来支持业务。当然游戏有一个特点是游戏的数据结构其实是比较灵活的，MongoDB 也是很多游戏公司的选择，来支持 Schrema free 这中场景的要求。
（2）游戏场景-分区分服
第二个场景是分区分服，业务要求：跟单区场景有点不同，它对于这个系统的容量是希望可以线性增加的。业务价值：有滚服、和服的诉求，滚服指从测服合并进正式服，和服指两个服务用户较少，则合并为一个服务器。选型能够支持快速回档，业务价值能够给我们增加更多的用户。这个场景下给游戏客户，推荐 Redis 集群版加上 PolarDB、Tair、 DMS、DBS 和 DAS 来提供数据的快速回档和数据管理能力。
（3）游戏运营-玩家行为分析
第三个场景是游戏运营和玩家分析。游戏典型的特点是游戏玩家，不管是在游戏平台上还是游戏里面，其实每一个玩家的行为日志是非常丰富的比如：王者荣耀的皮肤购买、局内的对战、对战结果的输赢，用户的日志量非常大。我们服务的对象是游戏的广告和数据平台部门，对于游戏公司来说流量会越来越贵，能够保证更精准的调整这个运营策略，其次，用户会逐渐成熟，对游戏的品质要求越来越高，而且整个游戏行业的竞争非常的激烈，好玩而且要懂得这个市场。在给游戏公司提供能力的时候，是考虑到数据分析的价值，比如包括战斗数据成长数据，第二是行为分析，比如有付费的检出、社交个性化道具这些具体的业务价值，能够保证这个游戏的角色平衡提高和可玩性再挖掘。在这个场景下给游戏公司提供的建议选型，前端选型 MYSQL 和 PolarDB。其实在最近几年的推广来看，像比较著名的公司如米哈游，用阿里云的 PolarDB 的更多一点是考虑到弹性能力，PolarDB 弹性能力在游戏的这个场景下会充分利用。后端的游戏的日志分析选用的是 Analytic、DLA、Clickhouse。任务调度可以用 DMS、Dataworks 来支持。
(4) PolarDB-快速备份恢复
秒级备份：每次备份不超过30秒
高频备份（快照）：每2小时做个备份（24h内）
分钟级恢复：从全量备份恢复，不超过10分钟
库表恢复（5.6已支持，5.7/8.0 2个月后）：可选择1-N 张表，恢复到本实例（重命名）
PolarDB 的快速备份恢复能力。在游戏场景下，回档的诉求是一个典型场景。PolarDB 支持秒级备份，因为它是一个共享的分布式存储，可以做快照备份，可以对备份做高频快照，比如说每两分钟做一次，通过这种方式可以做到分钟级恢复游戏的全量数据。
同时也可以支持库表恢复，如多张表或某一张表发生问题，要回档，可以选择一张或者多张表恢复。整个恢复速度非常快，比较传统的这个方案如 MYSQL 或者其他的关系数据库去恢复时，其速度是比较慢的，可能要十几分钟、几十分钟甚至小时级别。这对于游戏玩家来说是不能忍受的。实际上快速恢复可以给游戏公司提供非常好的回档能力。
（5）游戏数据库的容灾多活-PolarDB GDN
PolarDB 支持全球数据库网络，它的核心能力是，可以在比如说北京写入一个PolarDB 主集群，后台通过内网把数据同步到新加坡的一个集群或美西的集群。多个集群之间可以保持这个数据同步，主集群和从集群可以进行数据同步。每个集群都可以支持写，从集群会把写请求发送给主集群，这个场景对于全球性的游戏来说支持的非常好的。
（6）游戏数据库的容灾多活
游戏数据库容灾多活，基于PolarDB 是可以做容灾多活的，在下图场景下可以达到2s 以内的延迟，同时支持快速切换和快速回切。
（7）全球多活让缓存距离应用更近
上图的场景是阿里云自研的缓存能力 Tair，支持全球多活，支持北京、新加坡、上海多个 region 与 region 之间进行不同的数据部署。这个场景游戏的服务商有独立部署的诉求，而且希望就近读写，缓存延迟非常低，很多场景都是一毫秒以内，个别情况可能稍微延迟一下。通过这个 Tair 的这个全球多货能力可以保证，全球可以就近读写，同时能数据互相复制，这样就除了冗余之外还可以降低业务设计的复杂度。
同时 Tair 也支持秒级数据的恢复，这个场景下缓存的数据希望精确地回滚或者恢复到某个时间点，而且支持全量和增量的恢复。这种场景能够保证我们这个游戏回档简单而且这个版本发布异常的时候不需要去做数据的备份，其次误删除和恶意删除可以快速的恢复。
（8）游戏案例-心动
游戏的案例——心动，是一个多区多服的一个场景，通过 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，难点是我们要对整个业务做一个数据拆分，那数据拆分其实是电力的业务适配的时候，需要帮客户做的比较难的点。在这个场景下缓存其实是能够做临时表和内存库的，能够提升访问性能，减少业务层对底层关系型数据库的依赖做结耦。
