เพื่อปรับปรุงประสิทธิภาพของ SQL ทำไมไม่เพียงแค่ใส่แรมจำนวนมากแทนที่จะมีฮาร์ดดิสก์ที่เร็วกว่า?

มีคนบอกฉันว่าเพื่อปรับปรุงประสิทธิภาพของเซิร์ฟเวอร์ SQL ซื้อฮาร์ดดิสก์ที่เร็วที่สุดที่เป็นไปได้ด้วย RAID 5 และอื่น ๆ

ดังนั้นฉันจึงคิดว่าแทนที่จะใช้เงินทั้งหมดสำหรับ RAID 5 และฮาร์ดดิสก์ที่รวดเร็วเป็นพิเศษ (ซึ่งไม่ถูกตามทาง) ทำไมไม่เพียงแค่รับ RAM จำนวนมาก? เรารู้ว่าเซิร์ฟเวอร์ SQL โหลดฐานข้อมูลลงในหน่วยความจำ หน่วยความจำเร็วกว่าฮาร์ดดิสก์ใด ๆ

ทำไมไม่ทำสิ่งต่าง ๆ เช่น RAM ขนาด 100 GB บนเซิร์ฟเวอร์ จากนั้นใช้ฮาร์ดดิสก์ SCSI ปกติกับ RAID 1 นั่นจะไม่ถูกและเร็วกว่านี้มากใช่ไหม

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

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

2. ประสิทธิภาพการเขียนสำหรับฐานข้อมูลของคุณจะยังคงถูก จำกัด โดยดิสก์ดังนั้นคุณสามารถรักษาสัญญาที่ว่าข้อมูลถูกจัดเก็บจริง

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

(นอกเหนือจากนี้คนที่บอกให้คุณใช้ RAID-5 สำหรับประสิทธิภาพของฐานข้อมูลอาจไม่ใช่คนที่ดีที่จะฟังในเรื่องนี้เพราะมันแทบจะไม่เคยเป็นตัวเลือกที่ดีที่สุด - มันมีประสิทธิภาพในการอ่านที่ดี แต่ประสิทธิภาพการเขียนที่แย่ มักเป็นข้อ จำกัด ในการผลิต - เนื่องจากคุณสามารถใช้ RAM ในการแคชเพื่อแก้ไขปัญหาด้านประสิทธิภาพการอ่านส่วนใหญ่)

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

ถ้าคุณต้องการความเร็ว:

• เพิ่ม RAM เพื่อให้ดัชนีที่ใช้งานอย่างน้อยสามารถพอดีกับ RAM ได้ (ตัวอย่างเช่นในระบบที่ฉันทำงาน 32GB RAM มีอยู่มากมายสำหรับฐานข้อมูล 350GB เนื่องจากดัชนีเป็นสิ่งที่คุณต้องการใน RAM ไม่ใช่ข้อมูลดิบ)
• ใช้ RAID10 กับดิสก์ใด ๆ (เร็วกว่าดิสก์ดีกว่า)
• หลีกเลี่ยง RAID5
• แยก mdf, ldf และ temp DB ลงในชุดแกนหมุนแยก (ตัวอย่าง: tempdb ในชุด RAID1 ของตัวเอง, ldf บนชุดแกนหมุน RAID1 หรือ RAID10 ของตัวเอง, mdf บนชุด RAID 10 อย่างน้อย 4 ดิสก์ทั้งหมด)

ทำตามขั้นตอนเหล่านั้นแล้ว SQL Server จะทำการบิน

ถ้าคุณต้องการให้เพิ่ม RAM เพิ่มเติม แต่ทำตามข้างบนก่อนและคุณอาจพบว่าคุณทำเสร็จแล้ว

RAM เป็นดิสก์ใหม่ดิสก์คือเทปใหม่

ในhttp://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids โปรดทราบว่าเมื่อหกปีก่อน ใช่เรามีระบบฐานข้อมูลที่พยายาม (และพยายามอย่างหนัก) เพื่อเก็บชุดข้อมูลทั้งหมดไว้ใน RAM และค่อนข้างจะใช้กับเครื่องหลายเครื่องแทนที่จะใช้ดิสก์เพราะดิสก์มีขนาดที่ช้ากว่าอย่างไรก็ตาม คุณต้องเขียนชุดข้อมูลไปยังดิสก์ แต่ในคำขวัญข้างต้นนั้นคล้ายกับงานสำรองข้อมูลเบื้องหลังมากกว่าการดำเนินการออนไลน์ ความทนทานนั้นทำได้ผ่านการผนวกเฉพาะบันทึกที่มีฐานข้อมูลเหล่านี้ (ฉันคิดว่า MongoDB และ Redis แต่มีอีกมากมาย)

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

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

สำหรับการอ่านเพิ่มเติมในหัวข้อนี้ฉันแนะนำบทความวิชาการThe End of a Architectural Era (ถึงเวลาแล้วสำหรับการเขียนซ้ำทั้งหมด) มันไม่ใช่เรื่องยากที่จะอ่าน

ไม่ชัดเจนหากคำถามนี้เกี่ยวกับ SQL Server โดยเฉพาะ ผู้โพสต์ดั้งเดิมควรชี้แจงเรื่องนี้

Daniel Pittman เขียนว่า:

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

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

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

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

น่าเศร้าที่ RDBMS ดูเหมือนจะอยู่ในอาณาจักรเหล็กขนาดใหญ่ - มันไม่ง่ายเลยที่จะเติบโตในแนวนอน

นี่เป็นกรณีของ "มันขึ้นอยู่กับสิ่งที่คุณกำลังทำ" บางทีคำแนะนำ "ถูกต้อง" คือหลีกเลี่ยง SQL ทั้งหมดและใช้ memcache / redis / etc!

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

อย่างไรก็ตามประสิทธิภาพของดิสก์มักจะเป็นปัญหาคอขวดบนเซิร์ฟเวอร์ SQL และหนักกว่าสิ่งอื่น ๆ เช่น RAM ที่จะอัปเกรดในภายหลัง (หากคุณมีเซิร์ฟเวอร์ที่ไม่ได้รับการเติมด้วย DIMM)

มีความคิดเห็นจำนวนหนึ่งเกี่ยวกับ RAID5 ที่ช้า แต่ฉันอยากจะบอกว่ามันไม่ได้เป็นเช่นนั้นเสมอไปดังนั้นควรระวังก่อนที่จะทำการกวาดงบ เซิร์ฟเวอร์ระดับไฮเอนด์จริงๆที่มีการ์ด RAID ที่รวดเร็วและ BBWC จำนวนมากบางครั้งก็เร็วกว่ามากใน RAID5 (หรือ RAID50 ที่มีมากกว่า 4 ดิสก์) มากกว่าที่ทำใน RAID10 ...

ในช่วงหลายปีที่ผ่านมาฉันพบกับอาร์เรย์ RAID5 ที่ช้า แต่หลังจากการเปรียบเทียบ DL360 G5 กับดิสก์ 4 ชุด 146G ในปี 2009 เราต้องตรวจสอบการทดสอบอีกครั้ง แท้จริงแล้วอาร์เรย์นั้นเร็วกว่าด้วย RAID5 มากกว่า RAID10 ในเกือบทุกการทดสอบ BBWC และการคำนวณพาริตีที่รวดเร็วช่วยให้เซิร์ฟเวอร์สามารถใช้ดิสก์ 4 ดิสก์ได้อย่างมีประสิทธิภาพมากขึ้นในฐานะอาร์เรย์ RAID5 มากกว่า RAID10 การทดสอบบางอย่างแสดงให้เห็นถึงปริมาณงานที่ดีขึ้น 50% เมื่อใช้ RAID5 และเกือบจะไม่มีเลยเลย การทดสอบที่ช้าลงเพียง 5-10% เท่านั้น

ฉันขอเตือนผู้ที่ทำงบแบบครอบคลุมว่า RAID5 ช้าทุกคนบอกว่ามันออนไลน์ แต่มันก็ไม่จริงในทุกกรณี

คุณมีถุงขนมหลายแบบให้เลือกและขึ้นอยู่กับว่าคุณต้องการรสชาติแบบไหน

1. ฐานข้อมูลจะมีการกำหนดค่าให้คิวรีแคชและที่แคชนี้มีอยู่หน่วยความจำหรือฮาร์ดไดรฟ์
2. RAID 5 ไม่ได้เร็วที่สุดเสมอไป แต่ RAID 0 (JBOD) เป็นแถบและรวดเร็วเนื่องจาก RAID 5 ยังเป็นแถบความคิดก็เหมือนกันมาก
3. RAID 1 จะไม่ปรับปรุงความเร็วของคุณมันเป็นเพียงกระจกเงา
4. ประสิทธิภาพของ SQL ขึ้นอยู่กับการทำดัชนีและเป็นสิ่งแรกที่ต้องตรวจสอบ สำคัญมากในฐานข้อมูลเชิงสัมพันธ์
5. อย่าทำดัชนีทุกอย่างการทำดัชนีมากกว่าสามารถลดความเร็วได้เนื่องจากการทำดัชนีของคุณโหลดเกิน
6. บางครั้งกับ SQL เข้าร่วมฐานข้อมูลจะช้าลง การใช้การเขียนโปรแกรมเพื่อวนชุดผลลัพธ์ที่มีการทำดัชนีขั้นต่ำจะช่วยเพิ่มความเร็ว
7. เซิร์ฟเวอร์เสมือนเป็นฝันร้ายของความเร็วหากคุณไม่จ่ายเงินดอลลาร์

เพียงแค่ลงทุนในความรู้ (ฟรี) ก่อนที่จะขายเงินสด 1. เรียนรู้การกำหนดค่าสำหรับฐานข้อมูลของคุณและดูการกำหนดค่าปัจจุบันของคุณเพื่อปรับให้เหมาะสม 2. ดูคำสั่งการเขียนโปรแกรมและ sql ทดสอบหน่วยด้วยสคริปต์ง่าย ๆ ที่เลียนแบบการดำเนินการที่เกี่ยวข้องอาจไม่ได้เป็นอย่างที่คุณคิดว่าเป็นปัญหา ถ้าสคริปต์ง่าย ๆ ใช้เวลาในการใช้ SQL Joins ให้แยกและทำสิ่งเดียวกันกับลูปที่ตั้งโปรแกรมไว้ให้ทำเช่นเดียวกัน นี่คือความทรงจำที่สามารถช่วย 3. ดูที่แผนการโฮสต์และเซิร์ฟเวอร์ ใช้ ps aux ในคอนโซลลินุกซ์และดูว่ามีบางอย่างที่ดูดหน่วยความจำและโปรเซสเซอร์ของคุณหรือไม่

ฮาร์ดไดรฟ์แบบสมบูรณ์ช่วยเพิ่มความเร็ว แต่ไม่ขึ้นอยู่กับคุณในพื้นที่เซิร์ฟเวอร์เสมือน หน่วยความจำไม่ได้ปรับปรุงความเร็วจนกว่าคุณจะกำหนดค่าบริการสำหรับช่วงเวลา Stripe RAID (0,5), RPM และการอ่าน / เขียนแบบซิงโครนัสด้วยบัสที่รวดเร็วช่วยได้ หน่วยประมวลผลหลักที่มีแคช l1, l2, l3 ที่ดีจะช่วยในการประมวลผลคอขวด ฉันขอฟังให้ Xeon ได้ไหม!

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

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