从架构层面分析PolarDB技术要点

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: PolarDB PostgreSQL(以下简称PolarDB)是一款阿里云自主研发的企业级数据库产品,采用计算存储分离架构,兼容PostgreSQL与Oracle。

背景

PolarDB PostgreSQL(以下简称PolarDB)是一款阿里云自主研发的企业级数据库产品,采用计算存储分离架构,兼容PostgreSQL与Oracle。PolarDB 的存储与计算能力均可横向扩展,具有高可靠、高可用、弹性扩展等企业级数据库特性。同时,PolarDB 具有大规模并行计算能力,可以应对OLTP与OLAP混合负载;还具有时空、向量、搜索、图谱等多模创新特性,可以满足企业对数据处理日新月异的新需求。

PolarDB 支持多种部署形态:存储计算分离部署、X-Paxos三节点部署、本地盘部署。

传统数据库的问题

随着用户业务数据量越来越大,业务越来越复杂,传统数据库系统面临巨大挑战,如:

  1. 存储空间无法超过单机上限。
  2. 通过只读实例进行读扩展,每个只读实例独享一份存储,成本增加。
  3. 随着数据量增加,创建只读实例的耗时增加。
  4. 主备延迟高。

PolarDB云原生数据库的优势

image.png

针对上述传统数据库的问题,阿里云研发了PolarDB云原生数据库。采用了自主研发的计算集群和存储集群分离的架构。具备如下优势:

  1. 扩展性:存储计算分离,极致弹性。
  2. 成本:共享一份数据,存储成本低。
  3. 易用性:一写多读,透明读写分离。
  4. 可靠性:三副本、秒级备份。

PolarDB整体架构简介

下面会从两个方面来解读PolarDB的架构,分别是:存储计算分离架构、HTAP架构。

存储计算分离架构

image.png

PolarDB是存储计算分离的设计,存储集群和计算集群可以分别独立扩展:

  1. 当计算能力不够时,可以单独扩展计算集群。
  2. 当存储容量不够时,可以单独扩展存储集群。

基于Shared-Storage后,主节点和多个只读节点共享一份存储数据,主节点刷脏不能再像传统的刷脏方式了,否则:

  1. 只读节点去存储中读取的页面,可能是比较老的版本,不符合他自己的状态。
  2. 只读节点指读取到的页面比自身内存中想要的数据要超前。
  3. 主节点切换到只读节点时,只读节点接管数据更新时,存储中的页面可能是旧的,需要读取日志重新对脏页的恢复。

对于第一个问题,我们需要有页面多版本能力;对于第二个问题,我们需要主库控制脏页的刷脏速度。

HTAP架构

读写分离后,单个计算节点无法发挥出存储侧大IO带宽的优势,也无法通过增加计算资源来加速大的查询。我们研发了基于Shared-Storage的MPP分布式并行执行,来加速在OLTP场景下OLAP查询。 PolarDB支持一套OLTP场景型的数据在如下两种计算引擎下使用:

  • 单机执行引擎:处理高并发的OLTP型负载。
  • 分布式执行引擎:处理大查询的OLAP型负载。

image.png

在使用相同的硬件资源时性能达到了传统Greenplum的90%,同时具备了SQL级别的弹性:在计算能力不足时,可随时增加参与OLAP分析查询的CPU,而数据无需重分布。

PolarDB - 存储计算分离架构

Shared-Storage带来的挑战

基于Shared-Storage之后,数据库由传统的share nothing,转变成了shared storage架构。需要解决如下问题:

  • 数据一致性:由原来的N份计算+N份存储,转变成了N份计算+1份存储。
  • 读写分离:如何基于新架构做到低延迟的复制。
  • 高可用:如何Recovery和Failover。
  • IO模型:如何从Buffer-IO向Direct-IO优化。

架构原理

image.png

首先来看下基于Shared-Storage的PolarDB的架构原理。

  • 主节点为可读可写节点(RW),只读节点为只读(RO)。
  • Shared-Storage层,只有主节点能写入,因此主节点和只读节点能看到一致的落盘的数据。
  • 只读节点的内存状态是通过回放WAL保持和主节点同步的。
  • 主节点的WAL日志写到Shared-Storage,仅复制WAL的meta给只读节点。
  • 只读节点从Shared-Storage上读取WAL并回放。

数据一致性

传统数据库的内存状态同步

传统share nothing的数据库,主节点和只读节点都有自己的内存和存储,只需要从主节点复制WAL日志到只读节点,并在只读节点上依次回放日志即可,这也是复制状态机的基本原理。

基于Shared-Storage的内存状态同步

前面讲到过存储计算分离后,Shared-Storage上读取到的页面是一致的,内存状态是通过从Shared-Storage上读取最新的WAL并回放得来,如下图:

image.png

  1. 主节点通过刷脏把版本200写入到Shared-Storage。
  2. 只读节点基于版本100,并回放日志得到200。

基于Shared-Storage的“过去页面”

上述流程中,只读节点中基于日志回放出来的页面会被淘汰掉,此后需要再次从存储上读取页面,会出现读取的页面是之前的老页面,称为“过去页面”。如下图:

image.png

  1. T1时刻,主节点在T1时刻写入日志LSN=200,把页面P1的内容从500更新到600;
  2. 只读节点此时页面P1的内容是500;
  3. T2时刻,主节点将日志200的meta信息发送给只读节点,只读节点得知存在新的日志;
  4. T3时刻,此时在只读节点上读取页面P1,需要读取页面P1和LSN=200的日志,进行一次回放,得到P1的最新内容为600;
  5. T4时刻,只读节点上由于BufferPool不足,将回放出来的最新页面P1淘汰掉;
  6. 主节点没有将最新的页面P1为600的最新内容刷脏到Shared-Storage上;
  7. T5时刻,再次从只读节点上发起读取P1操作,由于内存中已把P1淘汰掉了,因此从Shared-Storage上读取,此时读取到了“过去页面”的内容;

“过去页面” 的解法

只读节点在任意时刻读取页面时,需要找到对应的Base页面和对应起点的日志,依次回放。如下图:

image.png

  1. 在只读节点内存中维护每个Page对应的日志meta。
  2. 在读取时一个Page时,按需逐个应用日志直到期望的Page版本。
  3. 应用日志时,通过日志的meta从Shared-Storage上读取。

通过上述分析,需要维护每个Page到日志的“倒排”索引,而只读节点的内存是有限的,因此这个Page到日志的索引需要持久化,PolarDB设计了一个可持久化的索引结构 - LogIndex。LogIndex本质是一个可持久化的hash数据结构。

  1. 只读节点通过WAL receiver接收从主节点过来的WAL meta信息。
  2. WAL meta记录该条日志修改了哪些Page。
  3. 将该条WAL meta插入到LogIndex中,key是PageID,value是LSN。
  4. 一条WAL日志可能更新了多个Page(索引分裂),在LogIndex对有多条记录。
  5. 同时在BufferPool中给该该Page打上outdate标记,以便使得下次读取的时候从LogIndex重回放对应的日志。
  6. 当内存达到一定阈值时,LogIndex异步将内存中的hash刷到盘上。


image.png

通过LogIndex解决了刷脏依赖“过去页面”的问题,也是得只读节点的回放转变成了Lazy的回放:只需要回放日志的meta信息即可。

基于Shared-Storage的“未来页面”

在存储计算分离后,刷脏依赖还存在“未来页面”的问题。如下图所示:

image.png

  1. T1时刻,主节点对P1更新了2次,产生了2条日志,此时主节点和只读节点上页面P1的内容都是500。
  2. T2时刻, 发送日志LSN=200给只读节点。
  3. T3时刻,只读节点回放LSN=200的日志,得到P1的内容为600,此时只读节点日志回放到了200,后面的LSN=300的日志对他来说还不存在。
  4. T4时刻,主节点刷脏,将P1最新的内容700刷到了Shared-Storage上,同时只读节点上BufferPool淘汰掉了页面P1。
  5. T5时刻,只读节点再次读取页面P1,由于BufferPool中不存在P1,因此从共享内存上读取了最新的P1,但是只读节点并没有回放LSN=300的日志,读取到了一个对他来说超前的“未来页面”。
  6. “未来页面”的问题是:部分页面是未来页面,部分页面是正常的页面,会到时数据不一致,比如索引分裂成2个Page后,一个读取到了正常的Page,另一个读取到了“未来页面”,B+Tree的索引结构会被破坏。

“未来页面”的解法

“未来页面”的原因是主节点刷脏的速度超过了任一只读节点的回放速度(虽然只读节点的Lazy回放已经很快了)。因此,解法就是对主节点刷脏进度时做控制:不能超过最慢的只读节点的回放位点。如下图所示:

image.png

  1. 只读节点回放到T4位点。
  2. 主节点在刷脏时,对所有脏页按照LSN排序,仅刷在T4之前的脏页(包括T4),之后的脏页不刷。
  3. 其中,T4的LSN位点称为“一致性位点”。

低延迟复制

传统流复制的问题

  1. 同步链路:日志同步路径IO多,网络传输量大。
  2. 页面回放:读取和Buffer修改慢(IO密集型 + CPU密集型)。
  3. DDL回放:修改文件时需要对修改的文件加锁,而加锁的过程容易被阻塞,导致DDL慢。
  4. 快照更新:RO高并发引起事务快照更新慢。

如下图所示:

image.png

  1. 主节点写入WAL日志到本地文件系统中。
  2. WAL Sender进程读取,并发送。
  3. 只读节点的WAL Receiver进程接收写入到本地文件系统中。
  4. 回放进程读取WAL日志,读取对应的Page到BufferPool中,并在内存中回放。
  5. 主节点刷脏页到Shared Storage。

可以看到,整个链路是很长的,只读节点延迟高,影响用户业务读写分离负载均衡。

优化1 - 只复制Meta

因为底层是Shared-Storage,只读节点可直接从Shared-Storage上读取所需要的WAL数据。因此主节点只把WAL日志的元数据(去掉Payload)复制到只读节点,这样网络传输量小,减少关键路径上的IO。如下图所示:

image.png

  1. WAL Record是由:Header,PageID,Payload组成。
  2. 由于只读节点可以直接读取Shared-Storage上的WAL文件,因此主节点只把 WAL 日志的元数据发送(复制)到只读节点,包括:Header,PageID。
  3. 在只读节点上,通过WAL的元数据直接读取Shared-Storage上完整的WAL文件。

通过上述优化,能显著减少主节点和只读节点间的网络传输量。从下图可以看到网络传输量减少了98%。

image.png

优化2 - 页面回放优化

在传统DB中日志回放的过程中会读取大量的Page并逐个日志Apply,然后落盘。该流程在用户读IO的关键路径上,借助存储计算分离可以做到:如果只读节点上Page不在BufferPool中,不产生任何IO,仅仅记录LogIndex即可。

可以将回放进程中的如下IO操作offload到session进程中:

  1. 数据页IO开销。
  2. 日志apply开销。
  3. 基于LogIndex页面的多版本回放。

如下图所示,在只读节点上的回放进程中,在Apply一条WAL的meta时:

image.png

  1. 如果对应Page不在内存中,仅仅记录LogIndex。
  2. 如果对应的Page在内存中,则标记为Outdate,并记录LogIndex,回放过程完成。
  3. 用户session进程在读取Page时,读取正确的Page到BufferPool中,并通过LogIndex来回放相应的日志。
  4. 可以看到,主要的IO操作有原来的单个回放进程offload到了多个用户进程。

通过上述优化,能显著减少回放的延迟,比AWS Aurora快30倍。

image.png

优化3 - DDL锁回放优化

在主节点执行DDL时,比如:drop table,需要在所有节点上都对表上排他锁,这样能保证表文件不会在只读节点上读取时被主节点删除掉了(因为文件在Shared-Storage上只有一份)。在所有只读节点上对表上排他锁是通过WAL复制到所有的只读节点,只读节点回放DDL锁来完成。

而回放进程在回放DDL锁时,对表上锁可能会阻塞很久,因此可以通过把DDL锁也offload到其他进程上来优化回访进程的关键路径。

image.png

通过上述优化,能够回放进程一直处于平滑的状态,不会因为去等DDL而阻塞了回放的关键路径。

image.png

上述3个优化之后,极大的降低了复制延迟,能够带来如下优势:

  • 读写分离:负载均衡,更接近Oracle RAC使用体验。
  • 高可用:加速HA流程。
  • 稳定性:最小化未来页的数量,可以写更少或者无需写页面快照。

Recovery优化

背景

数据库OOM、Crash等场景恢复时间长,本质上是日志回放慢,在共享存储Direct-IO模型下问题更加突出。

image.png

Lazy Recovery

前面讲到过通过LogIndex我们在只读节点上做到了Lazy的回放,那么在主节点重启后的recovery过程中,本质也是在回放日志,那么我们可以借助Lazy回放来加速recovery的过程:

image.png

  1. 从checkpoint点开始逐条去读WAL日志。
  2. 回放完LogIndex日志后,即认为回放完成。
  3. recovery完成,开始提供服务。
  4. 真正的回放被offload到了重启之后进来的session进程中。

优化之后(回放500MB日志量):

image.png

Persistent BufferPool

上述方案优化了在recovery的重启速度,但是在重启之后,session进程通过读取WAL日志来回放想要的page。表现就是在recovery之后会有短暂的响应慢的问题。优化的办法为在数据库重启时BufferPool并不销毁,如下图所示:crash和restart期间BufferPool不销毁。

image.png

内核中的共享内存分成2部分:

  1. 全局结构,ProcArray等。
  2. BufferPool结构;其中BufferPool通过具名共享内存来分配,在进程重启后仍然有效。而全局结构在进程重启后需要重新初始化。

image.png

而BufferPool中并不是所有的Page都是可以复用的,比如:在重启前,某进程对Page上X锁,随后crash了,该X锁就没有进程来释放了。因此,在crash和restart之后需要把所有的BufferPool遍历一遍,剔除掉不能被复用的Page。另外,BufferPool的回收依赖k8s。

该优化之后,使得重启前后性能平稳。

image.png

PolarDB - HTAP架构

PolaDB读写分离后,由于底层是存储池,理论上IO吞吐是无限大的。而大查询只能在单个计算节点上执行,单个计算节点的CPU/MEM/IO是有限的,因此单个计算节点无法发挥出存储侧的大IO带宽的优势,也无法通过增加计算资源来加速大的查询。我们研发了基于Shared-Storage的MPP分布式并行执行,来加速在OLTP场景下OLAP查询。

HTAP架构原理

PolarDB底层存储在不同节点上是共享的,因此不能直接像传统MPP一样去扫描表。我们在原来单机执行引擎上支持了MPP分布式并行执行,同时对Shared-Storage进行了优化。 基于Shared-Storage的MPP是业界首创,它的原理是:

  1. Shuffle算子屏蔽数据分布。
  2. ParallelScan算子屏蔽共享存储。

image.png

如图所示:

  1. 表A和表B做join,并做聚合。
  2. 共享存储中的表仍然是单个表,并没有做物理上的分区。
  3. 重新设计4类扫描算子,使之在扫描共享存储上的表时能够分片扫描,形成virtual partition。

分布式优化器

基于社区的GPORCA优化器扩展了能感知共享存储特性的Transformation Rules。使得能够探索共享存储下特有的Plan空间,比如:对于一个表在PolarDB中既可以全量的扫描,也可以分区域扫描,这个是和传统MPP的本质区别。

图中,上面灰色部分是PolarDB内核与GPORCA优化器的适配部分。

下半部分是ORCA内核,灰色模块是我们在ORCA内核中对共享存储特性所做的扩展。

image.png

算子并行化

PolarDB中有4类算子需要并行化,下面介绍一个具有代表性的Seqscan的算子的并行化。为了最大限度的利用存储的大IO带宽,在顺序扫描时,按照4MB为单位做逻辑切分,将IO尽量打散到不同的盘上,达到所有的盘同时提供读服务的效果。这样做还有一个优势,就是每个只读节点只扫描部分表文件,那么最终能缓存的表大小是所有只读节点的BufferPool总和。

image.png

下面的图表中:

  1. 增加只读节点,扫描性能线性提升30倍。
  2. 打开Buffer时,扫描从37分钟降到3.75秒。

image.png

消除数据倾斜问题

倾斜是传统MPP固有的问题:

  1. 在PolarDB中,大对象的是通过heap表关联TOAST表,无论对哪个表切分都无法达到均衡。
  2. 另外,不同只读节点的事务、buffer、网络、IO负载抖动。

以上两点会导致分布执行时存在长尾进程。

image.png

  1. 协调节点内部分成DataThread和ControlThread。
  2. DataThread负责收集汇总元组。
  3. ControlThread负责控制每个扫描算子的扫描进度。
  4. 扫描快的工作进程能多扫描逻辑的数据切片。
  5. 过程中需要考虑Buffer的亲和性。

需要注意的是:尽管是动态分配,尽量维护buffer的亲和性;另外,每个算子的上下文存储在worker的私有内存中,Coordinator不存储具体表的信息;

下面表格中,当出现大对象时,静态切分出现数据倾斜,而动态扫描仍然能够线性提升。

image.png

SQL级别弹性扩展

那我们利用数据共享的特点,还可以支持云原生下极致弹性的要求:把Coordinator全链路上各个模块所需要的外部依赖存在共享存储上,同时worker全链路上需要的运行时参数通过控制链路从Coordinator同步过来,使Coordinator和worker无状态化。

image.png

因此:

  1. SQL连接的任意只读节点都可以成为Coordinator节点,这解决了Coordinator单点问题。
  2. 一个SQL能在任意节点上启动任意worker数目,达到算力能SQL级别弹性扩展,也允许业务有更多的调度策略:不同业务域同时跑在不同的节点集合上。

image.png

事务一致性

多个计算节点数据一致性通过等待回放和globalsnapshot机制来完成。等待回放保证所有worker能看到所需要的数据版本,而globalsnapshot保证了选出一个统一的版本。

image.png

TPCH性能 - 加速比

image.png

我们使用1TB的TPCH进行了测试,首先对比了PolarDB新的分布式并行和单机并行的性能:有3个SQL提速60倍,19个SQL提速10倍以上;

image.png

另外,使用分布式执行引擎测,试增加CPU时的性能,可以看到,从16核和128核时性能线性提升; 单看22条SQL,通过该增加CPU,每个条SQL性能线性提升。

TPCH性能 - 和Greenplum的对比

和传统MPP的Greenplum的对比,同样使用16个节点,PolarDB的性能是Greenplum的90%。

image.png

前面讲到我们给PolarDB的分布式引擎做到了弹性扩展,数据不需要充分重分布,当dop=8时,性能是Greenplum的5.6倍。

分布式执行加速索引创建

OLTP业务中会建大量的索引,经分析建索引过程中:80%是在排序和构建索引页,20%在写索引页。通过使用分布式并行来加速排序过程,同时流水化批量写入。

image.png

上述优化能够使得创建索引有4~5倍的提升。

image.png

分布式并行执行加速多模 - 时空数据库

PolarDB是对多模数据库,支持时空数据。时空数据库是计算密集型和IO密集型,可以借助分布式执行来加速。我们针对共享存储开发了扫描共享RTREE索引的功能。

image.png

  • 数据量:40000万,500 GB
  • 规格:5个只读节点,每个节点规格为16 核CPU、128 GB 内存
  • 性能:
  • 随CPU数目线性提升
  • 共80核CPU时,提升71倍

image.png

总结

本文从架构层面分析了PolarDB的技术要点:

  • 存储计算分离架构。
  • HTAP架构。

后续文章将具体讨论更多的技术细节,比如:如何基于Shared-Storage的查询优化器,LogIndex如何做到高性能,如何闪回到任意时间点,如何在Shared-Storage上支持MPP,如何和X-Paxos结合构建高可用等等,敬请期待。

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
3天前
|
关系型数据库 分布式数据库 数据库
【PolarDB开源】PolarDB与微服务架构的融合:灵活扩展与高效管理
【5月更文挑战第23天】阿里云PolarDB是适用于微服务的高性能分布式数据库,提供数据分片、水平扩展及高可用性解决方案。通过SQL或API实现弹性扩展,内置故障转移保障服务连续性,且兼容MySQL协议,易于集成微服务生态。通过Spring Boot示例展示了PolarDB的配置与集成过程,强调其在现代云原生应用中的重要角色。
10 1
|
3天前
|
存储 关系型数据库 MySQL
PolarDB-X 存储引擎核心技术 | 索引回表优化
数据库系统为了高效地存储、检索和维护数据,采用了多种不同的数据组织结构。不同的组织结构有其特定的用途和优化点,比如提高查询速度、优化写入性能、减少存储空间等,目前 PolarDB-X 采用了 B-Tree 的索引组织结构。
|
5天前
|
监控 关系型数据库 分布式数据库
【PolarDB 开源】PolarDB HTAP 实践:混合事务与分析处理的性能优化策略
【5月更文挑战第21天】PolarDB开源后在HTAP领域表现出色,允许在同一系统处理事务和分析工作负载,提高数据实时性。通过资源分配、数据分区、索引优化等策略提升性能。示例代码展示了创建和查询事务及分析表的基本操作。PolarDB还提供监控工具,帮助企业优化系统并应对业务变化。其HTAP能力为开发者和企业提供了强大支持,推动技术进步,加速数字化时代的业务发展。
21 1
|
6天前
|
存储 关系型数据库 分布式数据库
【PolarDB开源】深入PolarDB内核:探究存储计算分离架构的设计哲学
【5月更文挑战第20天】PolarDB是阿里巴巴的云原生分布式数据库,以其存储计算分离架构为核心,解决了传统数据库的扩展性和资源灵活性问题。该架构将数据存储和计算处理分开,实现高性能(通过RDMA加速数据传输)、高可用性(多副本冗余保证数据可靠性)和灵活扩展(计算资源独立扩展)。通过动态添加计算节点以应对业务流量变化,PolarDB展示了其在云时代应对复杂业务场景的能力。随着开源项目的进展,PolarDB将持续推动数据库技术发展。
35 6
|
1天前
|
关系型数据库 Serverless 分布式数据库
【PolarDB 开源】PolarDB Serverless 模式:自动扩缩容与成本效益分析
【5月更文挑战第25天】PolarDB Serverless 提供自动扩缩容功能,适应动态工作负载,降低成本。在业务高峰期增加资源保障性能,低谷期减少资源实现成本优化。通过对比传统模式下的成本浪费,示例说明了Serverless如何节省开支。代码演示了连接与查询PolarDB Serverless数据库的基本操作。要充分利用该模式,需合理规划业务、监控性能并结合其他云服务。PolarDB Serverless是弹性、经济的数据库选择,未来将持续创新,助力企业高效发展。
10 1
|
1天前
|
关系型数据库 分布式数据库 数据处理
【PolarDB 开源】PolarDB 在大数据分析中的应用:海量数据处理方案
【5月更文挑战第25天】PolarDB是解决大数据挑战的关键技术,以其高性能和可扩展性处理大规模数据。通过与数据采集和分析工具集成,构建高效数据生态系统。示例代码显示了PolarDB如何用于查询海量数据。优化策略包括数据分区、索引、压缩和分布式部署,广泛应用于电商、金融等领域,助力企业进行精准分析和决策。随着大数据技术进步,PolarDB将继续发挥关键作用,创造更多价值。
7 0
|
2天前
|
弹性计算 编解码 运维
飞天技术沙龙回顾:业务创新新选择,倚天Arm架构深入探讨
基于「倚天710自研芯片+CIPU云原生基础设施处理器」组合的倚天ECS实例为解决算力挑战提供新思路。
|
2天前
|
关系型数据库 分布式数据库 数据库
【阿里云云原生专栏】云原生时代的数据库选型:阿里云RDS与PolarDB对比分析
【5月更文挑战第24天】阿里云提供RDS和PolarDB两种数据库服务。RDS是高性能的在线关系型数据库,支持MySQL等引擎,适合中小规模需求;而PolarDB是分布式数据库,具备高扩展性和性能,适用于大规模数据和高并发场景。RDS与PolarDB在架构、性能、弹性伸缩、成本等方面存在差异,开发者应根据具体需求选择。示例代码展示了如何通过CLI创建RDS和PolarDB实例。
185 0
|
3天前
|
弹性计算 编解码 运维
飞天技术沙龙回顾:业务创新新选择,倚天Arm架构深入探讨
阿里云、平头哥与Arm联合举办的飞天技术沙龙在上海举行,聚焦Arm Neoverse核心优势和倚天710计算实例在大数据、视频领域的应用。活动中,专家解读了倚天710的性能提升和成本效益,强调了CIPU云原生基础设施处理器的角色,以及如何通过软件优化实现资源池化和稳定性平衡。实例展示在视频编码和大数据处理上的性能提升分别达到80%和70%的性价比优化。沙龙吸引众多企业代表参与,促进技术交流与实践解决方案的探讨。
飞天技术沙龙回顾:业务创新新选择,倚天Arm架构深入探讨
|
4天前
|
存储 关系型数据库 分布式数据库
【PolarDB开源】PolarDB高可用架构解析:确保业务连续性的关键设计
【5月更文挑战第22天】阿里云PolarDB是一款高可用、高性能的云原生数据库,采用分布式共享存储架构实现计算与存储分离。通过主从复制保证数据实时同步,当主节点故障时,从节点能快速接管。此外,PolarDB提供自动故障转移和数据备份恢复功能,确保业务连续性和数据安全性。一个简单的Python SDK使用示例展示了查询数据的过程。总之,PolarDB通过多种机制保障了企业在异常情况下的服务稳定和数据完整性。
17 5

相关产品

  • 云原生数据库 PolarDB