Greenplum Sequence机制

Sequence(序列)是数据库经常使用自增列属性,对于单机PostgreSQL实例,数据库维护一个自增变量即可。但是对于Greenplum的MPP架构,如果每个节点都维护自己的Sequence,那么Sequence将会出现重复,那么Greenplum是如何处理的呢?

如何使用Sequence

create table test_sequence(id serial, name text);
 
postgres=> \d
public | test_sequence | table | postgres
public | test_sequence_id_seq | sequence | postgres

postgres=> insert into test_sequence (name) values(1);
INSERT 0 1
postgres=> insert into test_sequence (name) values(2);
INSERT 0 1
postgres=> insert into test_sequence (name) values(3);
INSERT 0 1
postgres=> select * from test_sequence;
 id | name
----+------
  3 | 3
  1 | 1
  2 | 2
(3 rows)

Sequence是谁维护

查看Master的Sequence维护元信息

postgres=> select * from test_sequence_id_seq;
    sequence_name     | last_value | increment_by |      max_value      | min_value | cache_value | log_cnt | is_cycled | is_called
----------------------+------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
 test_sequence_id_seq |          3 |            1 | 9223372036854775807 |         1 |           1 |      30 | f         | t
(1 row)

查看Segment的Sequence维护元信息

postgres=> select * from gp_dist_random('test_sequence_id_seq');
    sequence_name     | last_value | increment_by |      max_value      | min_value | cache_value | log_cnt | is_cycled | is_called
----------------------+------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
 test_sequence_id_seq |          1 |            1 | 9223372036854775807 |         1 |           1 |       1 | f         | f
 test_sequence_id_seq |          1 |            1 | 9223372036854775807 |         1 |           1 |       1 | f         | f
 test_sequence_id_seq |          1 |            1 | 9223372036854775807 |         1 |           1 |       1 | f         | f
 test_sequence_id_seq |          1 |            1 | 9223372036854775807 |         1 |           1 |       1 | f         | f
(4 rows)

通过Master和Segment的元信息可以看出,只有Master一直更新元信息,Segment的Sequence元信息一直不变,所以Sequence是由Master维护的。

Sequence分配过程

如何所示,Master上有一个seqserver进程,专门用来维护全局的Sequence信息。所有的Segment获取最新的Sequence都需要向Master的seqserver请求,然后seqserver更新Sequence云信息,返回给Segment。为了实现Sequence,Master和Segment多了一次交互,这样会影响性能,建议应用层生成自增值。

时间: 2024-12-23 05:40:21

Greenplum Sequence机制的相关文章

GPDB · 特性分析· GreenPlum FTS 机制

前言 FTS(Fault Tolerance Serve)是GreenPlum中的故障检测服务,是保证GP高可用的核心功能.GreenPlum的Segment的健康检测及HA是由GP Master实现的,GP Master上面有个专门的进程–FTS进程,它可以快速检测到Primary或者Mirror是否挂掉,并及时作出Primary/Mirror 故障切换.如果FTS挂掉了,Master将会重新fork出来一个FTS进程. FTS实现原理 GP Master上面的FTS进程每隔60s(时间可以配

Zookeeper,etcd,consul内部机制和分布式锁和选主实现的比较

我的另外3篇文章分别介绍了Zookeeper,etcd,consul是如何实现分布式锁和选主的.本文想比较一下Zookeeper.etcd.consul内部机制有哪些不同,他们实现锁和选主的方式相同和不同. Zookeeper提供了临时节点,sequence,和变更通知.利用Zookeeper的这3个特性实现了按照sequence的顺序依次获取锁和成为主. etcd没有临时节点的概念,但是通过租约的方式提供了类似的功能.etcd没有sequence的概念,但是提供了全局递增的序列号revisio

数据库相关中间件收录集

数据库中间件 这里主要介绍互联网行业内有关数据库的相关中间件.数据库相关平台主要解决以下三个方面的问题: 为海量前台数据提供高性能.大容量.高可用性的访问 为数据变更的消费提供准实时的保障 高效的异地数据同步 应用层通过分表分库中间件访问数据库,包括读操作(Select)和写操作(update, insert和delete等,DDL, DCL).写操作会在数据库上产生变更记录,MySQL的变更记录叫binlog, Oracle的称之为redolog, 增量数据订阅与消费中间件解析这些变更,并以统

Hibernate主键生成方式 Key Generator

Hibernate主键生成方式 Key Generator 主键产生器 可选项说明: 1) assigned 主键由外部程序负责生成,无需Hibernate参与. 2) hilo 通过hi/lo 算法实现的主键生成机制,需要额外的数据库表保存主键生成历史状态. 3) seqhilo 与hilo 类似,通过hi/lo 算法实现的主键生成机制,只是主键历史状态保存在Sequence中,适用于支持Sequence的数据库,如Oracle. 4) increment 主键按数值顺序递增.此方式的实现机制

我的hibernate学习笔记(之三)

 五.Hibernate 主键策略( 上面的步骤三的一部分)       <id><generator class="主键策略" /></id>       主键:在关系数据库中,主键用来标识记录并保证每条记录的唯一性( 一般可保证全数据库唯一) .必须满足以下条件:          1)不允许为空.          2)不允许主键值重复.          3)主键值不允许改变.      1.自然主键:以有业务含义的字段为主键,称为自然主键.

GPDB · 特性分析 · Segment 修复指南

问题背景 GPDB是中央控制节点式的架构,在一个 GreenPlum 集群中,有一个 Master 节点和多个 Segment 节点.Master 是中央控制节点,Segment 是数据存放节点.所有的Segment节点平等,均由Master管理.架构如下图: GreenPlum架构图 当GP Master出现问题的时候,可以通过外部的HA监控模块发现并激活备库,Standby Master 正常后删除原来的 Master 进行重建备库. 而 Segment 的修复与此不同!由上图可知,Segm

阿里数据库内核月报:2016年03月

# 01 MySQL · TokuDB · 事务子系统和 MVCC 实现 # 02 MongoDB · 特性分析 · MMAPv1 存储引擎原理 # 03 PgSQL · 源码分析 · 优化器逻辑推理 # 04 SQLServer · BUG分析 · Agent 链接泄露分析 # 05 Redis · 特性分析 · AOF Rewrite 分析 # 06 MySQL · BUG分析 · Rename table 死锁分析 # 07 MySQL · 物理备份 · Percona XtraBacku

《UVM实战》——2.3节为验证平台加入各个组件

2.3 为验证平台加入各个组件 2.3.1 加入transaction 在2.2节中,所有的操作都是基于信号级的.从本节开始将引入reference model.monitor.scoreboard等验证平台的其他组件.在这些组件之间,信息的传递是基于transaction的,因此,本节将先引入transaction的概念. transaction是一个抽象的概念.一般来说,物理协议中的数据交换都是以帧或者包为单位的,通常在一帧或者一个包中要定义好各项参数,每个包的大小不一样.很少会有协议是以b

《UVM实战》——1.2节学了UVM之后能做什么

1.2 学了UVM之后能做什么 1.2.1 验证工程师 验证工程师能够从本书学会如下内容: 如何用UVM搭建验证平台,包括如何使用sequence机制.factory机制.callback机制.寄存器模型(register model)等. 一些验证的基本常识,将会散落在各个章节之间. UVM的一些高级功能,如何灵活地使用sequence机制.factory机制等. 如何编写代码才能保证可重用性.可重用性是目前IC界提及最多的几个词汇之一,它包含很多层次.对于个人来说,如何保证自己在这个项目写的