Fillfactor สำหรับตารางแคชคืออะไร?

ฉันมีตารางที่มีการปรับปรุง / เข้าถึงมากซึ่งฉันเก็บวัตถุ Java ที่ทำให้เป็นอนุกรม พวกเขาอยู่ในตารางเป็นเวลา 2-3 ชั่วโมง (ยังมีการปรับปรุงในช่วงเวลานั้น) แล้วลบออก ขนาดของตารางประมาณ 300MB ฉันเคยเห็นว่ามันมาก VACUUMed บ่อยมากและสงสัยว่าการเปลี่ยนแปลงfillfactorจะช่วยได้อย่างไร

คำสำคัญที่นี่คือ:

1. "ปรับปรุงอย่างมาก"
2. "ในตาราง 2-3 ชั่วโมง"

จุดที่ 1 คือตัวบ่งชี้สำหรับปัจจัยการเติมที่ต่ำกว่าในขณะที่ 2. เป็นสิ่งที่ตรงกันข้าม ช่วยเพิ่มประสิทธิภาพหากมีการจัดเก็บรุ่นหลายแถวในหน้าข้อมูลเดียวกัน การอัปเดต HOTจะบรรลุเป้าหมายนั้น อ่านที่นี่หรือที่นี่ พวกเขาต้องการห้องกระดิกในหน้าข้อมูล - เช่น tuples ที่ตายแล้วหรือพื้นที่ที่สงวนไว้โดยfillfactor<100 แต่พวกเขาสามารถทำได้เฉพาะถ้าไม่มีดัชนีที่เกี่ยวข้องกับคอลัมน์ที่อัปเดตใด ๆซึ่งควรเป็นจริงสำหรับกรณีของคุณ

อีกปัจจัยสำคัญที่นี่จะเป็นขนาด tuple (เมื่อเทียบกับขนาดหน้าของคุณ (ซึ่งโดยทั่วไปคือ 8 kb) รายละเอียดเพิ่มเติมในคำตอบที่เกี่ยวข้องนี้:

• วัดขนาดของแถวตาราง PostgreSQL

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

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

รูปแบบมาตรฐานของการVACUUMเอารุ่นแถวตายในตารางและดัชนีและเครื่องหมายพื้นที่ที่มีอยู่เพื่อนำมาใช้ในอนาคต

เหมืองเน้นหนัก
คุณสามารถเล่นโดยใช้การตั้งค่าต่อตารางสำหรับ autovacuumเพื่อทริกเกอร์มันน้อย (หรือมากกว่า) บ่อยสำหรับตารางนี้เท่านั้น:

ขีด จำกัด เริ่มต้นและตัวคูณสเกลจะนำมาจาก postgresql.confแต่ก็เป็นไปได้ที่จะแทนที่พวกเขาในแต่ละตาราง ;

เหมืองเน้นหนัก โดยเฉพาะอย่างยิ่งกับและautovacuum_vacuum_threshold autovacuum_vacuum_scale_factorการวิ่งบ่อยครั้งVACUUMอาจเป็นความคิดที่ดีแทนที่จะต่ำมาก fillfacterขึ้นอยู่กับรูปแบบการเข้าถึง หากสิ่งอันดับทูปมีชีวิตอยู่พูดว่า 3 ชั่วโมงและอัปเดตแต่ละครั้งหลายครั้งฉันจะลดระดับลงfillfactorเหลือ 50 อย่างคุณจะต้องทดสอบและหาจุดที่น่าสนใจ

ทางเลือก

ทั้งหมดนี้นอกเหนือจากข้อมูลของคุณดูเหมือนจะผันผวนตั้งแต่เริ่มต้น: ใช้UNLOGGEDตาราง :

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

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

หรือรุนแรงยิ่งขึ้น: ใช้ที่เก็บคีย์ - ค่าเช่นRedisหากคุณสามารถทำได้โดยไม่ต้องมีคุณสมบัติและความปลอดภัยที่ RDBMS ให้ไว้ทั้งหมด

ฉันขอแนะนำคีย์ - ค่า DBMS แต่ฉันโยนมันออกไปเพื่อผลประโยชน์

แทนที่จะดำเนินการคำสั่ง INSERT & DELETE เพียงอัปเดตเท่านั้น

โครงสร้างตารางจะเป็นอย่างไร

ID      integer  -- sequential ID
Used    boolean  -- default FALSE
Object  -- whatever type is appropriate

คอลัมน์การถือวัตถุจะมีความยาวคงที่เพื่อหลีกเลี่ยงการแยกและการย้ายแถว ขนาดคอลัมน์นี้เพื่อรองรับวัตถุของคุณและเพื่อเติมหน้าบนดิสก์อย่างมีประสิทธิภาพ

เติมตารางของคุณล่วงหน้าด้วยแถวมากเท่าที่คุณต้องการและอีกไม่กี่

เมื่อวัตถุถูกเขียนให้ค้นหาแถวที่มี Used = False และอัปเดตแถวนั้น เมื่อวัตถุถูกทำลายให้ตั้งค่าใช้เป็น "เท็จ" ไม่มีการสร้างขยะและไม่มีการรวบรวมขยะ

แน่นอนว่ามีเงื่อนไขข้อยกเว้นมากมายที่ต้องจัดการ (โอเวอร์โฟลว์แถวโอเวอร์โฟลว์สภาพการแข่งขันในการใช้ ID เป็นต้น) แต่ไม่มีใครผ่านไม่ได้