我希望将查询除以数百万,以实现可扩展性和并发目的,我希望使用updated_at字段获取所有数据,日期为几天前.
我已经在一百万个ID上尝试了很多索引和查询,而且我似乎无法使用Heroku的Ronin硬件在100秒内获得性能.
我正在寻找我没有尽力提高效率的建议.
尝试#1
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE (date(updated_at)) < (date(now())-7) AND id >= 5000001 AND id < 6000001;
- INDEX USED: (date(updated_at),id)
- 268578.934 ms
尝试#2
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE ((date(now()) - (date(updated_at)) > 7)) AND id >= 5000001 AND id < 6000001;
- INDEX USED: primary key
- 335555.144 ms
尝试#3
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE (date(updated_at)) < (date(now())-7) AND id/1000000 = 5;
- INDEX USED: (date(updated_at),(id/1000000))
- 243427.042 ms
尝试#4
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE (date(updated_at)) < (date(now())-7) AND id/1000000 = 5 AND updated_at IS NOT NULL;
- INDEX USED: (date(updated_at),(id/1000000)) WHERE updated_at IS NOT NULL
- 706714.812 ms
尝试#5(对于一个月的过期数据)
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE (EXTRACT(MONTH from date(updated_at)) = 8) AND id/1000000 = 5;
- INDEX USED: (EXTRACT(MONTH from date(updated_at)),(id/1000000))
- 107241.472 ms
尝试#6
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE (date(updated_at)) < (date(now())-7) AND id/1000000 = 5;
- INDEX USED: ( (id/1000000 ) ASC,updated_at DESC NULLS LAST)
- 106842.395 ms
尝试#7(见:http://explain.depesz.com/s/DQP)
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE id/1000000 = 5 and (date(updated_at)) < (date(now())-7);
- INDEX USED: ( (id/1000000 ) ASC,date(updated_at) DESC NULLS LAST);
- 100732.049 ms
- Second try: 87280.728 ms
尝试#8
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE (date(updated_at)) < (date(now())-7) AND id/1000000 = 5 AND updated_at IS NOT NULL;
- INDEX USED: ( (id/1000000 ) ASC,date(updated_at) ASC NULLS LAST);
- 129133.022 ms
尝试#9(部分索引根据欧文的建议,见:
http://explain.depesz.com/s/p9A)
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE id BETWEEN 5000000 AND 5999999 AND (date(updated_at)) < '2012-10-23'::date;
- INDEX USED: (date(updated_at) DESC NULLS LAST)
- WHERE id BETWEEN 5000000 AND 6000000 AND date(updated_at) < '2012-10-23'::date;
- 73861.047 ms
尝试#10(根据Erwin的建议,CLUSTER).
- CREATE INDEX ix_8 on objects ( (id/1000000 ) ASC,date(updated_at) DESC NULLS LAST);
- CLUSTER entities USING ix_8;
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE id/1000000 = 5 and (date(updated_at)) < (date(now())-7) ;
- 4745.595 ms
- EXPLAIN ANALYZE SELECT count(*) FROM objects
- WHERE id/1000000 = 10 and (date(updated_at)) < (date(now())-7) ;
- 17573.639 ms
==>这个解决方案似乎是赢家.我必须彻底测试以验证我的应用程序中的所有反击.
数据库设置:
从pg_settings中选择name,min_val,max_val,boot_val;
- name | min_val | max_val | boot_val
- --------------------------------+-----------+--------------+-------------------
- allow_system_table_mods | | | off
- application_name | | |
- archive_command | | |
- archive_mode | | | off
- archive_timeout | 0 | 2147483647 | 0
- array_nulls | | | on
- authentication_timeout | 1 | 600 | 60
- autovacuum | | | on
- autovacuum_analyze_scale_factor | 0 | 100 | 0.1
- autovacuum_analyze_threshold | 0 | 2147483647 | 50
- autovacuum_freeze_max_age | 100000000 | 2000000000 | 200000000
- autovacuum_max_workers | 1 | 536870911 | 3
- autovacuum_naptime | 1 | 2147483 | 60
- autovacuum_vacuum_cost_delay | -1 | 100 | 20
- autovacuum_vacuum_cost_limit | -1 | 10000 | -1
- autovacuum_vacuum_scale_factor | 0 | 100 | 0.2
- autovacuum_vacuum_threshold | 0 | 2147483647 | 50
- backslash_quote | | | safe_encoding
- bgwriter_delay | 10 | 10000 | 200
- bgwriter_lru_maxpages | 0 | 1000 | 100
- bgwriter_lru_multiplier | 0 | 10 | 2
- block_size | 8192 | 8192 | 8192
- bonjour | | | off
- bonjour_name | | |
- bytea_output | | | hex
- check_function_bodies | | | on
- checkpoint_completion_target | 0 | 1 | 0.5
- checkpoint_segments | 1 | 2147483647 | 3
- checkpoint_timeout | 30 | 3600 | 300
- checkpoint_warning | 0 | 2147483647 | 30
- client_encoding | | | sql_ASCII
- client_min_messages | | | notice
- commit_delay | 0 | 100000 | 0
- commit_siblings | 1 | 1000 | 5
- constraint_exclusion | | | partition
- cpu_index_tuple_cost | 0 | 1.79769e+308 | 0.005
- cpu_operator_cost | 0 | 1.79769e+308 | 0.0025
- cpu_tuple_cost | 0 | 1.79769e+308 | 0.01
- cursor_tuple_fraction | 0 | 1 | 0.1
- custom_variable_classes | | |
- DateStyle | | | ISO,MDY
- db_user_namespace | | | off
- deadlock_timeout | 1 | 2147483 | 1000
- debug_assertions | | | off
- debug_pretty_print | | | on
- debug_print_parse | | | off
- debug_print_plan | | | off
- debug_print_rewritten | | | off
- default_statistics_target | 1 | 10000 | 100
- default_tablespace | | |
- default_text_search_config | | | pg_catalog.simple
- default_transaction_isolation | | | read committed
- default_transaction_read_only | | | off
- default_with_oids | | | off
- effective_cache_size | 1 | 2147483647 | 16384
- effective_io_concurrency | 0 | 1000 | 1
- enable_bitmapscan | | | on
- enable_hashagg | | | on
- enable_hashjoin | | | on
- enable_indexscan | | | on
- enable_material | | | on
- enable_mergejoin | | | on
- enable_nestloop | | | on
- enable_seqscan | | | on
- enable_sort | | | on
- enable_tidscan | | | on
- escape_string_warning | | | on
- extra_float_digits | -15 | 3 | 0
- from_collapse_limit | 1 | 2147483647 | 8
- fsync | | | on
- full_page_writes | | | on
- geqo | | | on
- geqo_effort | 1 | 10 | 5
- geqo_generations | 0 | 2147483647 | 0
- geqo_pool_size | 0 | 2147483647 | 0
- geqo_seed | 0 | 1 | 0
- geqo_selection_bias | 1.5 | 2 | 2
- geqo_threshold | 2 | 2147483647 | 12
- gin_fuzzy_search_limit | 0 | 2147483647 | 0
- hot_standby | | | off
- ignore_system_indexes | | | off
- integer_datetimes | | | on
- IntervalStyle | | | postgres
- join_collapse_limit | 1 | 2147483647 | 8
- krb_caseins_users | | | off
- krb_srvname | | | postgres
- lc_collate | | | C
- lc_ctype | | | C
- lc_messages | | |
- lc_monetary | | | C
- lc_numeric | | | C
- lc_time | | | C
- listen_addresses | | | localhost
- lo_compat_privileges | | | off
- local_preload_libraries | | |
- log_autovacuum_min_duration | -1 | 2147483 | -1
- log_checkpoints | | | off
- log_connections | | | off
- log_destination | | | stderr
- log_disconnections | | | off
- log_duration | | | off
- log_error_verbosity | | | default
- log_executor_stats | | | off
- log_hostname | | | off
- log_line_prefix | | |
- log_lock_waits | | | off
- log_min_duration_statement | -1 | 2147483 | -1
- log_min_error_statement | | | error
- log_min_messages | | | warning
- log_parser_stats | | | off
- log_planner_stats | | | off
- log_rotation_age | 0 | 35791394 | 1440
- log_rotation_size | 0 | 2097151 | 10240
- log_statement | | | none
- log_statement_stats | | | off
- log_temp_files | -1 | 2147483647 | -1
- log_timezone | | | UNKNOWN
- log_truncate_on_rotation | | | off
- logging_collector | | | off
- maintenance_work_mem | 1024 | 2097151 | 16384
- max_connections | 1 | 536870911 | 100
- max_files_per_process | 25 | 2147483647 | 1000
- max_function_args | 100 | 100 | 100
- max_identifier_length | 63 | 63 | 63
- max_index_keys | 32 | 32 | 32
- max_locks_per_transaction | 10 | 2147483647 | 64
- max_prepared_transactions | 0 | 536870911 | 0
- max_stack_depth | 100 | 2097151 | 100
- max_standby_archive_delay | -1 | 2147483 | 30000
- max_standby_streaming_delay | -1 | 2147483 | 30000
- max_wal_senders | 0 | 536870911 | 0
- password_encryption | | | on
- port | 1 | 65535 | 5432
- post_auth_delay | 0 | 2147483647 | 0
- pre_auth_delay | 0 | 60 | 0
- random_page_cost | 0 | 1.79769e+308 | 4
- search_path | | | "$user",public
- segment_size | 131072 | 131072 | 131072
- seq_page_cost | 0 | 1.79769e+308 | 1
- server_encoding | | | sql_ASCII
- server_version | | | 9.0.8
- server_version_num | 90008 | 90008 | 90008
- session_replication_role | | | origin
- shared_buffers | 16 | 1073741823 | 1024
- silent_mode | | | off
- sql_inheritance | | | on
- ssl | | | off
- ssl_renegotiation_limit | 0 | 2097151 | 524288
- standard_conforming_strings | | | off
- statement_timeout | 0 | 2147483647 | 0
- superuser_reserved_connections | 0 | 536870911 | 3
- synchronize_seqscans | | | on
- synchronous_commit | | | on
- syslog_facility | | | local0
- syslog_ident | | | postgres
- tcp_keepalives_count | 0 | 2147483647 | 0
- tcp_keepalives_idle | 0 | 2147483647 | 0
- tcp_keepalives_interval | 0 | 2147483647 | 0
- temp_buffers | 100 | 1073741823 | 1024
- temp_tablespaces | | |
- TimeZone | | | UNKNOWN
- timezone_abbreviations | | | UNKNOWN
- trace_notify | | | off
- trace_recovery_messages | | | log
- trace_sort | | | off
- track_activities | | | on
- track_activity_query_size | 100 | 102400 | 1024
- track_counts | | | on
- track_functions | | | none
- transaction_isolation | | |
- transaction_read_only | | | off
- transform_null_equals | | | off
- unix_socket_group | | |
- unix_socket_permissions | 0 | 511 | 511
- update_process_title | | | on
- vacuum_cost_delay | 0 | 100 | 0
- vacuum_cost_limit | 1 | 10000 | 200
- vacuum_cost_page_dirty | 0 | 10000 | 20
- vacuum_cost_page_hit | 0 | 10000 | 1
- vacuum_cost_page_miss | 0 | 10000 | 10
- vacuum_defer_cleanup_age | 0 | 1000000 | 0
- vacuum_freeze_min_age | 0 | 1000000000 | 50000000
- vacuum_freeze_table_age | 0 | 2000000000 | 150000000
- wal_block_size | 8192 | 8192 | 8192
- wal_buffers | 4 | 2147483647 | 8
- wal_keep_segments | 0 | 2147483647 | 0
- wal_level | | | minimal
- wal_segment_size | 2048 | 2048 | 2048
- wal_sender_delay | 1 | 10000 | 200
- wal_sync_method | | | fdatasync
- wal_writer_delay | 1 | 10000 | 200
- work_mem | 64 | 2097151 | 1024
- xmlbinary | | | base64
- xmloption | | | content
- zero_damaged_pages | | | off
- (195 rows)
I want to fetch all data with the updated_at field with a date of a
few days ago.
但你的WHERE条件是:
- (date(updated_at)) < (date(now())-7)
不应该是>?
索引
为了获得最佳性能,您可以……
>分区索引
>从索引中排除不相关的行
>使用更新的谓词在非工作时间自动重新创建索引.
您的索引可能如下所示:
- CREATE INDEX objects_id_updated_at_idx (updated_at::date DESC NULLS LAST)
- WHERE id BETWEEN 0 AND 999999
- AND updated_at > '2012-10-01 0:0'::timestamp -- some minimum date
- CREATE INDEX objects_id_updated_at_idx (updated_at::date DESC NULLS LAST)
- WHERE id BETWEEN 1000000 AND 1999999
- AND updated_at > '2012-10-01 0:0'::timestamp -- some minimum date
…
第二个条件立即从索引中排除不相关的行,这应该使它更小更快 – 取决于您的实际数据分布.根据我的初步评论,我假设你想要更新的行.
该条件还会自动排除updated_at中的NULL值 – 您似乎在表中允许这些值,并且显然希望在查询中排除.指数的有用性随着时间的推移而恶化.查询始终检索最新条目.定期使用更新的WHERE子句重新创建索引.这需要在桌子上进行独占锁定,所以在非工作时间进行.还有CREATE INDEX CONCURRENTLY以最小化锁定的持续时间:
- CREATE INDEX CONCURRENTLY objects_id_up_201211_idx; -- create new idx
- DROP INDEX objects_id_up_201210_idx; -- then drop old
关于SO的相关答案:
> Postgres returns records in wrong order
为了进一步优化,您可以像我们在评论中提到的那样使用CLUSTER
.但是你需要一个完整的索引.不适用于部分索引.你会暂时创建:
- CREATE INDEX objects_full_idx (id/1000000,updated_at::date DESC NULLS LAST);
完整索引的这种形式匹配上面部分索引的排序顺序.
- CLUSTER objects USING objects_full_idx;
- ANALYZE objects;
这需要一段时间,因为表是物理重写的.它实际上也是真空.它需要在桌子上进行独占的写锁定,所以在非工作时间进行 – 如果您可以负担得起的话.同样,存在一种侵入性较小的替代方案:pg_repack
然后,您可以再次删除索引.这是一次性的影响.我至少会尝试一次,看看你的查询能从中获益多少.随后的写入操作会使效果恶化.如果你看到相当大的影响,你可以在非工作时间重复这个程序.
如果您的表收到大量写入操作,则必须权衡此步骤的成本和收益.对于许多UPDATE,请考虑将FILLFACTOR
设置为低于100.在CLUSTER之前执行此操作.
询问
- SELECT count(*)
- FROM objects
- WHERE id BETWEEN 0 AND 999999 -- match conditions of partial index!
- AND updated_at > '2012-10-01 0:0'::timestamp
- AND updated_at::date > (now()::date - 7)
更多
这个相关的答案提出了一种更先进的索引分区技术:
> Can spatial index help a “range – order by – limit” query
Postgresql 9.2为您提供了几项新功能.仅凭Index-only scans就可以让你值得拥有.
确保autovacuum
正常运行.您报告的CLUSTER的巨大收益可能部分归因于您从CLUSTER获得的隐含的VACUUM FULL.也许这是由Heroku自动设置的,不确定.问题中的设置看起来不错.所以这可能不是问题,CLUSTER真的很有效.