greenplum

角色权限及客户端认证管理 GP数据库逻辑结构 在GP中，Database（ 数据库 ）、Schema（模式）以及Role（角色）三者之间的关系如下所示： 一个数据库下可以有多个模式，一个模式只属于一个数据库。模式在GP中也被称为Namespace，不同数据库之间的模式没有关系，可以重名； 语言在使用之前必须创建，一个语言只属于一个数据库； 表、视图、索引、序列、函数必须属于一个模式； 一个文件空间可以有多个表空间，一个表空间只属于一个文件空间，文件空间和角色之间没有关系； 表空间和表时一对多的关系，一个模式下的表可以分布在多个表空间下； 除了文件空间之外，其他的权限管理都是通过角色来实现，在这些层次结构中，用户必须对上一层有访问权限才能够访问该层的内容； 什么是角色(role) Role的组成：由用户(User)和组(Group)组成； 跟OS的role没有关系； User通过Master节点登录和认证的； Role是定义在GPDB系统级别的； 初始化SUPERUSERROLE：gpadmin。 角色与权限安全的最佳实践 保护系统gpadmin的用户； 为每个登录的User分配不同的角色； 使用组来管理权限从而实现管理组； 控制具备SUPERUSER属性的User数量。 创建Role 创建用户User Role 使用CREATE ROLE创建一个User Role，语法如下所示：

Greenplum是一个大规模并行处理数据库，它由一个master和多个segment组成，其数据按照设定的分布策略分布于各个segment上。数据表的单个行会被分配到一个或多个segment上，但是有这么多的segment，它到底会被分到哪个或哪些segment上呢？分布策略会告诉我们。 分布策略 在Greenplum 5中，有2种分布策略： 哈希分布 随机分布 在Greenplum 6中，添加了另一个策略： 哈希分布 随机分布 复制分布 数据表的单个行会被分配到一个或多个segment上，但是有这么多的segment，它到底会被分到哪个或哪些segment上呢？分布策略会告诉我们。 哈希分布： 要使用这一策略，需要在创建表使用 “DISTRIBUTED BY（column，[...]）” 子句。 散列算法使分布键将每一行分配给特定segment。相同值的键将始终散列到同一个segment。选择唯一的分布键（例如Primary Key）将确保较均匀的数据分布。哈希分布是表的默认分布策略。 如果创建表时未提供DISTRIBUTED子句，则将PRIMARY KEY（如果表真的有的话）或表的第一个合格列用作分布键。什么类型的列是合格列呢？几何类型或用户自定义数据类型的列不能用作Greenplum分布键列。如果表中没有合格的列，则退化为随机分布策略。 但是

1.gpadmin是Greenplum的超级管理员用户，可以分创其他管理员账户 2.修改用户属性 修改用户为超级用户(默认为nosuperuser)： 修改用户拥有创建数据库的权限（默认是nocreatedb）： 修改用户登入的连接数（默认是-1无限制）： 修改密码： 其他创建用户的语法可以通过\h create role命令来查看 通过pg_roles字典查看数据库的用户信息：select rolname,oid from pg_roles; 3.创建完用户后，还需要修改pg_hba.conf文件，来赋予用户的远程登录权限，通过gpstop –u命令重新加载配置文件，使之生效。 4.键入psql -U lishuohao -h 10.10.13.89 -p 2345及密码，即可连入数据库，\c查看当前连入数据库的用户 来源： CSDN 作者： Sakolee 链接： https://blog.csdn.net/qq_36135235/article/details/104675488

一、问题描述 初始化 master standby 时（包括 "gpinitsystem -s " 和 " gpinitstandby -s "）时，屏幕标准输出报错 standby 节点启、停失败，而在debug模式下报错： [DEBUG]:-get pids cmdStr='ssh -o 'StrictHostKeyChecking no' master_s ". /home/gpadmin/greenplum/greenplum_path.sh; python -c 'from gppylib.commands import unix; print unix.getDescendentProcesses(10571)'"' had result: cmd had rc=1 completed=True halted=False stdout='' stderr='Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/gpadmin/greenplum/lib/python/gppylib/commands/unix.py", line 968, in getDescendentProcesses for p in psutil.Process(pid)

版权声明：本文由黄辉原创文章，转载请注明出处: 文章原文链接： https://www.qcloud.com/community/article/195 来源：腾云阁 https://www.qcloud.com/community 如今，多样的交易模式以及大众消费观念的改变使得数据库应用领域不断扩大，现代的大型分布式应用系统的数据膨胀也对数据库的海量数据处理能力和并行处理能力提出了更高的要求，如何在数据呈现海量扩张的同时提高处理速度和应用系统的可用性，使客户能同时得到更高的处理速度、更高的数据可用性和更大的数据集，是数据库系统面临的一个挑战。 通过TPC-H基准测试，可获得数据库单位时间内的性能处理能力，为评估数据库系统的现有性能服务水平提供有效依据，通过横向对比促进数据库系统的整体质量提升，能更好地在重大信息化工程中实现推广。 一.TPC-H原理简介 TPC-H是由TPC(Transaction Processing Performance Council)事务处理性能委员会公布的一套针对数据库决策支持能力的测试基准，通过模拟数据库中与业务相关的复杂查询和并行的数据修改操作考察数据库的综合处理能力，获取数据库操作的响应时间和每小时执行的查询数指标(QphH@Size)。 TPC-H基准模型中定义了一个数据库模型，容量可以在1GB~10000GB的8个级别中进行选择

Greenplum 数据库调优 目录 Greenplum 数据库调优 1 目录 1 1 Greenplum查询处理回顾 2 1.1 Master 把查询语句分发到segment 2 2 Greenplum数据库调优 3 2.1 系统资源 3 2.2 硬件问题 4 2.3 资源管理 5 2.3.1 查看resource queue的参数 5 2.3.2 设置临时的内存大小 6 2.3.3 当发生数据溢出时添加内存的大小 6 2.3.4 受影响的系统的参数 7 2.3.5 查看一些有用的视图 7 2.4 统计信息不准确 8 2.4.1 创建两张表 8 2.4.2 使用EXPLAIN查看执行计划 8 2.4.3 使用ANALYZE执行统计信息 9 2.4.4 以下情况都需要执行ANALYZE 10 2.5 数据倾斜 10 2.5.1 数据倾斜实例 10 2.5.2 使用视图查看表的倾斜 11 2.5.3 改变数据倾斜问题 11 2.6 计算倾斜 12 2.6.1 关联条件倾斜 12 2.6.2 多计算聚集 12 2.6.3 减少计算倾斜问题 13 2.7 数据广播 13 2.7.1 查看表是不是出现了Broadcast 13 2.7.2 改变planner之后运行 14 2.7.3 修改GUC来设定优化器 14 2.8 多阶段聚集 15 2.8.1 多阶段聚集关闭的情况 15 2.8.2

Greenplum集群安装配置及最佳实践 目录 Greenplum集群安装配置及最佳实践 1 目录 1 1 总体介绍 2 1.1 硬件平衡 2 1.2 高可用 2 1.3 部署方案 2 1.3.1 Group Mirroring 部署方案 3 1.3.2 Spread Mirroring 部署方案 3 1.3.3 Group + Spread Mirroring 部署方案 4 2 硬件选型 4 2.1 Master 节点 4 2.1.1 网卡 4 2.1.2 内存 4 2.1.3 磁盘 4 2.1.4 CPU 5 2.2 Segment 节点 5 2.2.1 网卡 5 2.2.2 内存 5 2.2.3 磁盘 5 2.2.4 CPU 5 2.3节点配置实例 6 2.4硬件配置经验总结 6 3 硬件配置 7 1主机配置实例 7 2 磁盘的配置 7 3 网络配置 8 4 交换机配置 8 4 储存规划 9 4.1 磁盘可用空间 9 4.2 用户数据容量 9 4.3 系统数据容量 10 5 集群的配置 10 5.1 最低系统要求 10 5.2 系统设置 11 5.3 操作系统参数设置 11 5.4 I/O设置 12 5.5 其他设置 13 6 集群安装 13 6.1 安装方式 13 6.2 数据库目录 14 7 集群验证 14 7.1 硬件性能验证 14 7.2 集群初始化 15 7.3

Greenplum 架构和核心引擎 Greenplum 架构和核心引擎 1 学习地址 2 1 Greenplum 架构概述 2 1.1 概述简介 2 1.2 MPP无共享静态拓扑 3 1.3 集群内数据分两类 3 1.4 对用户透明 4 1.5 用户数据表 4 1.6 系统表/数据字典 5 1.7 数据分布:并行化处理的根基 5 1.8 多态储存:根据数据温度选择最佳的储存方式 6 1.8.1 行储存 6 1.8.2 列储存 6 1.8.3 外部表 6 2 Greenplum SQL的执行过程 7 2.1 系统空闲状态 7 2.2 客户端建立会话链接 7 2.3 Master fork一个进程处理客户端请求 8 2.4 QD建立和Segment的链接 8 2.5 segment fork 一个子进程处理QD的链接请求 9 2.6 客户端发送查询请求给QD 10 2.7 QD发送任务给QE 10 2.8 QD与QEs建立数据通信通道 11 2.9 QE各司其职 11 2.10 QE状态管理 12 2.11 QD返回查询结果给客户端 12 3 Greenplum 主要设计思考 13 3.1 继承自 PostgreSQL 的设计 13 3.2 主从架构 13 3.3 数据储存 14 3.4 数据通信 14 3.5 三级并行计算 15 3.6 流水线执行 15 3.7 网络 16 3.8