HybridDB · 最佳实践 · HybridDB 数据合并的方法与原理

引言

刚开始使用HybridDB的用户,有个问的比较多的问题:如何快速做数据“合并”(Merge)?所谓“合并”,就是把数据新版本更新到HybridDB中。如果数据已经存在,则将它们替换为新版本;如果不存在,将它们插入数据库中。一般是离线的做这种数据合并,例如每天一次批量把数据更新到HybridDB中。也有客户需要实时的更新,即做到分钟级甚至秒级延迟。这里我们介绍一下HybridDB中数据合并的方法和背后原理。

简单更新过程

无论怎么做数据合并,都是对数据的修改,即Update、Delete、Insert、Copy等操作。我们先要了解一下HybridDB中的数据更新过程。我们以用户发起一次Update操作为例(对列存表单行记录的更新),整个流程如下图所示。

其中的步骤说明如下:

  1. 用户把Update的SQL请求发送到主节点;
  2. 主节点发起分布式事务,并对被Update的表加锁(HybridDB不允许并行的Update同一张表),然后把更新请求分发到对应的子节点。
  3. 子节点通过索引扫描,定位到要更新的数据,并更新数据。对于列存表,更新逻辑其实就是删除旧的数据行,并在表的尾端写入新的数据行。(列存表)被更新的数据页面会写入内存缓存区,对应的表文件长度的变化(因为尾端写入了数据,所以数据表对应的文件长度增大了)会写入日志(xlog文件)。
  4. 在Update命令结束前,内存中的被更新的数据页面和xlog日志,都要同步到Mirror节点。同步完成后,主节点结束分布式事务,返回用户执行成功的消息。

可以看出,整个过程的链条很长,SQL语句解析、分布式事务、锁,主节点子节点之间的连接建立、子节点与Mirror数据和日志同步等操作,都会耗费CPU或IO资源,同时拖慢整个请求的响应时间。因此,对于HybridDB来说,应该尽量避免单行数据的更新,而是尽量批量的更新数据,也就是尽量做到:

  • 尽量把更新放到一个SQL语句,减少语句解析、节点通信、数据同步等开销;
  • 尽量把更新放到一个事务,避免不必要的事务开销。

简而言之,就是数据的合并和更新,尽量以”成批“的形式进行。下面我们看看,如何批量的做数据更新。

批量Update

假如我们要Update很多独立数据行,怎么才能用一个SQL来实现呢?

我们假设有张表target_table需要做更新(称为目标表),这张表的定义如下。一般目标表都非常大,这里我们往target_table里面插入1千万数据。为了能快速更新,target_table上要有索引。这里我们定义了primary key,会隐含的创建一个唯一值索引(unique index)。

create table target_table(c1 int, c2 int, primary key (c1));

insert into target_table select generate_series(1, 10000000);

为了做批量的Update,需要用到中间表(Stage Table),其实就是为了更新数据临时创建的表。为了更新target_table的数据,可以先把新数据插入到中间表source_table中。然后,把新数据通过COPY命令、OSS外部表等方式导入到source_table。这里为简单起见,我们直接插入一些数据。

create table source_table(c1 int, c2 int);

insert into source_table select generate_series(1, 100), generate_series(1,100);

source_table数据准备好后,执行下面的update set … from … where ..语句,即可实现批量的Update。注意,为了最大限度的使用到索引,在执行Update前,要使用set opitimzer=on启用ORCA优化器(如果不启用ORCA优化器,则需要执行set enable_nestloop = on才能使用到索引)。


set optimizer=on;

update target_table set c2 = source_table.c2 from source_table where target_table.c1= source_table.c1;

这种Update的执行计划如下:

=> explain update target_table set c2 = source_table.c2 from source_table where target_table.c1= source_table.c1;
                                                         QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
 Update  (cost=0.00..586.10 rows=25 width=1)
   ->  Result  (cost=0.00..581.02 rows=50 width=26)
         ->  Redistribute Motion 4:4  (slice1; segments: 4)  (cost=0.00..581.02 rows=50 width=22)
               Hash Key: public.target_table.c1
               ->  Assert  (cost=0.00..581.01 rows=50 width=22)
                     Assert Cond: NOT public.target_table.c1 IS NULL
                     ->  Split  (cost=0.00..581.01 rows=50 width=22)
                           ->  Nested Loop  (cost=0.00..581.01 rows=25 width=18)
                                 Join Filter: true
                                 ->  Table Scan on source_table  (cost=0.00..431.00 rows=25 width=8)
                                 ->  Index Scan using target_table_pkey on target_table  (cost=0.00..150.01 rows=1 width=14)
                                       Index Cond: public.target_table.c1 = source_table.c1

可以看到,HybridDB“聪明”的选择了索引。但是,如果往source_table里面加入更多数据,优化器会认为使用Nest Loop关联方法+索引扫描,不如不使用索引高效,而是会选取Hash关联方法+表扫描方式执行。例如:

postgres=> insert into source_table select generate_series(1, 1000), generate_series(1,1000);
INSERT 0 1000
postgres=> analyze source_table;
ANALYZE
postgres=> explain update target_table set c2 = source_table.c2 from source_table where target_table.c1= source_table.c1;
                                              QUERY PLAN
------------------------------------------------------------------------------------------------------
 Update  (cost=0.00..1485.82 rows=275 width=1)
   ->  Result  (cost=0.00..1429.96 rows=550 width=26)
         ->  Assert  (cost=0.00..1429.94 rows=550 width=22)
               Assert Cond: NOT public.target_table.c1 IS NULL
               ->  Split  (cost=0.00..1429.93 rows=550 width=22)
                     ->  Hash Join  (cost=0.00..1429.92 rows=275 width=18)
                           Hash Cond: public.target_table.c1 = source_table.c1
                           ->  Table Scan on target_table  (cost=0.00..477.76 rows=2500659 width=14)
                           ->  Hash  (cost=431.01..431.01 rows=275 width=8)
                                 ->  Table Scan on source_table  (cost=0.00..431.01 rows=275 width=8)

上述批量的Update方式,减少了SQL编译、节点间通信、事务等开销,可以大大提升数据更新性能并减少对资源的消耗。

批量Delete

对于Delete操作,采用和上述批量Update类似的中间表,然后使用下面的带有“Using”子句的Delete来实现批量删除:

delete from target_table using source_table where target_table.c1 = source_table.c1;

可以看到,这种批量的Delete同样使用了索引。

explain delete from target_table using source_table where target_table.c1 = source_table.c1;
                                             QUERY PLAN
-----------------------------------------------------------------------------------------------------
 Delete (slice0; segments: 4)  (rows=50 width=10)
   ->  Nested Loop  (cost=0.00..41124.40 rows=50 width=10)
         ->  Seq Scan on source_table  (cost=0.00..6.00 rows=50 width=4)
         ->  Index Scan using target_table_pkey on target_table  (cost=0.00..205.58 rows=1 width=14)
               Index Cond: target_table.c1 = source_table.c1

利用Delete + Insert做数据合并

回到本文刚开始的问题,如何实现批量的数据合并?做数据合并时,我们先把待合入的数据放入中间表中。如果我们预先知道待合入的数据,在目标表中都已经有对应的数据行,即我们通过Update语句即可实现数据合入。但多数情况下,待合入的数据中,一部分是在目标表中已存在记录的数据,还有一部分是新增的,目标表中没有对应记录。这时候,使用一次批量的Delete + 一次批量的Insert即可:

set optimizer=on;

delete from target_table using source_table where target_table.c1 = source_table.c1;

insert into target_table select * from source_table;

利用Values()表达式做实时更新

使用中间表,需要维护中间表生命周期。有的用户想实时的批量更新数据到HybridDB,即持续性的同步数据或合并数据到HybridDB。如果采用上面的方法,需要反复的创建、删除(或Truncate)中间表。其实,可以利用Values表达式,达到类似中间表的效果,但不用维护表。方法是先将待更新的数据拼成一个Values表达式,然后按如下方式执行Update或Delete:

update target_table set c2 = t.c2 from (values(1,1),(2,2),(3,3),…(2000,2000)) as t(c1,c2) where target_table.c1=t.c1

delete from target_table using (values(1,1),(2,2),(3,3),…(2000,2000)) as t(c1,c2) where target_table.c1 = t.c1

注意,使用set optimizer=on;set enable_nestloop=on;都可以生成使用索引的查询计划。比较复杂的情形,比如索引字段有多个、涉及分区表等,必须要使用ORCA优化器才能匹配上索引。

总结

上面我们简单介绍了HybridDB的批量数据合并和更新的最佳实践。利用这些方法,无论是在每天一次或多次的ETL操作,还是实时更新数据的场景,都可以把HybridDB的数据更新效率充分发挥出来。

时间: 2024-11-05 20:42:53

HybridDB · 最佳实践 · HybridDB 数据合并的方法与原理的相关文章

《Greenplum5.0 最佳实践》数据导入 (六)

Loading Data INSERT 命令 使用 INSERT 命令将数据加载到表中.一行数据会根据分布键,从主节点分配到 segment 上.这是一种非常慢的方法,并不适合加载大量数据. COPY 命令 Postgresql 数据库提供的 COPY 命令实质就是将 外部文件拷贝到数据库表中, 该命令一次可以插入多行数据, 效率明显高于 INSERT 命令.但是这并不是一位置数据不需要从master 节点开始执行数据导入,依旧需要master 节点完成数据分布的计算.使用数据拷贝命令,并不意味

HybridDB最佳实践——实现OLAP和OLTP一体化打造

HybridDB(基于Greenplum)经过长达四个月时间的公测,终于开始商业化的征程.为我们客户提供计算分析能力. 在这之前,我们团队做了许多技术.产品上的打磨,其中OSS的高效访问与处理是其中较为重要的一环.这个功能可以给用户在数据流转方面带来质的变化. 缘起 在传统的OLAP方案中,链路是比较长的,数据流转的代价较为高昂.而且往往常用的数据同步工具未必能够满足需求,复杂的分析在同步上会需要一些功能的定制.而且资源的不够弹性.管理上的诸多麻烦,也带来成本的上升. 那么在云环境中,这一情况可

HybridDB · 最佳实践 · 阿里云数据库PetaData

前言 随着互联网DT时代的高速发展,业界需要简单高效的数据处理方式在海量数据中挖掘价值,企业厂商和开源界目前较流行的的做法,是提供支持类SQL接口的数据库服务,或者是提供SDK接口的数据处理平台服务. 在SQL接口的数据库服务中,传统的关系数据库,如MySQL.PG等,处理海量数据显得越来越力不从心,既无法突破单机硬件资源限制,又无法并行利用多机硬件资源:大数据NewSQL数据库,必须依赖外部数据库保证数据的事务特性,并通过数据导入工具将完整提交的数据导入进来计算,系统复杂度和成本较高. 在SD

Android应用性能优化最佳实践.2.1 Android系统显示原理

绘?制?优?化 Android应用启动慢,使用时经常卡顿,是非常影响用户体验的,应该尽量避免出现.卡顿的场景有很多,按场景可以分成4类:UI绘制.应用启动.页面跳转.事件响应,如 图2-1所示.在这四种场景下又有多个小分类,基本上覆盖了卡顿的各个场景.   图2-1 卡顿主要场景 这4种卡顿场景的根本原因又可以分成两大类. 界面绘制:主要原因是绘制的层级深.页面复杂.刷新不合理,由于这些原因导致卡顿的场景更多出现在UI和启动后的初始界面以及跳转到页面的绘制上. 数据处理:导致这种卡顿场景的原因是

PgSQL · 最佳实践 · 双十一数据运营平台订单Feed数据洪流实时分析方案

摘要 2017年的双十一又一次刷新了记录,交易创建峰值32.5万笔/秒.支付峰值25.6万笔/秒.而这样的交易和支付等记录,都会形成实时订单Feed数据流,汇入数据运营平台的主动服务系统中去. 数据运营平台的主动服务,根据这些合并后的数据,实时的进行分析,进行实时的舆情展示,实时的找出需要主动服务的对象等,实现一个智能化的服务运营平台. 通过阿里云RDS PostgreSQL和HybridDB for PGSQL实时分析方案: - 承受住了几十万笔/s的写入吞吐并做数据清洗,是交易的数倍 - 实

PostgreSQL、Greenplum DML合并操作 最佳实践

标签 PostgreSQL , Greenplum , 合并删除 , 合并更新 , 合并DML 背景 在很多场景中会涉及到数据的合并,比如 1. 某业务系统的总用户有1亿,每天的活跃用户有100万,新增用户10万,每天需要将新增.活跃用户的数据(比如他们的余额变化.等等)合并到数据仓库的用户信息表. 2. 物化视图,某个表被用户不断的增.删.改.需要将这个表(基表)的某些字段或者某部分数据提取到一个物化视图中.这个物化视图不需要对每一笔基表的DML都实施操作,比如对单条记录的操作,合并成一次操作

聚焦行业最佳实践,BDTC 2016完整议程公布

2016年12月8-10日,由中国计算机学会(CCF)主办,CCF大数据专家委员会承办,中国科学院计算技术研究所.中科天玑数据科技股份有限公司与CSDN共同协办的2016中国大数据技术大会(Big Data Technology Conference 2016,BDTC 2016)将在北京新云南皇冠假日酒店隆重举办. 中国大数据技术大会(BDTC)的前身是Hadoop中国云计算大会(Hadoop in China,HiC).从2008年仅60余人参加的技术沙龙发展到当下数千人参与,国内最具影响力

Docker 镜像优化与最佳实践

云栖TechDay41期,阿里云高级研发工程师御坂带来Docker镜像优化与最佳实践.从Docker镜像存储的原理开始,针对镜像的存储.网络传输,介绍如何在构建中对这些关键点进行优化.并介绍Docker最新的多阶段构建的功能,以解决构建依赖的中间产物问题.   以下是精彩内容整理: 镜像概念 镜像是什么?从一个比较具体的角度去看,镜像就是一个多层存储的文件,相较于普通的ISO系统镜像来说,分层存储会带来两个优点,一个是分层存储的镜像比较容易扩展,比如我们可以基于一个Ubuntu镜像去构建我们的N

每天万亿+级 实时分析、数据规整 - 阿里云HybridDB for PostgreSQL最佳实践

背景 横看成岭侧成峰, 远近高低各不同. 不识庐山真面目, 只缘身在此山中. 不同的视角我们所看到的物体是不一样的, http://t.m.china.com.cn/convert/c_ovWL9w.html 图为墨西哥城放射状的街区广场. 图为西班牙迷宫般的果树漩涡. 地心说和日心说也是视角不同所呈现的. 实际上数据也有这样,我们每天产生海量的数据,有各种属性,以每个属性为视角(分组.归类.聚合),看到的是对应属性为中心的数据. 对应的业务场景也非常多,例如: 1.物联网, 每个传感器有很多属