Greenplum 数据库最佳实践

所需积分/C币:31 2019-04-30 10:39:15 946KB PDF
15
收藏 收藏
举报

Greenplum最佳实践;通过掌握这些最佳实践知识,会增加GPDB集群在维护、支持、性能和可扩展性等方面的成功率
使用 statement mem控制节点数据库为单个查询分配的内存量 使用资源队列设置队列允许的当前最大査询数( ACTIVE STATEMENTS)和允许使用的内存大小( MEMORY LIM|T)。 不要使用默认的资源队列,为所有用户都分配资源队列 根据负载和时间段,设置和队列实际需求相匹氈的优先级( PRIORITY 保证资源队列的内存配额不超过 gp vme_ protect limit 动态更新资源队列配置以适应日常工作需要。 详见内存和负载管理(后续章为 分区 只为大表设置分区,不要为小表设置分区。 仪在根据查询条件可以实现分区裁剪时使用分区表 建议优先使用范围( Range)分区,否则使用列表(List)分区。 根据查询特点合理设置分区。 不要使用相同的字段即做分区键又做分布键。 不要使用默认分区 避免使用多级分区;尽量创建少量的分区,每个分区的数据更多些 通过查询计划的 EXPLAIN结果来验证查询对分区表执行的是选择性扫描(分区裁剪) ·对于列存储的表,不要创建过多的分区,否则会造成物理文件过多: Physical files= Segments Columns* Partitions 详见分区(后续章为 索引 般来说GPDB中索引不是必需的 对于高基数的列存储表,如果需要遍历且査询选择性较高,则创建单列索引。 频繁吏新的列不要建立索引。 在加载大量数据之前删除索引,加载结束后再重新创建索引。 优先使用B树索引。 不要为需要频繁更新的字段创建位图索引。 不要为唯一性字段,基数非常高或者非常低的字段创建位图索引。 不要为事务性负载创建位图索引。 般来说不要索引分区表。如果需要建立索引,则选择与分区键不同的字段。 详见索引(后续章为 资源队列 使用瓷源队列管理集群的负载。 为所有角色定义适当的资源队列 使用 ACTIVE STATEMENTS参数限制队列成员可以并发运行的查询总数。 使用 MEMORY LIM参数限制队列中查询可以使用的内存总量。 不要设置所有队列为 MEDIUM,这样起不到管理负载的作用 根据负载和时间段动态调整资源队列。 详见配置资源队列(后续章 监控和维护 根据《 Greenplu数据库管理员指南》实现该书推荐的监控和管理仼务。 安装Greηplum数据库前建议运行 gpcheckpert,安装后定期运行。保存输出结果,随着时间推移对系统性能进行比较。 使用所有您可用的工具,以了解系统不同负载下的表现 检查任何不寻常的事件并确定原因 通过定期运行解释计划监控系统査询活动,以确保査询处于最仹运行状态。 检查查询计划,以确定是否按预期使用了索引和进行了分区裁剪。 了解系统日志文件的位置和内容,定期监控日志文件,而不是在出现问题时才査看. 详见系统监控和维护以及监控GPDB口志文件。(后续章为 ANALYZE 不要对整个数据库运行 ANALYZE,只对需要的表运行该命令。 建议数据加载后即刻运行 anAlYZE。 如果 NSERT、 UPDATE和 DELETE等操作修改大量数据,建议运行 ANALYZE。 执行 CREATE INDE操作后建议运行 anAlYZE ·如果对大表 ANALYZE耗时很久,则只对」oN字段、 WHERE、SORT、 GROUP BY或 HAVING宇句的字段运行 ANALYZE。 详见使用 ANAlYZE更新统计信息。(后续章 Vaccum 批量 UPDATE和 DELETE操作后建议执行 VACUUM 不建议使用 VACUUM FULL。建议使用CTAS( CREATE TABLE.AS)操作,然后重命名表名,并删除原来的表 对系统表定期运行 VACUUM,以避免系统表臃肿和在系统表上执行∨ ACUUM FULL操作 禁止杀死系统表的 ACUUM任务。 ·不建议使用 VACUUM ANALYZE。 详见消除系统表臃肿。(后绥章为 加载 使用 gpfdist进行数据的加载和导出。 随着段数据库个数的增加,并行性增加。 尽量将数据均匀地分布到多个ETL节点上。 将非常大的数据文件切分成相同大小的块,并放在尽量多的文件系统上。 个文科系统运行两个 gpfdist实例 在尽可能多的网络接口上运行 gpfdsit 使用gp_ external max_segs控制访问每个 gpfdist服务器的段数据库的个数。 建议 gp external_max_segs的值和 gpfdist进程个数为偶数。 数据加载前删除索引:加载完后重建索引。 ·数据加载完成后运行 anAlYzE操作。 数据加载过程中,设置 gp autostats mode为NoNE,取消统计信息的自动收集 ·若数据加载失败,使用 VACUUM回收空间 详见加载数据。(后续章为 transfer 为了更好的性能,建议使用 gptransfer迁移数据到相同大小或者更大的集群。 避免使用-Ⅷ或者- schema-ony选项。建议使用其他方法拷叭数据库模式到目标数据库,然后迁移数据 迁移数据前删除索引,迁移完成后重建索引。 使用 SQL COPY命令迁移小表到目标数据厍。 使用 transfer批量近移大表 在正式迁移产环境前测试运行 transfer。试验- batch-size和-sub- batch-size选项以获得最人平行度。如果需要,迭代运行多次 transfer来确定每次要迁移的 表的批次。 仅使用完全限定的表名。表名字中若含有点、空格、单引号和双引号,可能会导致问题 如果使用- validation选项在迁移后验证数据,则需要同时使用ⅹ选项,以在源表上加排它锁 确保在目标数据库上创建了相应的角色、函数和资源队列。 gptransfer-t不会迁移这些对象 从源数据库拷贝 postgres.conf和 pg hba.conf到目标数据库集群。 ·使用 gppkg在目标数据库上安装需要的扩展 详见使用 gptransfer迁移数据(后章犭 安全 妥善保护 gpadmin账号,只有在必要的时候才能允许系统管理员访问它。 仅当执行系统维护任务(例如升级或扩容),管理员才能以 gpadmin登录 Greenplum集群 ·限具有 SUPERUSER角色属性的用户数。GPDB中,身为超级用户的角色会跳过所有访问权限检查和资源队列限制。仅有系统管理员具有数捃库超级用户权限。 参考《 Greenplum数据库管理员指南》中的“修改角色属性”。 严禁数据库用户以 gpadmin身份登录,严禁以 gpadmin身份执行EL或者牛产仟务 为有登录需求的每个用户都分酤一个不同的角色。 考虑为每个应用或者网络服务分配一个不同的角色 使用用户组管理访问权限。 保护好ROOT的密码。 对于操作系统密码,强制使用强密码策略。 确保保扩好操作系统的重要文件。 详见安全。(后续章力 加密 加密和解密数据会影响性能,仅加密需要加密的数据。 在牛产系统中实现任何加密解决方案之前都要做性能测试。 ·GPDB生产系统使用的服务器证书应由证书签名颁发机构(CA)签名,这样客户端可以验证服务器。如果所有客户端都是本地的,则可以使用本地CA 如果客户端与GPDB的连接会经过不安全的链路,则使用SSL加密。 加密和解密使用相冋密钥的对称加密方式比非对称加密具有更好的性能,如果密钥可以安全共享,则建议使用对称加密方式。 使用 pgcrypto包中的函数加密磁盘上的数据。数据的加密和解密都由数据斥进程完成,为了避免传输明文数据,需要使用SsL加密客户端和数据斥间的连接 数据加载和导出时,使用 gpfdists协议保护ETL数据安全。 详见加密数据和数据库连接。(后续章为 高可用 ·使用8到24个磁盘的硬件RAD存储解决方案 ·使用RAD1、5或6,以使磁盘阵列可以容忍磁盘故障。 为磁盘阵列配备热备磁盘,以便在检测到磁盘故障时自动开始重建。 在重建时通过RAD眷镜像防止整个磁盘阵列故障和性能下降。 ·定期监控磁盘利用率,并在需要吋增加额外的空间。 ·定期监控段数据库倾斜,以确保在所有段数据库上数据均匀分布,存储空间均匀消耗 酤置备用主服务器,当主服务器发生故障时由备用主服务器接管 规划好当主服务器发生故障时如何切换客户端连接到新的主服务器实例,例如通过更新DNS中主服务器的地址 建立监控系统,当主服务器发生故障时,可以通过系统监控应用或电子邮件发送通知。 分酤主段数据库和其镜像到不同的主机上,以防止主机故障。 建立监控系统,当主段数据库发生故障时,可以通过系统监控应用或电子邮件发送通知。 使用 gprecoverseg工具及时恢复故障段,并使系统返最佳半衡状态。 在主服务器上配置并运行 gpsnmpd以发送SNMP通知给网络监控器。 在 MAster_DATA_ DIRECTORY/ postgresql. conf配置文件中设置邮件通知,以便检测到关键问题时, Greenplum系统可以通过电子邮件通知管理员。 考虑双集群配置,提供额外的冗余和查询处理能力 除非 Greenplum数据库的数据很容易从数据源恢复,否则定期备份 ·如果堆表相对较小,或者两次备份之间仅有少量AO或列存储分区有变化,则使用增量备份 如果备份保存在集群的本地存储系统上,则备份结束后,将文件移到其他的安全存储系统上 如果备份保存到NFS中,则建议使用像 EMC Isilon这样的可扩展NFS方案以防止Jo瓶颈。 · Greenplum集成了对EMC的 Data domain z和 Symantec的 NetBackup的支持,可以沇式备份到 Data domain或 NetBackup企业备份平台上 详见高可用性(后纹章为 《 Greenplum数据库最佳实践》第二章 原创2016-03-04燃延栋刘套图 Pivotal中国研发中心 Pivotal中国研发中 第二章系统配置 本节描述了 Greenplum数据库集群关于主机配置的需求和最佳实践 ◆首选操作系统 红帽企业级LinuⅨx(RHEL)是首选操作系统。应使用最新支持的主版本,目前是RHEL6 ◆文件系统 Greenplum数据库的数据目录推荐使用XFS文件系统。使用以下选项挂载XFS: rw, noatime inode64, allocsize=16m ◆端口配置 ip_ocal_ port range的设置不要和 Greenplum数据库的端凵范围有冲突,例如: net. ipv4. ip local_ _port range =3000 65535 PORT BASE=2000 MIRROR PORT BASE=2100 REPLICATION PORT BASE=2200 MIRROR REPLICATION PORT BASE=2300 ◆Ⅳ/O配置 包含数据目录的设备的预读大小应设为16384 /sbin/blockdev--getra/dev/sdb 16384 包含数据日录的改备的/O调度算法设置为 deadline. cat/sys/block/sdbqueue/scheduler noop anticipatory [deadline] cfq 通过/etc/ security/ limits. conf增大操作系统文件数和进程数 来 soft nofile65536 hard nofile 65536 soft nproc 131072 本 hard nproc131072 后用core文件转储,并保存到已知位置。确保 limits. conf中允许的core转储文件 kernel. core_pattern =/var/core/ core. %h %t grep core/etc/security/limits. conf soft core unlimited ◆操作系统内存配置 Linux sysctl的wm. overcommit memory和wm. overcommit ratio变量会影响操作系统对内存分軋的管理。这些变量应该设置如下 ·wm. overcommit memoryγ控制操作系统使用什么方法确定分配给进程的内存总数。对于 Greerηplum数据库,唯一建议值是2. ·Ⅶm. overcommit ratio控制分配给应用程序进程的内存百分比。建议使用缺省佶50 不要启用操作系统的大内存页。 详见内存和负载管理。(后续章为 ◆共享内存设置 Greenplum数据库中同一数据库实例的不同 postgres进稈间通讯使用共享内存。使用 sysctl配置如下共享内存参数,且不建议修改: kernelshmmax=500000000 kernel. shmmni=4096 kernel.shmall= 4000000000 ◆验证操作系统 使用 gpcheck验证操作系统配置。参考《 Greenplum数据库工具指南》中的 gpcheck ◆设置一个主机上段数据库个数 确定每个段主机上段数据库的个数对整体性能有着巨大影响。这些段数据库之间共享主机的C吣U核、内存、网卡等,且和主机上的所有进程共亨这些资源。过高地估讠 每个服务器上运行的段数据库个数,通常是达不到最优性能的常见原因之一。 以下因素确定了一个主机上可以运行多少个段数据库 CPU核的个数 物理内存容量 网卡个数及速度 存储空间 主段数据库和镜像共存 主机是否运行ETL进程 ·主机上运行的非 Greenplum进程 ◆段服务器内存配置 服务器配置参数 gp vmem_ protect limit控制了每个段数据库为所有运行的査询分配的内存总量。如果査询需要的内存超过此值,则会失败。使用下面公式确定合适的 值: (swap+(RAM*vm overcommit ratio ))*. 9/number of Segments per server 例如,具有下面配置的段服务器 8GB交换空间 128GB内存 vm, overcommit ratio=50 8个段数据库 则设置 gp vmem protect limit为8GB: (8+(128*5)*9/8=8GB 参见内存和负载管理。(后续章刀 ◆SQL语句内存配置 服务器配置参数gp_ statement mem控制段数据库上单个查询可以使用的内存总量。如果语句需要更多内存,则会溢出数据到磁盘。用下面公式确定合适的值: (gp vmem_ protect limit *. 9)/max expected concurrent queries 例如,如果并发度为40, gp vmeme_ protect limit为8GB,则 gp statement mem为: (8192MB*9)/40=184MB 每个查询最多可以使用184MB内存,之后将溢出到磁盘。 若想安全的增大g_ statement_mem,要么增大gpwmηem_ protect limit.,要么降低并发。要增大 gp vmem_ protect limit,必须増加物理内存和/或交换空间,或者降低单个 主机上运行的段数据库个数。 请注意,为集群添加更多的段数据库实例并不能解决内存不足的问题,除非引入更多新主机来降低了单个主机上运行的段数据库的个数。 了解什么是溢出文件。了解 gp workfile limit files per query参数,其控制了单个査询最多可以创建多少个溢出文件。了解 gp workfile limit per Segment 有关使用资源队列管理内存的更多信息,请参考内存和负载管理。(续章为 ◆溢出文件配置 如果为sαL査询分配的内存不足, Greenplum数据库会创建溢出文件(也叫工作文件)。在默认情況下,一个SαL査询最多可以创建100000个溢岀文件,这足以满足大多 数查询 参数 gp workfile limit files per_ query决定了个査询最多可以创建多少个溢出文件。0意味着没有限制。限制溢出文件数据可以防止失控査询破坏整个系统。 如果分配内存不足或者岀现数据倾斜,则一个SαL査询可能产生大星溢出文件。如果超过溢岀文件上限, Greenplum数据库报告如下错误: ERROR: number of workfiles per query limit exceeded 在尝试增大gρ_ workfile_ limit_ files_per_ query前,先尝试通过修改SαL、数据分布策略或者内存配置以降低溢岀文件个数 gp_ toolkit模式包括一些视图,通过这些视图可以看到所有使用瀣出文件的查询的信息。这些信息有助于故障排除和调优查洵: gp workfile entriesλ图的每一行表示一个正在使用溢出文件的操作符的信息。关于操作符,参考如何理解查询计划解释。(后续章为 gp_ workfile_usage_per_ query视图的每一行表示一个正在使用溢出文件的SQL查询的信息 gp_ workfile· usage_per_ Segment视图的每一行对应一个段数据库,包含了该段上使用的溢出文件占用的磁盘空间总量 关于这些视图的宁段涵义,请参考《 Greenplum数据库参考指南》。 参数 gp workfile compress algorithm指定溢出文件的压缩算法:none或者zib

...展开详情
试读 44P Greenplum 数据库最佳实践
立即下载 低至0.43元/次 身份认证VIP会员低至7折
一个资源只可评论一次,评论内容不能少于5个字
您会向同学/朋友/同事推荐我们的CSDN下载吗?
谢谢参与!您的真实评价是我们改进的动力~
  • 分享学徒

关注 私信
上传资源赚钱or赚积分
最新推荐
Greenplum 数据库最佳实践 31积分/C币 立即下载
1/44
Greenplum 数据库最佳实践第1页
Greenplum 数据库最佳实践第2页
Greenplum 数据库最佳实践第3页
Greenplum 数据库最佳实践第4页
Greenplum 数据库最佳实践第5页
Greenplum 数据库最佳实践第6页
Greenplum 数据库最佳实践第7页
Greenplum 数据库最佳实践第8页
Greenplum 数据库最佳实践第9页

试读结束, 可继续读5页

31积分/C币 立即下载