# 14.4.填充数据库
在首次填充数据库时,可能需要插入大量数据。本节包含一些关于如何使此过程尽可能高效的建议。
# 14.4.1.禁用自动提交
当使用多个插入
s、 关闭自动提交,只在最后执行一次提交。(在普通SQL中,这意味着开始
一开始犯罪
最后。有些客户端库可能会在你背后这样做,在这种情况下,你需要确保库在你想做的时候做。)如果允许单独提交每个插入,PostgreSQL将为添加的每一行做大量工作。在一个事务中执行所有插入的另一个好处是,如果插入一行失败,那么插入到该点的所有行都将回滚,因此您不会被部分加载的数据卡住。
# 14.4.2.使用复制
使用复制
在一个命令中加载所有行,而不是使用一系列插入
命令。这个复制
命令针对加载大量行进行了优化;它不如以前灵活插入
,但对于大数据负载,开销要小得多。自从复制
是单个命令,如果使用此方法填充表格,则无需禁用自动提交。
如果你不能使用复制
,使用准备
创建一个插入
语句,然后使用处决
需要多少次就多少次。这避免了重复解析和规划的一些开销插入
.不同的接口以不同的方式提供该设施;在接口文档中查找“准备好的语句”。
请注意,使用复制
几乎总是比使用插入
即使准备
并将多个插入批处理到单个事务中。
复制
在同一事务中使用时最快创建表格
或截断
命令在这种情况下,不需要写入WAL,因为如果出现错误,包含新加载数据的文件将被删除。然而,这种考虑仅适用于以下情况:沃尔_数量是最小的
因为所有命令都必须写WAL,否则。
# 14.4.3.删除索引
如果要加载新创建的表,最快的方法是创建表,使用复制
,然后创建表所需的任何索引。在预先存在的数据上创建索引比在加载每一行时增量更新要快。
如果要向现有表中添加大量数据,则删除索引、加载表,然后重新创建索引可能是一种成功。当然,在索引丢失期间,其他用户的数据库性能可能会受到影响。在删除唯一索引之前,还应该三思而后行,因为唯一约束提供的错误检查将在索引丢失时丢失。
# 14.4.4.删除外键约束
与索引一样,与逐行检查相比,可以“批量”更有效地检查外键约束。因此,删除外键约束、加载数据并重新创建约束可能很有用。同样,在缺少约束的情况下,在数据加载速度和错误检查丢失之间存在一种折衷。
此外,当您将数据加载到具有现有外键约束的表中时,每一新行都需要服务器的挂起触发器事件列表中的一个条目(因为触发触发器检查该行的外键约束)。加载数百万行可能会导致触发器事件队列溢出可用内存,导致无法忍受的交换,甚至命令彻底失败。因此可能是这样必需的,而不仅仅是希望在加载大量数据时删除并重新应用外键。如果暂时删除约束是不可接受的,那么唯一的其他方法可能是将加载操作拆分为较小的事务。
# 14.4.5.增加维护工作记忆
暂时增加维修_工作_记忆加载大量数据时的配置变量可以提高性能。这将有助于加快速度创建索引
命令和ALTER TABLE ADD外键
命令。这对我来说没什么用复制
因此,只有当您使用上述一种或两种技术时,此建议才有用。
# 14.4.6.增加最大尺寸
暂时增加最大值_沃尔_大小配置变量还可以加快大数据的加载速度。这是因为将大量数据加载到PostgreSQL中会导致检查点出现的频率高于正常检查点频率(由检查点超时
配置变量)。每当出现检查点时,所有脏页都必须刷新到磁盘。通过增加最大尺寸
在批量数据加载期间,可以暂时减少所需的检查点数量。
# 14.4.7.禁用WAL存档和流式复制
在将大量数据加载到使用WAL存档或流式复制的安装中时,在加载完成后进行新的基本备份可能比处理大量增量WAL数据更快。要在加载时防止增量WAL日志记录,请通过设置沃尔_数量到最小的
, 档案文件_模式到关
和最大值_沃尔_寄件人归零。但请注意,更改这些设置需要重新启动服务器,并使以前进行的任何基本备份都无法用于存档恢复和备用服务器,这可能会导致数据丢失。
除了避免存档者或WAL发送者处理WAL数据的时间外,这样做实际上会加快某些命令的速度,因为如果瓦卢层
是最小的
当前子事务(或顶级事务)创建或截断了它们更改的表或索引。(他们可以通过做一个简单的测试,以更低廉的成本保证碰撞安全。)同步
最后比写沃尔还难。)
# 14.4.8.跑分析
之后
每当您显著改变了表中的数据分布时,运行分析
强烈推荐。这包括将大量数据批量加载到表中。跑步分析
(或真空分析
)确保计划员拥有关于表的最新统计信息。如果没有统计信息或过时的统计信息,规划人员可能会在查询规划过程中做出错误的决策,从而导致在统计信息不准确或不存在的任何表上性能不佳。请注意,如果启用了autovacuum守护程序,它可能会运行分析
自动地看见第25.1.3节和第25.1.6节了解更多信息。
# 14.4.9.关于pg的几点注记_倾倒
转储pg生成的脚本_dump会自动应用以上几个准则,但不是全部准则。重新加载pg_尽快转储转储,您需要手动执行一些额外的操作。(请注意,这些要点适用于恢复垃圾场,不是暂时的创建信息技术无论是使用psql加载文本转储还是使用pg加载文本转储,都适用相同的要点_从pg还原到加载_转储存档文件。)
默认情况下,pg_垃圾场使用复制
,当它生成完整的模式和数据转储时,在创建索引和外键之前要小心地加载数据。因此,在这种情况下,会自动处理几个准则。你要做的是:
设置适当(即大于正常值)的
维护工作记忆
和最大尺寸
.如果使用WAR归档或流复制,请考虑在还原期间禁用它们。要做到这一点,设置
存档模式
到关
,瓦卢层
到最小的
和max_wal_senders
在加载转储之前将其设置为零。之后,将它们设置回正确的值,并进行新的基本备份。使用两种pg的并行转储和恢复模式进行实验_转储和pg_恢复并找到要使用的最佳并发作业数。通过
-j
与串行模式相比,该选项应能显著提高性能。考虑是否将整个转储恢复为单个事务。要做到这一点,请通过
-1
或--单笔交易
psql或pg的命令行选项_恢复使用此模式时,即使是最小的错误也会回滚整个恢复,可能会放弃许多小时的处理。取决于数据之间的关联程度,这似乎比手动清理更可取,或者不可取。复制
如果使用单个事务并关闭WAL存档,则命令运行速度最快。如果数据库服务器中有多个CPU,请考虑使用PG。_恢复
--工作
选项这允许同时加载数据和创建索引。跑
分析
之后仅数据转储仍将使用
复制
,但它不会删除或重新创建索引,并且通常不会触摸外键。[14]因此,当加载一个只包含数据的转储文件时,如果您希望使用这些技术,您可以删除并重新创建索引和外键。这仍然是有用的增加最大尺寸
加载数据时,但不要费心增加维护工作记忆
; 相反,您可以在手动重新创建索引和外键之后再这样做。别忘了分析
当你完成时;看见第25.1.3节和第25.1.6节了解更多信息。