เรียนลบ Nikolay Samokhvalov (Postgres.ai)

ในอนาคตอันไกล การลบข้อมูลที่ไม่จำเป็นโดยอัตโนมัติจะเป็นหนึ่งในภารกิจสำคัญของ DBMS [1] ในระหว่างนี้ เราเองจำเป็นต้องดูแลการลบหรือย้ายข้อมูลที่ไม่จำเป็นไปยังระบบจัดเก็บข้อมูลที่มีราคาไม่แพง สมมติว่าคุณตัดสินใจลบสองสามล้านแถว งานที่ค่อนข้างง่าย โดยเฉพาะอย่างยิ่งหากทราบเงื่อนไขและมีดัชนีที่เหมาะสม "ลบจาก table1 โดยที่ col1 = :value" - อะไรจะง่ายกว่านี้ จริงไหม

วิดีโอ:

• ฉันอยู่ในคณะกรรมการโครงการ Highload ตั้งแต่ปีแรก เช่น ตั้งแต่ปี 2007

• และฉันใช้ Postgres มาตั้งแต่ปี 2005 ใช้ในหลายโครงการ

• รวมกลุ่มกับ RuPostges ตั้งแต่ปี 2007

• เรามีผู้เข้าร่วมมากกว่า 2100 คนที่ Meetup เป็นอันดับสองของโลกรองจากนิวยอร์กซึ่งแซงหน้าซานฟรานซิสโกไปนานแล้ว

• ฉันอาศัยอยู่ในแคลิฟอร์เนียมาหลายปีแล้ว ฉันติดต่อกับบริษัทอเมริกันมากขึ้น รวมถึงบริษัทขนาดใหญ่ด้วย พวกเขาเป็นผู้ใช้งาน Postgres และมีสิ่งที่น่าสนใจมากมาย

https://postgres.ai/ เป็นบริษัทของฉัน เราอยู่ในธุรกิจการทำงานอัตโนมัติที่ขจัดการชะลอตัวของการพัฒนา

หากคุณกำลังทำอะไรบางอย่าง บางครั้งมีปลั๊กบางชนิดรอบๆ Postgres สมมติว่าคุณต้องรอให้ผู้ดูแลระบบตั้งค่าแท่นทดสอบให้คุณ หรือต้องรอให้ DBA ตอบกลับคุณ และเราพบปัญหาคอขวดดังกล่าวในกระบวนการพัฒนา ทดสอบ และบริหารจัดการ และพยายามขจัดปัญหาเหล่านั้นด้วยความช่วยเหลือของระบบอัตโนมัติและแนวทางใหม่ๆ

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

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

ในโลกของเซตตะไบต์มีข้อมูลมากขึ้นเรื่อยๆ นั่นคือ 1 เพตะไบต์ และตอนนี้มีการประมาณแล้วว่าเรามีข้อมูลมากกว่า 000 เซ็ตตะไบต์ที่จัดเก็บอยู่ในโลก และมีมากขึ้นเรื่อย ๆ

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

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

ผู้ที่นับเงินได้ต้องการสองสิ่ง พวกเขาต้องการให้เราลบ ดังนั้นในทางเทคนิคแล้วเราน่าจะทำได้

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

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

โดยทั่วไป ภารกิจคือการลบสิ่งเฉพาะเจาะจง บรรทัดเฉพาะในบางตารางโดยอัตโนมัติ

และเรามีคำขอดังกล่าวซึ่งเราจะพูดถึงในวันนี้ นั่นคือ การกำจัดขยะ

เราขอให้นักพัฒนาที่มีประสบการณ์ทำ เขารับคำขอนี้ตรวจสอบด้วยตัวเอง - ทุกอย่างใช้งานได้ ทดสอบการแสดงละคร - ทุกอย่างเรียบร้อยดี แผ่ออก - ทุกอย่างใช้งานได้ เราเรียกใช้วันละครั้ง - ทุกอย่างเรียบร้อยดี

ฐานข้อมูลเติบโตขึ้นเรื่อยๆ Daily DELETE เริ่มทำงานช้าลงเล็กน้อย

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

ไม่กี่เดือนต่อมาพวกเขาก็จำได้ และนักพัฒนาคนนั้นเลิกหรือยุ่งกับสิ่งอื่น สั่งให้คนอื่นส่งคืน

เขาตรวจสอบกับ dev ในการแสดงละคร - ทุกอย่างโอเค โดยธรรมชาติแล้วคุณยังต้องทำความสะอาดสิ่งที่สะสมอยู่ เขาตรวจสอบการทำงานทุกอย่าง

จะเกิดอะไรขึ้นต่อไป? จากนั้นทุกอย่างก็พังทลายลงเพื่อเรา มันลดลงจนเมื่อถึงจุดหนึ่งทุกอย่างก็พังทลายลง ทุกคนตกตะลึงไม่มีใครเข้าใจว่าเกิดอะไรขึ้น แล้วปรากฎว่าเรื่องนี้อยู่ใน DELETE นี้

บางอย่างผิดพลาด? นี่คือรายการของสิ่งที่อาจผิดพลาด ข้อใดสำคัญที่สุด?

• ตัวอย่างเช่น ไม่มีการตรวจสอบ กล่าวคือ ผู้เชี่ยวชาญ DBA ไม่ได้ตรวจสอบ เขาจะพบปัญหาทันทีด้วยสายตาที่มีประสบการณ์ และนอกจากนี้ เขาสามารถเข้าถึงผลิตภัณฑ์ที่มีบรรทัดสะสมหลายล้านบรรทัด

• บางทีพวกเขาอาจตรวจสอบบางอย่างผิดพลาด

• ฮาร์ดแวร์อาจล้าสมัยและคุณจำเป็นต้องอัปเกรดฐานนี้

• หรือมีบางอย่างผิดปกติกับตัวฐานข้อมูล และเราจำเป็นต้องย้ายจาก Postgres ไปยัง MySQL

• หรืออาจมีบางอย่างผิดปกติกับการดำเนินการ

• อาจมีข้อผิดพลาดบางอย่างในองค์กรของการทำงานและคุณจำเป็นต้องไล่ใครซักคนและจ้างคนที่ดีที่สุด?

ไม่มีการตรวจสอบ DBA หากมี DBA เขาจะเห็นบรรทัดหลายล้านบรรทัดเหล่านี้ และแม้ไม่มีการทดลองใดๆ ก็จะพูดว่า: "พวกเขาไม่ทำอย่างนั้น" สมมติว่าโค้ดนี้อยู่ใน GitLab, GitHub และจะมีกระบวนการตรวจสอบโค้ด และไม่มีสิ่งใดที่การดำเนินการนี้จะเกิดขึ้นกับผลิตภัณฑ์หากไม่ได้รับอนุมัติจาก DBA เห็นได้ชัดว่า DBA จะพูดว่า: “สิ่งนี้ไม่สามารถทำได้ ”

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

http://bit.ly/nancy-hl2018-2

ความผิดพลาดครั้งที่สอง - พวกเขาเช็คอินผิดที่ เราพบว่าข้อมูลขยะจำนวนมากสะสมอยู่ในผลิตภัณฑ์ แต่ผู้พัฒนาไม่มีข้อมูลสะสมในฐานข้อมูลนี้ และไม่มีใครสร้างขยะนี้ระหว่างการแสดงละคร ดังนั้นจึงมี 1 บรรทัดที่ทำงานได้อย่างรวดเร็ว

เราเข้าใจดีว่าการทดสอบของเราอ่อนแอ นั่นคือกระบวนการที่สร้างขึ้นไม่สามารถตรวจจับปัญหาได้ ไม่ได้ทำการทดสอบ DB ที่เพียงพอ

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

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

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

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

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

การตั้งค่าใน Postgres ล้าหลัง ออกแบบมาสำหรับปริมาณข้อมูลและธุรกรรมอายุ 10-15 ปี และจุดตรวจก็ไม่มีข้อยกเว้น

นี่คือข้อมูลจากรายงานการตรวจสุขภาพ Postgres ของเรา นั่นคือการตรวจสุขภาพอัตโนมัติ และนี่คือฐานข้อมูลบางส่วนที่มีขนาดหลายเทราไบต์ และที่เห็นได้ชัดเจนคือด่านบังคับเกือบ 90% ของคดีทั้งหมด

มันหมายความว่าอะไร? มีสองการตั้งค่าที่นั่น ด่านสามารถมาได้โดยหมดเวลา เช่น ใน 10 นาที หรืออาจเกิดขึ้นเมื่อกรอกข้อมูลค่อนข้างมาก

และโดยค่าเริ่มต้น max_wal_saze จะถูกตั้งค่าเป็น 1 กิกะไบต์ ในความเป็นจริงสิ่งนี้เกิดขึ้นใน Postgres หลังจาก 300-400 เมกะไบต์ คุณเปลี่ยนแปลงข้อมูลมากมายและจุดตรวจของคุณก็เกิดขึ้น

และถ้าไม่มีใครปรับมัน และบริการก็เติบโตขึ้น และบริษัทก็ได้รับเงินจำนวนมาก มีการทำธุรกรรมจำนวนมาก จุดตรวจจะมานาทีละครั้ง บางครั้งทุกๆ 30 วินาที และบางครั้งก็ทับซ้อนกัน นี่ค่อนข้างแย่

และเราจำเป็นต้องตรวจสอบให้แน่ใจว่ามันมาไม่บ่อยนัก นั่นคือ เราสามารถเพิ่ม max_wal_size ได้ และจะมาไม่บ่อย

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

ดังนั้น เรากำลังทำการทดลองสองชุดบนฐานข้อมูล

ชุดแรก - เราเปลี่ยน max_wal_size และเรากำลังดำเนินการครั้งใหญ่ ขั้นแรก เราใช้การตั้งค่าเริ่มต้นที่ 1 กิกะไบต์ และเราทำการลบจำนวนหลายล้านบรรทัด

คุณจะเห็นว่ามันยากสำหรับเรา เราเห็นว่าดิสก์ IO นั้นแย่มาก เราพิจารณาจำนวน WAL ที่เราสร้างขึ้น เนื่องจากสิ่งนี้สำคัญมาก มาดูกันว่าเกิดด่านกี่ครั้ง และเรามองว่ามันไม่ดี

ต่อไปเราจะเพิ่ม max_wal_size เราทำซ้ำ เราเพิ่มขึ้น เราทำซ้ำ และหลายครั้ง โดยหลักการแล้ว 10 คะแนนเป็นสิ่งที่ดีโดยที่ 1, 2, 4, 8 กิกะไบต์ และเราดูที่พฤติกรรมของระบบใดระบบหนึ่ง เป็นที่ชัดเจนว่าที่นี่อุปกรณ์ควรจะเหมือนในผลิตภัณฑ์ คุณต้องมีดิสก์เดียวกัน จำนวนหน่วยความจำเท่ากัน และการตั้งค่า Postgres เหมือนกัน

และด้วยวิธีนี้ เราจะแลกเปลี่ยนระบบของเรา และเรารู้ว่า DBMS จะทำงานอย่างไรในกรณีที่มีการลบจำนวนมากไม่ดี มันจะตรวจสอบอย่างไร

จุดตรวจในภาษารัสเซียคือจุดตรวจ

ตัวอย่าง: ลบหลายล้านแถวตามดัชนี แถวจะ "กระจัดกระจาย" ไปตามหน้าต่างๆ

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

หากการดำเนินการดังกล่าวได้รับอนุญาตใน prod เราจะนอนลงเพราะเห็นได้ชัดว่า DELETE หนึ่งคนฆ่าเราในกองทหาร

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

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

ทำไมเป็นเช่นนั้น

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

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

และเราจะบังคับด่านเพื่อบันทึกหลายครั้ง จะมีการดำเนินการซ้ำซ้อนสำหรับเขาได้อย่างไร

แต่นั่นไม่ใช่ทั้งหมด หน้ามีขนาด 8 กิโลไบต์ใน Postgres และ 4 กิโลไบต์ใน Linux และมีการตั้งค่า full_page_writes มันถูกเปิดใช้งานโดยค่าเริ่มต้น และสิ่งนี้ถูกต้องเพราะหากเราปิดการทำงาน อาจมีอันตรายที่จะบันทึกเพียงครึ่งหน้าหากเกิดข้อผิดพลาด

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

ในการเปลี่ยนแปลงครั้งต่อไปจะมีเพียงทูเพิลเฉพาะ แต่เป็นครั้งแรกที่เราเขียนทุกอย่าง

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

และด้วยเหตุนี้เราจึงมีความซ้ำซ้อนสองครั้ง

ถ้าเราเพิ่ม max_wal_size ปรากฎว่าเราทำให้ง่ายขึ้นสำหรับทั้งตัวตรวจสอบและตัวเขียน wal และนั่นก็เยี่ยมมาก

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

เราทำการดำเนินการและดูว่าด่านกำลังจะเสร็จเมื่อไหร่ เราฆ่า -9 Postgres โดยตั้งใจ

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

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

เราวัดสถานการณ์ดังกล่าวสำหรับขนาด max_wal_size ที่แตกต่างกัน และเข้าใจว่าหาก max_wal_size คือ 64 กิกะไบต์ ในกรณีที่แย่ที่สุดสองเท่า เราจะปีนขึ้นไปเป็นเวลา 10 นาที แล้วเราคิดว่ามันเหมาะกับเราหรือเปล่า นี่เป็นคำถามทางธุรกิจ เราต้องแสดงภาพนี้ให้ผู้ที่รับผิดชอบในการตัดสินใจทางธุรกิจและถามว่า “เราจะนอนราบได้นานแค่ไหนในกรณีที่มีปัญหา? เราสามารถนอนลงในสถานการณ์ที่เลวร้ายที่สุดเป็นเวลา 3-5 นาทีได้หรือไม่? และคุณตัดสินใจ

และนี่คือประเด็นที่น่าสนใจ เรามีรายงานสองสามฉบับเกี่ยวกับ Patroni ในการประชุม และบางทีคุณอาจกำลังใช้มันอยู่ นี่คือ autofailover สำหรับ Postgres GitLab และ Data Egret พูดถึงเรื่องนี้

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

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

ฉันยังคงไม่ไปไกลเกินไป แม้ว่าเราจะมี autofailover ก็ตาม ตามกฎแล้ว ค่าต่างๆ เช่น 64, 100 กิกะไบต์เป็นค่าที่ดี บางครั้งก็คุ้มค่าที่จะเลือกน้อยลง โดยทั่วไปแล้วนี่เป็นวิทยาศาสตร์ที่ละเอียดอ่อน

ในการวนซ้ำ ตัวอย่างเช่น max_wal_size =1, 8 คุณต้องดำเนินการจำนวนมากซ้ำหลายครั้ง คุณทำมัน. และบนฐานเดิมที่คุณต้องการทำอีกครั้ง แต่คุณได้ลบทุกอย่างไปแล้ว จะทำอย่างไร?

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

แต่ในกรณีนี้เราโชคดี ถ้าตามที่กล่าวไว้ที่นี่ "เริ่มต้น ลบ ย้อนกลับ" เราก็สามารถลบซ้ำได้ คือถ้าเรายกเลิกเองก็ทำซ้ำได้ และข้อมูลจะอยู่ที่ตัวคุณ คุณไม่ได้รับการบวมใด ๆ คุณสามารถวนซ้ำกับ DELETE ดังกล่าวได้

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

เราทำจานด้วยหนึ่งคอลัมน์ "i" Postgres มีคอลัมน์ยูทิลิตี้ พวกเขามองไม่เห็นเว้นแต่จะขอเป็นพิเศษ เหล่านี้คือ: ctid, xmid, xmax

Ctid เป็นที่อยู่ทางกายภาพ ศูนย์หน้า ทูเพิลแรกในหน้า

จะเห็นได้ว่าหลังจาก ROOLBACK แล้วทูเพิลยังคงอยู่ที่เดิม นั่นคือเราสามารถลองอีกครั้งก็จะทำงานในลักษณะเดียวกัน นี่คือสิ่งสำคัญ

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

นี่เป็นเรื่องเกี่ยวกับโปรแกรมเมอร์ เกี่ยวกับ DBA พวกเขามักจะตำหนิโปรแกรมเมอร์เสมอ: "ทำไมคุณถึงดำเนินการที่ยาวและยากเช่นนี้" นี่เป็นหัวข้อตั้งฉากที่แตกต่างไปจากเดิมอย่างสิ้นเชิง เคยมีการบริหารและตอนนี้จะมีการพัฒนา

เห็นได้ชัดว่าเราไม่ได้แตกเป็นชิ้นเล็กชิ้นน้อย ก็เป็นที่ชัดเจน. เป็นไปไม่ได้ที่จะไม่ทำลาย DELETE ดังกล่าวเป็นจำนวนหลายล้านบรรทัดออกเป็นส่วนๆ จะใช้เวลา 20 นาทีและทุกอย่างจะสงบลง แต่น่าเสียดายที่แม้แต่นักพัฒนาที่มีประสบการณ์ก็ยังทำผิดพลาดได้ แม้แต่ในบริษัทขนาดใหญ่

ทำไมการทำลายจึงสำคัญ?

• หากเราเห็นว่าดิสก์แข็งให้ช้าลง และถ้าเราเสีย เราสามารถเพิ่มการหยุดชั่วคราว เราสามารถชะลอการควบคุม

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

https://postgres.ai/products/joe/

สิ่งนี้น่าสนใจ ฉันมักจะเห็นว่านักพัฒนาถาม: "ฉันควรเลือกขนาดแพ็คใด"

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

ฉันมีกฎง่าย ๆ มาก: ใช้เวลาให้มากที่สุด แต่อย่าใช้ไฟล์ปฏิบัติการต่อวินาทีมากเกินไป

ทำไมต้องเป็นวินาที? คำอธิบายนั้นง่ายมากและเข้าใจได้สำหรับทุกคน แม้กระทั่งคนที่ไม่เชี่ยวชาญด้านเทคนิค เราเห็นปฏิกิริยา ลองใช้เวลา 50 มิลลิวินาที หากมีอะไรเปลี่ยนไป ตาของเราจะตอบสนอง ถ้าน้อยก็ยากขึ้น หากบางสิ่งตอบสนองหลังจากผ่านไป 100 มิลลิวินาที ตัวอย่างเช่น คุณคลิกเมาส์ แล้วมันตอบกลับคุณหลังจากผ่านไป 100 มิลลิวินาที แสดงว่าคุณรู้สึกถึงความล่าช้าเล็กน้อยนี้แล้ว วินาทีนั้นรับรู้แล้วว่าเป็นเบรก

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

เราเลือกขนาดของแพ็ค ในแต่ละกรณีเราสามารถทำได้แตกต่างกัน ได้อย่างอัตโนมัติ และเราเชื่อมั่นในประสิทธิภาพของการประมวลผลของหนึ่งแพ็ค นั่นคือเราทำ DELETE หนึ่งแพ็คหรืออัปเดต

อย่างไรก็ตาม ทุกสิ่งที่ฉันพูดถึงไม่ได้เกี่ยวกับ DELETE เท่านั้น อย่างที่คุณเดา นี่คือการดำเนินการจำนวนมากกับข้อมูล

และเราเห็นว่าแผนการนั้นยอดเยี่ยม คุณสามารถดูการสแกนดัชนีได้ การสแกนเฉพาะดัชนีจะดียิ่งขึ้น และเรามีข้อมูลจำนวนเล็กน้อยที่เกี่ยวข้อง และน้อยกว่าวินาทีที่สมหวัง สุดยอด.

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

กลยุทธ์การแบ่งพาร์ติชันคืออะไร? ฉันเห็นกลยุทธ์การแบ่งพาร์ติชัน 3 แบบที่แตกต่างกันซึ่งนักพัฒนาในชุดใช้อยู่

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

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

ในกลยุทธ์แรก คุณสามารถทำได้ในหลายเธรด ไม่ใช่เรื่องยาก

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

แต่มีวิธีที่เย็นกว่าและดีกว่า นี่คือกลยุทธ์ที่สาม และเมื่อเป็นไปได้จะเป็นการดีกว่าที่จะเลือก เราทำสิ่งนี้โดยใช้ดัชนีพิเศษ ในกรณีนี้ ส่วนใหญ่จะเป็นดัชนีตามเงื่อนไขขยะและ ID ของเรา เราจะรวม ID เพื่อให้เป็นดัชนีเท่านั้น สแกนเพื่อไม่ให้เราไปที่กอง

โดยทั่วไป การสแกนเฉพาะดัชนีจะเร็วกว่าการสแกนดัชนี

และเราค้นหา ID ของเราที่เราต้องการลบอย่างรวดเร็ว BATCH_SIZE เราเลือกไว้ล่วงหน้า และเราไม่เพียงแค่ได้มันมาเท่านั้น เรายังได้มันมาด้วยวิธีพิเศษและทำการแฮ็คมันทันที แต่เรากำลังล็อคเพื่อที่ว่าหากล็อคไว้แล้วเราจะไม่ล็อค แต่ดำเนินการต่อไปและดำเนินการต่อไป นี่คือการข้ามการอัพเดทที่ถูกล็อค ฟีเจอร์ที่ยอดเยี่ยมของ Postgres นี้ช่วยให้เราสามารถทำงานในหลายๆ เธรดได้หากต้องการ เป็นไปได้ในกระแสเดียว และนี่คือ CTE - นี่เป็นคำขอเดียว และเรามีการลบจริงในชั้นสองของ CTE นี้ - returning *. คุณสามารถคืนรหัสได้ แต่จะดีกว่า *ถ้าคุณไม่มีข้อมูลมากนักในแต่ละบรรทัด

ทำไมเราต้องการมัน? นี่คือสิ่งที่เราต้องรายงานกลับ ตอนนี้เราลบไปหลายบรรทัดแล้ว และเรามีเส้นขอบตาม ID หรือ created_at แบบนี้ คุณสามารถทำขั้นต่ำ, สูงสุด อย่างอื่นสามารถทำได้ คุณสามารถบรรจุได้มากมายที่นี่ และสะดวกมากสำหรับการตรวจสอบ

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

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

แต่นี่เป็นกลยุทธ์ที่เหมาะสมที่สุด วิธีแบ่งเป็นชุดและถ่ายทีละชุดด้วยคำขอเดียว ลบเล็กน้อย ฯลฯ

การทำธุรกรรมที่ยาวนาน https://gitlab.com/snippets/1890447

สูญญากาศอัตโนมัติที่ถูกบล็อก - https://gitlab.com/snippets/1889668

ปัญหาการบล็อก - https://gitlab.com/snippets/1890428

ข้อผิดพลาด #5 เป็นเรื่องใหญ่ Nikolai จาก Okmeter พูดคุยเกี่ยวกับการตรวจสอบ Postgres น่าเสียดายที่ไม่มีการตรวจสอบ Postgres ในอุดมคติ บางคนอยู่ใกล้ บางคนอยู่ไกลออกไป Okmeter ใกล้จะสมบูรณ์แบบแล้ว แต่ยังขาดอะไรไปมากและจำเป็นต้องเพิ่ม คุณต้องพร้อมสำหรับสิ่งนี้

ตัวอย่างเช่น tuples ที่ตายแล้วจะได้รับการตรวจสอบอย่างดีที่สุด หากคุณมีของตายมากมายในโต๊ะแสดงว่ามีบางอย่างผิดปกติ ดีกว่าที่จะตอบสนองในขณะนี้ มิฉะนั้น อาจมีการลดลง และเราสามารถนอนลงได้ มันเกิดขึ้น.

หากมี IO ขนาดใหญ่แสดงว่าสิ่งนี้ไม่ดี

ธุรกรรมยาวเกินไป ไม่ควรอนุญาตให้ทำธุรกรรมที่ยาวบน OLTP และนี่คือลิงค์ไปยังส่วนย่อยที่ให้คุณนำส่วนย่อยนี้ไปใช้และติดตามธุรกรรมที่มีความยาวได้บางส่วนแล้ว

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

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

และบล็อกประเด็น. ป่าแห่งต้นไม้บล็อก ฉันชอบรับบางสิ่งจากใครบางคนและปรับปรุงมัน ที่นี่ฉันใช้ CTE แบบเรียกซ้ำที่ยอดเยี่ยมจาก Data Egret ที่แสดงป่าของล็อกทรี นี่เป็นเครื่องมือวินิจฉัยที่ดี และบนพื้นฐานของมัน คุณยังสามารถสร้างการตรวจสอบได้อีกด้วย แต่ต้องทำอย่างระมัดระวัง คุณต้องสร้าง statement_timeout เล็กๆ สำหรับตัวคุณเอง และเป็นที่ต้องการของ lock_timeout

บางครั้งข้อผิดพลาดเหล่านี้เกิดขึ้นในผลรวม

ในความคิดของฉัน ข้อผิดพลาดหลักที่นี่คือองค์กร เป็นองค์กรเพราะเทคนิคไม่ดึง นี่คือหมายเลข 2 - พวกเขาเช็คอินผิดที่

เราตรวจสอบผิดที่ เนื่องจากเราไม่มีสำเนาการผลิตซึ่งง่ายต่อการตรวจสอบ นักพัฒนาอาจไม่สามารถเข้าถึงการผลิตได้เลย

และเราไม่ได้ตรวจสอบที่นั่น ถ้าเราได้ตรวจสอบที่นั่นเราจะได้เห็นมันเอง นักพัฒนามองเห็นได้ทั้งหมดแม้ไม่มี DBA หากเขาตรวจสอบในสภาพแวดล้อมที่ดี ซึ่งมีข้อมูลจำนวนเท่ากันและตำแหน่งที่เหมือนกัน เขาคงจะเห็นความเสื่อมโทรมทั้งหมดนี้และเขาคงจะละอายใจ

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

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

สิ่งที่เราทำคือโอเพ่นซอร์ส มันถูกโพสต์บน GitLab และเราทำให้ผู้คนสามารถตรวจสอบได้แม้ไม่มี DBA เรากำลังทำแล็บฐานข้อมูล นั่นคือ เราเรียกส่วนประกอบพื้นฐานที่โจกำลังทำงานอยู่ และคุณสามารถคว้าสำเนาของการผลิตได้ ขณะนี้มีการใช้งาน Joe เพื่อความหย่อนคุณสามารถพูดได้ที่นั่น: "อธิบายคำขอดังกล่าวและเช่นนั้น" และรับผลลัพธ์สำหรับสำเนาฐานข้อมูลของคุณทันที คุณสามารถลบที่นั่นได้ และจะไม่มีใครสังเกตเห็น

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

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

ตัวอย่าง: ฐานข้อมูล 5 เทราไบต์ รับสำเนาในเวลาน้อยกว่า 30 วินาที และไม่ได้ขึ้นอยู่กับขนาดนั่นคือไม่สำคัญว่าจะมีกี่เทราไบต์

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

คำถาม

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

นี่เป็นแนวทางที่ดีและเป็นงานที่ดีมาก มันคล้ายกับสิ่งที่ pg_repack ทำ มันคล้ายกับสิ่งที่คุณต้องทำเมื่อคุณสร้าง ID 4 ไบต์ เฟรมเวิร์กหลายตัวทำสิ่งนี้เมื่อไม่กี่ปีที่ผ่านมา และเพลตก็โตขึ้น และจำเป็นต้องแปลงเป็น 8 ไบต์

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

หากคุณดู pg_repack บน GitHub เมื่อมีงานแปลง ID จาก int 4 เป็น int 8 ก็มีความคิดที่จะใช้ pg_repack เอง นอกจากนี้ยังเป็นไปได้ แต่เป็นการแฮ็กเล็กน้อย แต่ก็จะใช้งานได้เช่นกัน คุณสามารถแทรกแซงทริกเกอร์ที่ pg_repack ใช้และพูดว่า: "เราไม่ต้องการข้อมูลนี้" เช่น เราโอนเฉพาะสิ่งที่เราต้องการเท่านั้น แล้วเขาก็เปลี่ยนไป แค่นั้นแหละ

ด้วยวิธีนี้ เรายังคงได้รับสำเนาที่สองของตาราง ซึ่งข้อมูลได้รับการจัดทำดัชนีแล้วและวางซ้อนกันอย่างเท่าเทียมกันด้วยดัชนีที่สวยงาม

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

ฉันเพิ่งมาจากโลกของ MySQL ฉันเลยมาฟัง และเราใช้แนวทางนี้

แต่ถ้าเรามี 90% เท่านั้น ถ้าเรามี 5% ก็ไม่ดีที่จะใช้

ขอบคุณสำหรับรายงาน! หากไม่มีทรัพยากรที่จะทำสำเนาผลิตภัณฑ์ที่สมบูรณ์ มีอัลกอริทึมหรือสูตรคำนวณโหลดหรือขนาดหรือไม่

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

ขอบคุณสำหรับรายงาน! ก่อนอื่นคุณเริ่มต้นเกี่ยวกับความจริงที่ว่ามี Postgres ที่ยอดเยี่ยมซึ่งมีข้อ จำกัด ดังกล่าวและดังกล่าว แต่กำลังพัฒนา และนี่คือไม้ค้ำยันโดยมาก ทั้งหมดนี้ไม่ได้ขัดแย้งกับการพัฒนาของ Postgres เอง ซึ่ง DELETE deferent บางตัวจะปรากฏขึ้นหรืออย่างอื่นที่ควรรักษาระดับต่ำในสิ่งที่เราพยายามจะละเลงด้วยวิธีการแปลก ๆ ของเราที่นี่

หากเราพูดใน SQL ให้ลบหรืออัปเดตบันทึกจำนวนมากในธุรกรรมเดียว Postgres จะแจกจ่ายที่นั่นได้อย่างไร เรามีข้อจำกัดทางร่างกายในการปฏิบัติงาน เรายังจะทำอีกนาน และเราจะล็อคในเวลานี้เป็นต้น

เสร็จสิ้นด้วยดัชนี

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

คำถามคือ มีเวกเตอร์ของการพัฒนาที่ไปโน่นไปนี่ และตรงนี้ของคุณไปคู่ขนานกันหรือไม่? เหล่านั้น. พวกเขายังไม่ได้คิดเกี่ยวกับเรื่องนี้อีกหรือ?

ผมได้พูดถึงหลักการที่ใช้ได้ในตอนนี้ มีบอทอีกตัว แนนซี่ด้วยสิ่งนี้ คุณสามารถปรับแต่งจุดตรวจสอบอัตโนมัติได้ สักวันหนึ่งมันจะอยู่ใน Postgres หรือไม่? ไม่รู้สิ ยังไม่ได้คุยกันเลย เรายังห่างไกลจากสิ่งนั้น แต่มีนักวิทยาศาสตร์ที่สร้างระบบใหม่ และผลักเราเข้าสู่ดัชนีอัตโนมัติ มีการพัฒนา. ตัวอย่างเช่น คุณสามารถดูการปรับอัตโนมัติ มันเลือกพารามิเตอร์โดยอัตโนมัติ แต่เขาจะยังไม่ทำการปรับด่านให้คุณ นั่นคือมันจะรับประสิทธิภาพบัฟเฟอร์เชลล์ ฯลฯ

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

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

Autovacuum อาจไม่ใช่ปัญหาที่ใหญ่ที่สุดที่นี่ และข้อเท็จจริงที่ว่าการทำธุรกรรมที่ยาวนานสามารถล็อคธุรกรรมอื่นๆ ได้ ความเป็นไปได้นี้ยิ่งอันตราย เธออาจจะเจอหรือไม่เจอก็ได้ หากเธอพบกันก็อาจเลวร้ายมาก และด้วยเครื่องดูดฝุ่นอัตโนมัติ - นี่เป็นปัญหาเช่นกัน มีปัญหาสองประการเกี่ยวกับการทำธุรกรรมที่ยาวนานใน OLTP: การล็อกและการดูดฝุ่นอัตโนมัติ และหากคุณเปิดใช้ความคิดเห็นสแตนด์บายแบบด่วนบนแบบจำลอง คุณจะยังคงได้รับการล็อคสูญญากาศอัตโนมัติบนต้นแบบ ซึ่งจะมาจากแบบจำลอง แต่อย่างน้อยก็จะไม่มีการล็อค และจะมีล็อก เรากำลังพูดถึงการเปลี่ยนแปลงข้อมูล ดังนั้นการล็อกจึงเป็นจุดสำคัญที่นี่ และหากเป็นเช่นนี้เป็นเวลานาน ธุรกรรมก็จะยิ่งถูกล็อคมากขึ้นเรื่อยๆ พวกเขาสามารถขโมยของคนอื่นได้ และต้นลกก็ปรากฏขึ้น ฉันให้ลิงก์ไปยังตัวอย่างข้อมูล และปัญหานี้จะเห็นได้เร็วกว่าปัญหาเกี่ยวกับ autovacuum ซึ่งสามารถสะสมได้เท่านั้น

ขอบคุณสำหรับรายงาน! คุณเริ่มรายงานโดยบอกว่าคุณทดสอบไม่ถูกต้อง เราคิดต่อไปว่าต้องใช้อุปกรณ์เดิมโดยฐานเป็นแบบเดียวกัน สมมติว่าเราให้ฐานแก่นักพัฒนา และเขาก็ทำตามคำขอ และดูเหมือนว่าเขาจะสบายดี แต่เค้าไม่เช็ค live ให้ดู แต่ live เช่น เรามีโหลด 60-70% และแม้ว่าเราจะใช้การปรับแต่งนี้ ก็ไม่ได้ผลดีนัก

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

เมื่อเราทำการเลือกขยะแล้ว และเรามี เช่น แฟล็กที่ถูกลบ

นี่คือสิ่งที่ autovacuum ทำโดยอัตโนมัติใน Postgres

อ๋อ เขาทำงั้นเหรอ?

Autovacuum เป็นตัวเก็บขยะ

ขอบคุณ!

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

แน่นอนว่ามี

เป็นไปได้ไหมที่จะป้องกันตัวเองหากเราล็อคโต๊ะที่ไม่ควรใช้?

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

ที่มา: will.com