VACUUM ANALYZE ปกติยังคงแนะนำภายใต้ 9.1 หรือไม่

ฉันใช้ PostgreSQL 9.1 บน Ubuntu VACUUM ANALYZEยังมีกำหนดการแนะนำหรือมีระบบตอบโต้อัตโนมัติเพียงพอที่จะดูแลทุกความต้องการได้หรือไม่?

หากคำตอบคือ "มันขึ้นอยู่กับ" แล้ว:

• ฉันมีฐานข้อมูลขนาดใหญ่ (ขนาดการถ่ายโอนข้อมูลบีบอัด 30 GiB, ไดเรกทอรีข้อมูล 200 GiB)
• ฉันทำ ETL ลงในฐานข้อมูลนำเข้าใกล้ 3 ล้านแถวต่อสัปดาห์
• ตารางที่มีการเปลี่ยนแปลงบ่อยที่สุดนั้นสืบทอดมาจากตารางต้นแบบโดยไม่มีข้อมูลในตารางต้นแบบ (ข้อมูลถูกแบ่งพาร์ติชันเป็นรายสัปดาห์)
• ฉันสร้างการเปิดตัวรายชั่วโมงและจากที่นั่นรายงานรายวันรายสัปดาห์และรายเดือน

ฉันถามเพราะกำหนดVACUUM ANALYZEส่งผลกระทบต่อการรายงานของฉัน มันใช้เวลานานกว่า 5 ชั่วโมงและฉันต้องฆ่ามันสองครั้งในสัปดาห์นี้เพราะมันส่งผลกระทบต่อการนำเข้าฐานข้อมูลปกติ check_postgresไม่ได้รายงานการขยายตัวที่สำคัญในฐานข้อมูลดังนั้นจึงไม่ใช่ปัญหา

จากเอกสาร, autovacuum ควรดูแล ID ธุรกรรมที่มีการห่อหุ้มด้วย คำถามที่ยืน: ฉันยังคงต้องVACUUM ANALYZE?

VACUUM จำเป็นสำหรับการปรับปรุงหรือลบแถวในตารางที่ไม่ใช่แบบชั่วคราวเท่านั้น เห็นได้ชัดว่าคุณกำลังทำ INSERT จำนวนมาก แต่ไม่ชัดเจนจากคำอธิบายที่คุณกำลังทำ UPDATE หรือ DELETE จำนวนมาก

การดำเนินการเหล่านี้สามารถติดตามได้ด้วยpg_stat_all_tablesมุมมองเฉพาะn_tup_updและn_tup_delคอลัมน์ ยิ่งไปกว่านั้นยังมีn_dead_tupคอลัมน์ที่บอกต่อตารางจำนวนแถวที่ต้องดูดฝุ่น (ดูการตรวจสอบสถิติในเอกสารสำหรับฟังก์ชั่นและมุมมองที่เกี่ยวข้องกับการรวบรวมสถิติ)

กลยุทธ์ที่เป็นไปได้ในกรณีของคุณคือการระงับ VACUUM ที่กำหนดไว้คอยจับตาดูมุมมองนี้และตรวจสอบว่าตารางn_dead_tupใดกำลังจะขึ้นอย่างมีนัยสำคัญ จากนั้นใช้ VACUUM เชิงรุกกับตารางเหล่านี้เท่านั้น นี่จะเป็นชัยชนะหากมีตารางขนาดใหญ่ที่ไม่เคยลบหรือปรับปรุงแถวและ VACUUM ที่ก้าวร้าวมีความจำเป็นจริง ๆ สำหรับโต๊ะเล็ก ๆ เท่านั้น

แต่ยังคงใช้งาน ANALYZE ต่อไปเพื่อให้เครื่องมือเพิ่มประสิทธิภาพมีสถิติใหม่อยู่เสมอ

ฉันไม่เห็นสิ่งใดในคำถามของคุณที่autovacuumจะไม่ดูแล ส่วนใหญ่จะขึ้นอยู่กับรูปแบบของกิจกรรมการเขียนของคุณ คุณพูดถึง 3 ล้านแถวใหม่ต่อสัปดาห์ แต่โดยทั่วไปINSERT(หรือCOPY) จะไม่สร้างตารางและดัชนีขยายตัว ( autovacuumเพียง แต่มีการดูแลของสถิติคอลัมน์ที่แผนที่การมองเห็นและบางงานเล็ก ๆ น้อย ๆ ) UPDATEและDELETEเป็นสาเหตุสำคัญของตารางและดัชนีขยายตัวโดยเฉพาะอย่างยิ่งเมื่อกำหนดเป้าหมายแถวแบบสุ่ม ฉันไม่เห็นสิ่งใดในคำถามของคุณ

autovacuumมาไกลแล้วและทำงานได้ดีใน Postgres 9.1 หรือใหม่กว่า ฉันจะมีลักษณะที่มีการตั้งค่าautovacuum ถ้าดูดฝุ่นมีแนวโน้มที่จะยุ่งเกี่ยวกับภาระงานของคุณยังมีลักษณะที่"ค่าใช้จ่ายตามความล่าช้าเครื่องดูดฝุ่น" การดูดด้วยมือควรเป็นข้อยกเว้นที่หายาก

หากคุณมีจำนวนมากสุ่มUPDATEs คุณอาจต้องการที่จะตั้งค่าFILLFACTORกับสิ่งที่ต่ำกว่า 100 เพื่อให้การปรับปรุง HOT VACUUMทันทีและลดความจำเป็นในการ เพิ่มเติมเกี่ยวกับการปรับปรุง HOT:

• ข้อมูลที่ซ้ำซ้อนในงบปรับปรุง

ยังทราบว่าตารางชั่วคราวต้องคู่มือและVACUUM ANALYZEฉันพูดคู่มือในCREATE TABLE :

ภูต autovacuumไม่สามารถเข้าถึงและดังนั้นจึงไม่สามารถสูญญากาศหรือวิเคราะห์ตารางชั่วคราว ด้วยเหตุผลนี้การดำเนินการสูญญากาศและการวิเคราะห์ที่เหมาะสมควรดำเนินการผ่านคำสั่ง SQL เซสชัน ตัวอย่างเช่นหากจะใช้ตารางชั่วคราวในคิวรีที่ซับซ้อนคุณควรรันANALYZEบนตารางชั่วคราวหลังจากเติมข้อมูลแล้ว

แม้ว่าฉันจะยอมรับว่าการใช้คุณสมบัติอัตโนมัตินั้นดีที่สุดแทนที่จะใช้เป็นฐานข้อมูลกว้าง แต่ในกรณีส่วนใหญ่การปรับแต่งตารางต่อไปเป็นสิ่งที่จำเป็น

ฉันไม่เห็นด้วยกับตัวเลือกการออกแบบของ postgres เพื่อรวมสุญญากาศและวิเคราะห์เข้าด้วยกันฉันได้เห็นหลาย ๆ กรณีที่ฐานข้อมูลที่มีการแทรก / อัปเดตจำนวนมาก แต่การลบเพียงเล็กน้อยนั้นไม่เคยวิเคราะห์เสร็จ

วิธีแก้ไขคือเข้าไปในตารางที่มีการใช้งานอย่างหนักและอยู่ภายใต้ข้อความค้นหาจำนวนมากและตั้งค่าการวิเคราะห์อัตโนมัติสำหรับตารางเหล่านั้นลงไปที่สิ่งที่พวกเขาได้รับการวิเคราะห์วันละครั้งหรือทุก ๆ วัน

คุณสามารถไปที่การตั้งค่าต่อตารางใน gui บนแท็บสูญญากาศอัตโนมัติและคุณจะเห็นการวิเคราะห์การตั้งค่าที่คุณสามารถตั้งค่าได้โดยอิสระจากสุญญากาศ

การตั้งค่าสิ้นสุดลงในตาราง reloptions และสามารถมองเห็นได้ด้วยแบบสอบถาม

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

และค่าตัวอย่างของการวิเคราะห์เชิงรุกอาจจะเป็น

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

หากต้องการดูว่าตารางครั้งล่าสุดของคุณได้รับข้อความวิเคราะห์อัตโนมัติเมื่อใด

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;