ข้อมูล MySQL ขนาดใหญ่ที่สามารถนำเข้ามาใน SSD สร้างความเสียหายได้หรือไม่

ฉันต้องนำเข้าข้อมูลจำนวนมาก (~ 100 ล้านแถว, ~ 100 ครั้ง) ในฐานข้อมูล MySQL ปัจจุบันมันถูกเก็บไว้ในฮาร์ดดิสก์ของฉันและคอขวดของการนำเข้าของฉันน่าจะเป็นความเร็วในการเขียนของฮาร์ดดิสก์

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

มันไม่ใช่คำตอบที่ตรงไปตรงมาสำหรับเรื่องนี้

SSD ไม่สนใจเกี่ยวกับการเขียนต่อเนื่องเท่าที่จะมีการเขียนทับเซ็กเตอร์ใด ๆ เมื่อ SSD ออกมาครั้งแรกบางสิ่งเช่น SQL นั้นเป็นคำที่ไม่ดีเนื่องจากระบบปฏิบัติการโดยทั่วไปถือว่าไดรฟ์เหมือน HDD แบบดั้งเดิมและความล้มเหลวก็เกิดขึ้นบ่อยมาก

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

SSD ใน SQL ไม่เพียง แต่เป็นเรื่องธรรมดา แต่มักสนับสนุน รู้สึกอิสระที่จะอ่านเว็บไซต์น้องสาว DBA

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

การอ่านเป็นเรื่องปกติและ SSD สามารถอ่านบิตของพวกเขาได้โดยไม่มีผลเสียใด ๆ

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

ให้ฉันบอกว่าขีด จำกัด การเขียนบนไดรฟ์องค์กรใหม่มีขนาดใหญ่มาก ใช้ 845DC Pro ใหม่ของ Samsung เป็นการดีที่ 10 ไดรฟ์เขียนต่อวันเป็นเวลา 5 ปีในการรับประกัน ฉันคิดว่ามันจะทำสองครั้ง ในการใส่ตัวเลขลงไปนั้นนั่นคือ 14,600 TB ที่เขียนขึ้นใน 5 ปีสำหรับรุ่น 800 GB
หรือ TB 2,920 ต่อปี
หรือ 8 TB ต่อวันเป็นเวลาห้าปี

แสดงให้ฉันเห็นฮาร์ดไดรฟ์พร้อมการรับประกันที่ครอบคลุมการใช้งานมาก ฉันไม่แน่ใจด้วยซ้ำว่าคุณสามารถเขียน 8 TB ลง HDD ได้ในหนึ่งวัน: - (50 MB / s ปริมาณงานเฉลี่ย * 60 (วินาที) * 60 (นาที) * 24 (ชั่วโมง) = 24320,000 MB / วัน = 4.32 TB / วัน) ปรากฎว่าคุณไม่สามารถทำได้ (ในไดรฟ์เฉลี่ย)

ตราบใดที่คุณใช้ไดรฟ์เช่นนี้ตาม V-NAND (หรือ SLC ที่ทนทานเท่า ๆ กัน) ไม่ใช่หนึ่งในแฟลช TLC หรือ MLC ที่ไม่ดีคุณควรจะใช้ได้ และต่อไปRAID 10และการสำรองข้อมูลก็เป็นเพื่อนของคุณด้วยเหตุผล และอย่างน้อยถ้าขีด จำกัด การเขียน SSD กลายเป็นปัญหาคุณยังสามารถอ่านข้อมูลที่เก็บไว้ในบิตที่ผิดปกติได้

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

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

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

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

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

หมายเหตุ: RAID arrays ไม่ใช่ข้อมูลสำรอง !!!! ไม่ว่าคุณจะใช้อาเรย์ RAID หรือไม่ก็ตามให้ทำการสำรองข้อมูล ไม่ว่าคุณจะใช้ SSD หรือไม่ก็ตามให้มีการสำรองข้อมูล

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

ซึ่งหมายความว่าเมื่อมีการเพิ่มข้อมูลจะถูกเขียนไปยังภาคใหม่เสมอ อาจจะมีบางบัฟเฟอร์ / แลกเปลี่ยนที่ได้รับการปั่น / เขียนไปหลายครั้ง แต่ไม่สนใจว่าทั้งหมดของแทรกทฤษฎีเหล่านั้นจะส่งผลให้ไม่เกินหนึ่งเขียนต่อภาค ขึ้นอยู่กับวิธีการใช้งาน MySQL และการแทรกจำนวนมากที่คุณกำลังทำคุณอาจสร้างชุดที่สองของการเขียนในภายหลังเมื่อบันทึกธุรกรรมถูกรวมเข้ากับไฟล์ข้อมูลหลัก (ฉันจะเข้าใจเครื่องมือฐานข้อมูลที่แตกต่างกัน และสมมติว่า MySQL นั้นค่อนข้างคล้ายกันในการล้างข้อมูลบันทึกธุรกรรม)

ประเด็นก็คือคุณไม่ได้ "ปั่น" SSD นั่นคือคุณไม่ได้ทำการปรับเปลี่ยน / ย้าย / ลบ / etc อย่างมาก ที่อาจจะเขียนทับภาคส่วนเดิมหลาย ๆ ครั้ง ดังนั้นคุณจะต้องสร้างงานเขียนจำนวนน้อยมากต่อเซ็กเตอร์และนั่นเป็นสิ่งที่สำคัญจริงๆ

สมมติว่าคุณยังไม่ได้เติม SSD อย่างสมบูรณ์ควรมีพื้นที่ว่างเพียงพอสำหรับฮอตสปอตเหล่านั้น (เช่นบัฟเฟอร์ / swap) ที่ถูกปั่นเพื่อลดการสึกหรอผ่านขั้นตอนวิธีการปรับระดับการสึกหรอ

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

นี่ไม่มีปัญหา

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

นอกจากนี้คำสั่งนี้:

SSD ไม่ชอบการเขียนต่อเนื่องขนาดใหญ่และมีแนวโน้มที่จะสร้างความเสียหายได้

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

ซึ่งแตกต่างจากฮาร์ดดิสก์แบบดั้งเดิม SSD (หรือมากกว่าแฟลชที่อยู่ใน NAND) จัดอยู่ในบล็อกขนาดใหญ่ซึ่งมีหลายส่วนตามหลักเหตุผล ขนาดบล็อกทั่วไปคือ 512kB ในขณะที่เซกเตอร์ (ซึ่งเป็นหน่วยที่ระบบไฟล์ใช้) เป็นแบบดั้งเดิม 1kB (ค่าที่แตกต่างกันเป็นไปได้สองทศวรรษที่ผ่านมา 512B เป็นเรื่องธรรมดา)
สามสิ่งสามารถทำได้ด้วย 512kB-block สามารถอ่านได้จากส่วนหนึ่งส่วนหรือทั้งหมดสามารถตั้งโปรแกรม (= เขียนถึง) และสามารถลบได้ทั้งหมด การลบเป็นสิ่งที่เป็นปัญหาเพราะมีจำนวน จำกัด รอบการลบและคุณสามารถลบบล็อกที่สมบูรณ์เท่านั้น

ดังนั้นการเขียนที่มีขนาดใหญ่นั้นเป็นมิตรกับ SSD มากในขณะที่การเขียนที่มีขนาดเล็กนั้นไม่ใช่

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

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

SSD ไม่ชอบเลย หากคุณให้ความเร็วในการเขียนสูงสุด 5-10 ปี (24 ชั่วโมงต่อวัน 7 วันต่อสัปดาห์) จากนั้นคุณอาจจบด้วย SSD ที่ชำรุด

Ofc หลังจาก 5 ปีที่ผ่านมาเซิร์ฟเวอร์ส่วนใหญ่ถึงจุดจบของชีวิต

คำเตือน:
อย่าลองสิ่งนี้กับ SSD รุ่นแรก ผู้ที่แข็งแกร่งน้อยกว่า

หากคุณสนใจที่จะหารายละเอียดอย่างแท้จริงคุณจะต้องตอบคำถามต่อไปนี้:

โดยเฉลี่ยมีกี่ไบต์ในแต่ละแถว?

หากคุณสามารถบอกฉันได้ว่ามี 10 คอลัมน์แต่ละคอลัมน์คือ varchar (100) และการเข้ารหัสคือ UTF-8 ฉันสามารถเดาได้ว่าในกรณีที่เลวร้ายที่สุดที่คุณมีข้อมูลไบต์ละ 4,000 ไบต์และเพิ่มจำนวนไบต์เพิ่มเติมสำหรับ meta-data จะบอกว่า 4,200 ไบต์?

SQL ทรมานของคุณจะคำนวณ4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesข้อมูลที่เขียนลงดิสก์

42,000,000,000,000 / 1,000 = 42,000,000,000 KB

42,000,000,000 / 1,000 = 42,000,000 MB

42,000,000 / 1,000 = 42,000 GB

42,000 / 1,000 = 42 TB

ในสถานการณ์สมมติกรณีเลวร้ายที่สุดในทางทฤษฎีนี้คุณจะเขียน 42 TB ลงในดิสก์

ตามบทความนี้จัดทำโดย @KronoS คุณน่าจะดีสำหรับการทรมาน SQL อีก 25 รอบ

ดังที่โปสเตอร์ของการเขียนบน SSDกล่าวว่าสิ่งที่เป็นอันตรายจริงๆคือการเขียนข้อมูลขนาดเล็กอีกครั้ง

• บิตถูกเก็บไว้ในเซลล์ {บิต 1,2,3} บิต สิ่งเหล่านี้มีอายุขัยที่ จำกัด
• เซลล์ถูกจัดกลุ่มเป็น [2-16] หน้า KB (หน่วยที่เขียนได้น้อยที่สุด)
• หน้าถูกแบ่งออกเป็นบล็อก (128-256 หน้า -) (หน่วยลบที่เล็กที่สุด)
• เพื่อให้หน้าถูกเขียนใหม่มัน - และบล็อกทั้งหมด - จะต้องลบก่อน

นั่นคือเหตุผลที่แนะนำให้

• ไม่เคยเขียนน้อยกว่าหน้าในครั้งเดียว
• บัฟเฟอร์ขนาดเล็กเขียนและ
• แยกคำขออ่านและเขียน
• "การเขียนแบบเธรดเดี่ยวขนาดใหญ่ดีกว่าการเขียนพร้อมกันขนาดเล็กจำนวนมาก"

ดังนั้นจำนวนมากในคราวเดียวดูเหมือนจะดีขึ้น