ฐานข้อมูล SQL Server บน SSD - มีประโยชน์กับไฟล์แยกกันสำหรับทุกตารางหรือไม่?


19

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

เมื่อฉันต้องการบีบประสิทธิภาพออกมาจากฮาร์ดแวร์ที่มีอยู่ (เช่น RAM 64GB, SSD ที่เร็วมากและ 16 คอร์) ฉันคิดว่าจะอนุญาตให้แต่ละตารางมีไฟล์ของตัวเองได้ ฉันกำลังเข้าร่วมใน 2, 3, 4, 5 หรือมากกว่าตารางแต่ละตารางจะถูกอ่านโดยใช้เธรดแยกต่างหากและโครงสร้างของแต่ละไฟล์จะได้รับการจัดตำแหน่งอย่างใกล้ชิดกับเนื้อหาของตารางซึ่งหวังว่าจะช่วยลดการกระจายตัวและทำให้เร็วขึ้น สำหรับ SQL Server เพื่อเพิ่มเนื้อหาของตารางใดก็ตาม

หนึ่งข้อแม้ผมติดอยู่ใน SQL Server 2008 R2 Web Edition ซึ่งหมายความว่าฉันไม่สามารถใช้การแบ่งพาร์ติชันในแนวนอนอัตโนมัติซึ่งเป็นกฎที่ออกมาเป็นการยกระดับประสิทธิภาพ

จะใช้หนึ่งไฟล์ต่อตารางจริง ๆ แล้วเพิ่มประสิทธิภาพหรือไม่หรือฉันกำลังมองหาคุณลักษณะเอ็นจิน SQL Server ในตัวที่จะทำให้ซ้ำซ้อน?

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

คำตอบ:


18

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

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

หากคุณต้องการอ่านการสนทนาที่ดีเกี่ยวกับประสิทธิภาพของ SSD สำหรับ SQL Server มีบล็อกหลายชุด โดยปกติแล้วหนึ่งใน Paul Randal เป็นอ่านด้านบน:

เบรนต์ยังมีการนำเสนอที่ดีในหัวข้อ: SQL บน SSD: Hot and Crazy Loveและยังมีอีกมาก

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


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

17

ข้อเสนอแนะแรกของฉันคือจะไม่ตั้งสมมติฐานใด ๆ เกี่ยวกับประสิทธิภาพโดยไม่ทำการทดสอบโหลดกับการกำหนดค่าทั้งสอง

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

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

ป้อนคำอธิบายรูปภาพที่นี่

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


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

@NathanRidley โอเคเข้าใจ ... ฉันคิดว่าคำตอบที่แท้จริงถ้าไม่มีใครมีทรัพยากรที่พูดว่า "ไม่เคยทำแบบนี้" ว่าแนวทางการปฏิบัติที่ดีที่สุดคือการเปรียบเทียบการกำหนดค่าสองแบบกับภาระงานทั่วไปของคุณและดูว่ามีความแตกต่างที่วัดได้
Michael Fredrickson

4

ดังที่คนอื่น ๆ ระบุไว้ไม่มีประโยชน์โดยตรงจากไฟล์หนึ่งไฟล์ต่อตาราง นี่เป็นบทสรุปที่ยอดเยี่ยมจาก Steve Jones เกี่ยวกับตำนานที่มานี้: http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

คุณอาจต้องการตรวจสอบมุมมองที่แบ่งพาร์ติชันซึ่งฉันเชื่อว่าได้รับการสนับสนุนโดย 2008 Web Edition มีเทคนิคบางอย่างในการเขียนโค้ดกับมุมมองที่แบ่งพาร์ติชัน แต่คุณสามารถเลียนแบบการทำงานของตารางที่แบ่งพาร์ติชันได้ค่อนข้างง่าย


2

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

SQL Server 2008 R2 รองรับการบีบอัดหรือไม่ ถ้าใช่เปิดใช้งาน

ช่วยแก้ให้ด้วยนะถ้าฉันผิด.


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

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

ของคุณถูกต้องเกี่ยวกับเธรดแบบขนาน (ตาราง / ไฟล์) แต่ฉันคิดว่าจนกว่าคุณจะมีดิสก์ทางกายภาพเดียวเท่านั้นประสิทธิภาพการทำงานจะเพิ่มขึ้นเล็กน้อย

และฉันขอแนะนำให้คุณใช้อาร์เรย์ HDD RAID ที่แข็งแกร่งสำหรับฐานข้อมูลเพราะ SSD จะตายในไม่ช้า
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.