การกำเนิดของ SSD มีความหมายสำหรับการปรับฐานข้อมูลหรือไม่?

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

ใช่พวกเขาเปลี่ยนเกม การปรับให้เหมาะสมตามลักษณะของดิสก์แม่เหล็กหมุน (เช่นหาเวลาและความล่าช้าในการหมุน ) อาจไม่เกี่ยวข้องกับไดรฟ์ SSD กระดาษล่าสุด^*เผยแพร่ใน FITME 2010 นำเสนออัลกอริธึมการเพิ่มประสิทธิภาพคิวรีใหม่หนึ่งรายการตามลักษณะของ SSD

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

^* IEEE Xplore - การปรับเคียวรีหน่วยเก็บข้อมูลแบบคอลัมน์สำหรับฐานข้อมูลแบบแฟลช

ประสิทธิภาพ

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

ความทนทาน

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

การลดราคาโดยรวมของการจัดเก็บมีผลกระทบอย่างลึกซึ้งมากขึ้น

ก่อนที่เราจะมี SQL เรามีฐานข้อมูลแบบลำดับชั้นและเครือข่ายที่ดีที่สุดซึ่ง DBA จำเป็นต้องวางแผนการติดตามและจัดวางข้อมูลอย่างระมัดระวัง

ฐานข้อมูล SQL มีประสิทธิภาพน้อยกว่ามาก แต่ตอนนี้ดิสก์มีราคาถูกมากและรวดเร็วเราแทบไม่สนใจ

ฐานข้อมูล NoSQL ("Document") อาจมีประสิทธิภาพน้อยกว่า SQL เนื่องจากไม่มีความสามารถในการจับคู่แบบตรรกะกับกายภาพระหว่าง SQL schema แบบตรรกะและแบบแผนทางกายภาพพื้นฐานของไฟล์หรือพื้นที่ตารางหรืออะไรก็ตาม และเราแทบจะไม่แคร์

การปรับปรุงประสิทธิภาพของ SSD มีแนวโน้มที่จะหายไปจากการเปลี่ยนแปลงที่เกิดจากการใช้ฐานข้อมูล NoSQL ในแบบที่เราออกแบบระบบโดยรวม

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

SSD มีข้อบกพร่องบางประการเกี่ยวกับการเขียน:

• ขนาดการเขียนบล็อกขั้นต่ำประมาณ 4-8KB
• การเขียนสามารถทำได้แบบเต็มหน้าโดยทั่วไปคือ 256KB
• สามารถเขียนบล็อกว่างได้เท่านั้น

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

มีการปรับแต่งมากมายสำหรับปัญหานี้ที่ใช้งานกับ SSD ตัวควบคุมและแม้แต่ระดับระบบปฏิบัติการ แต่ DBMSs สามารถได้รับประโยชน์อย่างไม่ต้องสงสัยโดยการปรับการปรับแต่งเหล่านี้ให้เหมาะกับการทำงานเฉพาะของพวกเขา

อย่างไรก็ตามนี่ไม่ใช่สิ่งที่ผู้ใช้ฐานข้อมูล (เช่นในการใช้ฐานข้อมูลในแอปพลิเคชันของพวกเขา) ต้องคิดเพราะมันจะขึ้นอยู่กับการตัดสินใจในการออกแบบ / การนำไปใช้ที่ระดับ DBMS

จากสิ่งที่ฉันรวบรวมจากบล็อกServerFaultเซิร์ฟเวอร์ฐานข้อมูลต้องมีฮาร์ดแวร์ที่แข็งแรง เซิร์ฟเวอร์ฐานข้อมูลของไซต์แลกเปลี่ยนสแต็กกำลังใช้งาน SSD (ดูhttp://blog.serverfault.com/post/our-storage-decision/ ) และฉันคิดว่าการเพิ่มประสิทธิภาพการสืบค้นยังคงเป็นสิ่งจำเป็น CPU และหน่วยความจำได้รับผลกระทบจากการสืบค้นฐานข้อมูลและ IO

อย่างไรก็ตามประสิทธิภาพของฐานข้อมูลขึ้นอยู่กับ IO เป็นอย่างมากดังนั้น SSD จะช่วยได้แน่นอน

ใช่ด้วยเหตุผลที่ทุกคนระบุไว้

ฉันกำลังฟังพอดคาสต์บอกว่าชิ้นส่วนขนาดใหญ่ของ RDBMS เช่น Oracle, SQL Server เป็นต้นจะเริ่มเป็น "ตัวเลือก" ถ้าพวกเขาสามารถแยกการทำงานได้อย่างเหมาะสม ตรวจสอบว่าเป็นไดรฟ์ SSD และปรับให้เหมาะสมหรือไม่

มีโค้ดพิเศษจำนวนมากที่สร้างไว้ในแคชและการเขียนข้อมูลที่ไม่ต้องการอีกต่อไป

ที่น่าสนใจยิ่งกว่านั้นคือ RAMSAN และตัวแปรของมัน โดยทั่วไปแล้วฮาร์ดดิสก์ไดรฟ์ที่ทำจากชิปแรมที่มี UPS ในตัว X ชั่วโมงและความสามารถในการเขียนแบ็คกราวด์ไปยังพื้นที่เก็บข้อมูล HDD ในระยะยาว