กลยุทธ์ในการจัดการ SQL Server DB ที่มีไฟล์ (BLOBs) มากเกินไปหรือไม่?


11

สถานการณ์จำลอง:
ฐานข้อมูล SQL Server 2005 ที่ให้บริการแอปพลิเคชัน ASP.NET (บนเว็บเซิร์ฟเวอร์แยกต่างหาก)

ฐานข้อมูล:
DB มีข้อมูล "ปกติ" อยู่ประมาณ 5GB และ "ไฟล์" ประมาณ 15GB (เช่น: ไฟล์ PDF ขนาด 200k ที่จัดเก็บเป็นรูปภาพ (BLOB) ซึ่งเป็นสิ่งนั้น) มีผู้ใช้อัพโหลดไฟล์มากขึ้นและใช้พื้นที่ดิสก์มากขึ้นอย่างรวดเร็ว (ฐานข้อมูลอาจเพิ่มเป็น 50GB ในอีกไม่กี่เดือนข้างหน้าซึ่งส่วนใหญ่เป็นไฟล์)

ข้อกังวล: การ
จัดเก็บไฟล์จำนวนมากในฐานข้อมูลก่อให้เกิดปัญหาอยู่แล้ว (เช่น: ขนาดรวมขนาดใหญ่ของฐานข้อมูลทำให้การสำรองข้อมูลทั้งฐานข้อมูลเป็นครั้งคราวและการปรับใช้ทำได้ยาก)

และเรามีความกังวลใจที่มีจะมีปัญหามากขึ้น (เช่น: ปัญหาด้านประสิทธิภาพ - อาจเกิดจากการไม่สามารถเก็บ DB ทั้งหมดไว้ใน RAM ได้หรือไม่?)

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

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


การอัปเกรดเป็น 2008+ ความเป็นไปได้ซึ่งเป็นส่วนหนึ่งของโซลูชันหรือไม่
Jon Seigel

@ Jon Seigel ใช่มีตัวเลือกอะไรบ้างในปี 2008 (หรือแม้กระทั่งปี 2012)
MGOwen

คำตอบ:


6

ฉันดูแลฐานข้อมูลที่คล้ายกันมากในปัจจุบัน 3TB และเพิ่มขึ้น 5GB ต่อวัน

  • Filestream ( 2008+ ) ไม่ได้แก้ปัญหาการสำรองข้อมูล / เรียกคืน
  • Filestream ทำงานได้ดีกว่าที่จัดเก็บ LOB สำหรับไฟล์> 1MB ดังนั้นการทดสอบของ Paul Randalกล่าว เวิร์กโหลดขึ้นอยู่กับ 256KB-1MB และแย่กว่านั้นที่ 256KB
  • ข้อดีอย่างมากสำหรับ Filestream ในบางสภาพแวดล้อมคือมันผ่านการทำงานของพูลบัฟเฟอร์และใช้แคชระบบ Windows แทน
  • หากคุณวางไฟล์บนระบบไฟล์คุณจะสูญเสียความสอดคล้องของทรานแซคชันกับระเบียนฐานข้อมูล คุณได้เพิ่มค่าใช้จ่ายในการสำรองไฟล์หลายล้านไฟล์ซึ่งอาจเป็นปัญหาได้

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

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

หากคุณติดอยู่ที่ 2005 Standard (การแบ่งเป็นคุณลักษณะรุ่น Enterprise) และคุณมีตัวเลือกอ่านอย่างเดียวสำหรับประวัติคุณสามารถจัดการกับวิธีนี้แบบเก่า

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

ตัวเลือกสุดท้าย (ที่เรากำลังพิจารณาสำหรับ blobber ขนาด 3TB ของเรา) คือการย้ายข้อมูลไฟล์ไปยังฐานข้อมูลเอกสารหรือที่เก็บข้อมูลบนคลาวด์ (เช่นAmazonS3 , Azure BLOB Storage ) นี่จะแนะนำปัญหาความสอดคล้องของทรานแซคชันที่ฉันกล่าวถึงก่อนหน้านี้ แต่ใช้เวลาโหลดจากเซิร์ฟเวอร์ SQL ที่แพงมาก


3

ลองใช้ฟีเจอร์FILESTREAMในเซิร์ฟเวอร์ SQL

FILESTREAM รวมเครื่องมือฐานข้อมูลเซิร์ฟเวอร์ SQL กับระบบไฟล์ NTFS โดยการจัดเก็บข้อมูล varbinary (สูงสุด) วัตถุขนาดใหญ่ไบนารี (BLOB) เป็นไฟล์ในระบบไฟล์

บทความที่ดีเกี่ยวกับเรื่องนี้

  1. คำแนะนำเกี่ยวกับ SQL Server FileStream
  2. เป็น BLOB หรือไม่ถึง BLOB: ที่เก็บวัตถุขนาดใหญ่ในฐานข้อมูลหรือระบบไฟล์
  3. FILESTREAM ที่เก็บข้อมูลใน SQL Server 2008
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.