คุณปฏิบัติตามแนวทางใดบ้างเพื่อหลีกเลี่ยงการอัพเดทข้อมูลที่ไม่ถูกต้องในฐานข้อมูลขนาดใหญ่

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

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

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

หากคุณสามารถทำการเปลี่ยนแปลงกับระเบียนทั้งหมดมากกว่าระเบียนที่เฉพาะเจาะจงได้

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

ถ้าคุณสามารถแทรกมันจะดีกว่า

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

หากคุณสามารถหลีกเลี่ยงการลบได้ก็จะดีกว่า

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

มีนโยบายการอัพเดทที่สอดคล้องกัน

หากคุณต้องการอัปเดตระเบียนหนึ่งในหลาย ๆ สิ่งสามารถเกิดขึ้นได้:

1. บันทึกของคุณไม่มีอยู่
2. บันทึกของคุณมีอยู่ แต่มีการเปลี่ยนแปลงแล้ว
3. บันทึกของคุณมีอยู่และต้องการการเปลี่ยนแปลง

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

การสำรองข้อมูล

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

ข้อสรุป

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

โชคดี!

ณ จุดนี้คุณควรใช้ระบบฐานข้อมูลเกรดเชิงพาณิชย์ที่รองรับสแนปชอต (Oracles เรียกว่าFlashback ) ซึ่งเป็นสิ่งที่พวกเขาต้องการ

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

นี่คือพื้นที่ขนาดใหญ่ - ดังนั้นคาดว่าคำถามนี้จะปิดในค่อนข้างสั้น แต่ปิดหัวของฉัน (เป็น DBA เดิมในฐานข้อมูล yuge):

มาร์ท / พื้นที่เก็บข้อมูล

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

รหัสแหล่งที่มา

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

สร้าง / อัปเดตวันที่

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

ETL

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

การสำรองข้อมูล

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

การกู้คืนเวลา

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

การตรวจสอบบัญชี

การมีตารางการตรวจสอบจะบอกคุณว่าใคร (หรืออะไร) ทำการอัปเดตเป็นแถว นี่เป็นจุดเริ่มต้นที่ดีสำหรับการตรวจสอบ

ประวัติศาสตร์

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

การตรวจสอบข้อมูล

ตรวจสอบให้แน่ใจว่ามีการดำเนินการตรวจสอบความถูกต้องเบื้องต้นกับข้อมูลก่อนที่จะถูกจัดเก็บ - ตรวจสอบชนิดข้อมูลพื้นฐานที่มากกว่าและเหนือกว่า

ความสมบูรณ์ของการอ้างอิง

Referential integrity ไม่ใช่ bullet เงิน แต่สามารถช่วยให้มั่นใจว่าข้อมูลมีโครงสร้างที่ดี

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

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

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