ขนาดฐานข้อมูลเริ่มต้นของ PostgreSQL

คำถามของฉันมี 2 ส่วน

1. มีวิธีการระบุขนาดเริ่มต้นของฐานข้อมูลใน PostgreSQL หรือไม่?
2. หากไม่มีคุณจะจัดการกับการแตกแฟรกเมนต์อย่างไรเมื่อฐานข้อมูลเติบโตขึ้นตามกาลเวลา

ฉันเพิ่งย้ายจาก MSSQL ไปยัง Postgres และหนึ่งในสิ่งที่เราทำในโลก MSSQL เมื่อสร้างฐานข้อมูลคือการระบุขนาดเริ่มต้นของฐานข้อมูลและบันทึกธุรกรรม การกระจายตัวที่ลดลงนี้และประสิทธิภาพที่เพิ่มขึ้นโดยเฉพาะอย่างยิ่งถ้าขนาด "ปกติ" ของฐานข้อมูลเป็นที่รู้จักกันล่วงหน้า

ประสิทธิภาพของฐานข้อมูลของฉันลดลงตามขนาดที่เพิ่มขึ้น ตัวอย่างเช่นปริมาณงานที่ฉันวางผ่านตามปกติใช้เวลา 10 นาที เมื่อฐานข้อมูลเติบโตขึ้นเวลานี้จะเพิ่มขึ้น การทำ VACUUM, VACUUM FULL และ VACUUM FULL ANALYZE ไม่ปรากฏขึ้นเพื่อแก้ไขปัญหา สิ่งที่แก้ปัญหาด้านประสิทธิภาพคือการหยุดฐานข้อมูลแยกส่วนไดรฟ์แล้วทำการ VACUUM FULL ANALYZE ใช้เวลาทดสอบประสิทธิภาพของฉันกลับไปเป็น 10 นาทีเดิม สิ่งนี้ทำให้ฉันสงสัยว่าการแตกออกเป็นส่วน ๆ คือสิ่งที่ทำให้ฉันเจ็บปวด

ฉันไม่สามารถค้นหาการอ้างอิงถึงการจองพื้นที่ตาราง / ฐานข้อมูลใน Postgres ได้ ฉันกำลังใช้คำศัพท์ที่ไม่ถูกต้องและไม่พบสิ่งใดเลยหรือมีวิธีอื่นในการลดการแตกแฟรกเมนต์ของระบบไฟล์ใน Postgres

ตัวชี้ใด ๆ

การแก้ไขปัญหา

คำตอบที่ให้มาช่วยยืนยันสิ่งที่ฉันเริ่มสงสัย PostgreSQL จัดเก็บฐานข้อมูลข้ามหลายไฟล์และนี่คือสิ่งที่ช่วยให้ฐานข้อมูลเติบโตโดยไม่ต้องกังวลเรื่องการแตกแฟรกเมนต์ พฤติกรรมเริ่มต้นคือการแพ็คไฟล์เหล่านี้ไปที่ขอบด้วยข้อมูลตารางซึ่งเป็นสิ่งที่ดีสำหรับตารางที่ไม่ค่อยเปลี่ยนแปลง แต่ไม่ดีสำหรับตารางที่มีการปรับปรุงบ่อยครั้ง

PostgreSQL ใช้MVCCเพื่อจัดเตรียมการเข้าถึงข้อมูลตารางพร้อมกัน ภายใต้ชุดรูปแบบนี้การอัปเดตแต่ละครั้งจะสร้างเวอร์ชันใหม่ของแถวที่อัปเดต (ซึ่งอาจผ่านการประทับเวลาหรือหมายเลขเวอร์ชันใครจะรู้) ข้อมูลเก่าจะไม่ถูกลบทันที แต่ทำเครื่องหมายเพื่อลบ การลบที่แท้จริงเกิดขึ้นเมื่อมีการดำเนินการ VACUUM

สิ่งนี้เกี่ยวข้องกับปัจจัยเติมอย่างไร ปัจจัยการเติมเริ่มต้นของตารางเต็ม 100 เต็มหน้าตารางซึ่งหมายความว่าไม่มีพื้นที่ภายในหน้าตารางที่จะถือแถวที่ปรับปรุงเช่นแถวที่ปรับปรุงจะถูกวางในหน้าตารางที่แตกต่างจากแถวเดิม สิ่งนี้ไม่ดีสำหรับการแสดงตามประสบการณ์ของฉัน เนื่องจากตารางสรุปของฉันได้รับการอัปเดตบ่อยมาก (มากถึง 1,500 แถว / วินาที) ฉันเลือกที่จะตั้งค่าตัวประกอบการเติมเท่ากับ 20 นั่นคือ 20% ของตารางจะเป็นข้อมูลแถวที่แทรกและ 80% สำหรับข้อมูลการอัปเดต แม้ว่าสิ่งนี้อาจดูมากเกินไปพื้นที่จำนวนมากที่สงวนไว้สำหรับแถวที่อัพเดตหมายความว่าแถวที่อัปเดตจะอยู่ภายในหน้าเดียวกับต้นฉบับและมีหน้าตารางไม่เต็มตามเวลาที่ autovacuum daemon ทำงานเพื่อลบแถวที่ล้าสมัย

หากต้องการ "แก้ไข" ฐานข้อมูลของฉันฉันได้ทำสิ่งต่อไปนี้

1. ตั้งค่าตัวประกอบการเติมของตารางสรุปของฉันเป็น 20 คุณสามารถทำได้เมื่อสร้างโดยส่งพารามิเตอร์ไปที่CREATE TABLEหรือหลังจากความจริงผ่าน ALTER TABLE ฉันออกคำสั่ง plpgsql ต่อไปนี้:ALTER TABLE "my_summary_table" SET (fillfactor = 20);
2. ออกสูญญากาศเต็มรูปแบบเช่นนี้เขียนรุ่นใหม่ที่สมบูรณ์แบบของไฟล์ตารางและทำให้โดยปริยายเขียนไฟล์ตารางใหม่ที่มีปัจจัยเติมใหม่

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

TL; DR - การแตกแฟรกเมนต์ของไฟล์ไม่ใช่สาเหตุ แต่เป็นการกระจายตัวของพื้นที่ตาราง นี่คือการลดลงโดยการปรับแต่งปัจจัยการเติมตารางเพื่อให้เหมาะกับกรณีการใช้งานของคุณโดยเฉพาะ

1. ไม่มีสิ่งเดียวที่ใกล้เคียงกับที่คุณรวบรวมเซิร์ฟเวอร์ด้วยสวิตช์ --with-segsize สิ่งนี้อาจช่วยได้หากตารางของคุณใช้พื้นที่มากกว่ากิกะไบต์และระบบไฟล์ของคุณสามารถจัดการไฟล์เดียวที่อยู่เหนือกิ๊กได้ หากคุณใส่ 20 gigs คุณจะต้องสร้างไฟล์ 20 ไฟล์หากคุณไม่ได้ใช้สวิตช์นี้ หากระบบไฟล์ของคุณสามารถจัดการกับไฟล์บนกิ๊กคุณสามารถตั้งค่าให้มีค่ามากที่สุดที่จะเห็นประโยชน์บางกรณีที่เลวร้ายที่สุดคือผลประโยชน์เล็ก ๆ

2. ลองดูที่ CLUSTER http://www.postgresql.org/docs/9.1/static/sql-cluster.htmlและ FILLFACTOR http://www.postgresql.org/docs/9.1/static/sql-createtable.html , http://www.postgresql.org/docs/9.1/static/sql-createindex.html

โปรดทราบว่า FILLFACTOR สามารถใช้ได้กับทั้งตารางและดัชนี

มีอีกสิ่งหนึ่งในการเล่นที่ยังไม่ได้ป้อนสมการของคุณ: อัพเดทร้อนแรง คำตอบที่เกี่ยวข้อง:

• PostgreSQL ไม่ขยายตารางอธิบาย
• VACUUM ANALYZE ปกติยังคงแนะนำภายใต้ 9.1 หรือไม่
• ความหมายของ n_live_tup และ n_dead_tup ใน pg_stat_user_tables คืออะไร
• วิธีเพิ่มความเร็วคิวรี UPDATE ที่ช้า

การตั้งค่าFILLFACTORให้น้อยที่สุดเท่า20 ไม่ดูเหมือนมากเกินไป มันขยายตารางได้ถึงห้าเท่าของขนาด หาก HOT ปรับปรุงการทำงานของคุณไม่ควรจะต้องไปต่ำที่ - ปกติ

มีข้อยกเว้น: การปรับปรุง HOT เท่านั้นที่สามารถนำมาใช้ใหม่อันดับที่ตายจากการทำธุรกรรมก่อนหน้านี้ไม่ได้มาจากที่เดียวกันหรือพร้อมกันคน ดังนั้นการโหลดพร้อมกันอย่างหนักหรือการทำธุรกรรมที่ยาวนานการปรับปรุงแถวเดียวกันซ้ำ ๆ สามารถรับประกันการตั้งค่าที่ต่ำ (หรือต่ำกว่า) ได้

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

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

สุดท้ายคุณก็สามารถตั้งค่าพารามิเตอร์ต่อโต๊ะ autovacuum FILLFACTOR 20คุณสามารถกำหนดเป้าหมายตารางการปรับปรุงอย่างมากกับการตั้งค่าในเชิงรุกช่วยให้มีการบรรจุค่อนข้างเข้มงวดมากขึ้นของแถวกว่าเท่านั้น

หากปัญหาของคุณคือการแตกไฟล์แล้วไม่ไม่มี ใน Postgres แต่ละตารางจะได้รับเป็นไฟล์ของตัวเองหรือชุดของไฟล์หากใช้ TOAST ในระบบไฟล์ สิ่งนี้แตกต่างจาก Oracle (หรือเห็นได้ชัดว่า MS-SQL) ที่คุณสร้างไฟล์ tablespace ขนาดล่วงหน้าเพื่อวางตารางของคุณลงใน - แม้ว่าคุณอาจมีปัญหาการแตกแฟรกเมนต์ของระบบไฟล์หากไฟล์ tablespace ขยายหรือระบบไฟล์ การแยกส่วนที่ไม่ดีเริ่มต้นด้วย

สำหรับคำถามที่สองของคุณ ... ฉันไม่รู้ว่าจะจัดการกับการแตกแฟรกเมนต์ของระบบไฟล์ได้อย่างไรเนื่องจาก MS-Windows เป็นระบบปฏิบัติการเดียวที่ฉันประสบปัญหาการแตกแฟรกเมนต์และฉันไม่เรียกใช้ MS-Windows มากกว่าอย่างแน่นอน ต้องเป็นวันนี้ บางทีการวางไฟล์ฐานข้อมูลไว้ในดิสก์ของตัวเองอาจช่วยลดขนาดไฟล์ลงได้บ้าง