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

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

ข้อมูล

• มีระเบียนประมาณ 310,000 รายการในฐานข้อมูลทั้งหมด

• ฐานข้อมูลต้องการ 250 GB บนฮาร์ดดิสก์

• รุ่นของเซิร์ฟเวอร์คือ SQL Server 2008 ที่มีระดับความเข้ากันได้ของ SQL Server 2005 (90) แต่เรากำลังวางแผนที่จะอัพเกรดเป็น SQL Server 2012 ในไม่ช้า

ฉันคิดถึงความเป็นไปได้สองอย่าง:

ฐานข้อมูลใหม่

สร้างฐานข้อมูลที่คล้ายกับฐานข้อมูลบนเซิร์ฟเวอร์ที่ใช้งานจริงและแทรกข้อมูลเก่าทั้งหมดลงในฐานข้อมูลใหม่

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

ประวัติความเป็นมา

สร้าง schema fe [hist] ใหม่ด้วยตารางเดียวกันกับในฐานข้อมูลการผลิต แทรกข้อมูลเก่าทั้งหมดในตารางใหม่เหล่านี้ในสคีมาใหม่

• ข้อได้เปรียบ: การเข้าร่วมง่ายหากต้องการข้อมูลเก่าในอนาคต

• คุณเป็นหนึ่งในโซลูชันที่เหนือกว่าอีกหรือไม่
  • ทำไม?
• มีความเป็นไปได้ที่ดีกว่านี้ไหม?
• มีเครื่องมือที่เป็นไปได้ที่จะทำภารกิจนี้ได้อย่างง่ายดายหรือไม่?
• ความคิดอื่น ๆ ?

ขอบคุณล่วงหน้า

แก้ไข

คำถามเพิ่มเติม:

ตารางเก็บถาวรที่สร้างขึ้นใหม่จะต้องใช้คีย์หลัก / ต่างประเทศหรือไม่

หรือพวกเขาควรมีคอลัมน์ แต่ไม่มีคีย์ / ข้อ จำกัด ?

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

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

คุณชอบวิธีการแก้ปัญหามากกว่าวิธีอื่นหรือไม่?

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

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

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

มีความเป็นไปได้ที่ดีกว่านี้ไหม?

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

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

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

ความคิดอื่น ๆ ?

เนื่องจากคุณกำลังใช้รุ่น Enterprise และวางแผนที่จะอัปเกรดเป็น SQL 2008+ คุณอาจพิจารณาการบีบอัดข้อมูลสำหรับตารางนี้ การบีบอัดจะลดพื้นที่ดิสก์อย่างแน่นอน แต่ขึ้นอยู่กับทรัพยากรดิสก์และ CPU ของเซิร์ฟเวอร์ของคุณซึ่งอาจปรับปรุงประสิทธิภาพการสืบค้นสำหรับการอ่านโดยการลดดิสก์ I / O และปรับปรุงการใช้งานหน่วยความจำ (ข้อมูลมีขนาดพอดีกับแคชในเวลาเดียวกัน)

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

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

จากประสบการณ์ของฉันฐานข้อมูลที่สองจะเป็นตัวเลือกที่ต้องการด้วยเหตุผลสองประการ

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

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

เพิกเฉยใบอนุญาตตอนนี้เพราะนั่นไม่ใช่ที่ที่ฉันใช้เวลา

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

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

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

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

ข้อควรพิจารณาที่สำคัญบางประการ:

• ข้อความค้นหาส่งคืนข้อมูลประวัติ / เย็นอย่างสม่ำเสมอหรือมีการเข้าถึงข้อมูลเย็นบ่อยครั้งหรือไม่
• ข้อมูลประวัติไม่เปลี่ยนรูปหรือมีการอัพเดท / ลบอย่างสม่ำเสมอหรือไม่?
• แถว 310 เมตรคือ "ปานกลาง" (สมมติว่าทั้งหมดใน 1 ตาราง) ขึ้นอยู่กับขนาดของแถว คุณมีข้อมูลขนาดแถวหรือไม่? แถว 310 เมตรนั้นมีกี่ GB?
• อัตราการเติบโตของตารางนั้นคืออะไร?
• คุณสามารถแก้ไขรหัสแอปพลิเคชันและแบบสอบถาม SQL ได้หรือไม่

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

นอกจากนี้หากคุณกำลังคิดที่จะอัปเกรดลองพิจารณา 2016 และคุณสมบัติ Stretch Database ใหม่: https://msdn.microsoft.com/en-us/library/dn935011.aspx

ฉันต้องการแยกฐานข้อมูลออกเป็นฐานข้อมูลเชิงตรรกะแยกต่างหากด้วยเหตุผลดังต่อไปนี้:

1. ข้อกำหนดด้านทรัพยากร

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

2. ประสิทธิภาพ

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

3. การสำรองข้อมูลที่ง่ายขึ้น

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

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