SQL Server - ฐานข้อมูลแยกต่างหากสำหรับรายงาน?


19

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

ขั้นตอนการจัดเก็บอยู่ในฐานข้อมูลเดียวกับข้อมูลในรายงาน ตัวอย่างเช่น procs ที่ให้บริการรายงานสต็อคอยู่ในฐานข้อมูลสต็อค บางรายงานแสดงข้อมูลจากฐานข้อมูลมากกว่าหนึ่งฐานข้อมูลจากนั้น proc จะอยู่ในฐานข้อมูลแหล่งใดแหล่งหนึ่ง พารามิเตอร์รายงานรับข้อมูลจาก procs ในฐานข้อมูลองค์กรที่มีข้อมูลเช่นร้านค้าพนักงาน ฯลฯ

ซึ่งหมายความว่ารายงานทั้งหมดมีการเชื่อมต่อกับฐานข้อมูลองค์กรอย่างน้อยและการเชื่อมต่ออื่นไปยังฐานข้อมูลอื่น - และบางครั้งมากกว่านั้น

คำถามของฉันคือจะมีประโยชน์ในการเคลื่อนย้าย procs รายงานเข้าแยก "รายงาน" ฐานข้อมูล ฉันรู้ถึงประโยชน์ของการย้ายรายงานไปยังเซิร์ฟเวอร์อื่นและฉันไม่ได้พูดถึงเรื่องนี้ - มันจะอยู่บนเซิร์ฟเวอร์เดียวกัน

สิ่งที่อาจส่งผลกระทบต่อสิ่งนี้คือ:

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

โปรดแจ้งให้เราทราบว่าคุณคิดอย่างไร


คำถามของฉันคือ: เมื่อคุณย้าย RS และ / หรือ DW ไปยังเซิร์ฟเวอร์อื่นคุณมีโปรแกรมฐานข้อมูลที่มีอยู่ในเซิร์ฟเวอร์ใหม่ (เหล่านี้) หรือไม่ หรือคุณใช้โปรแกรมฐานข้อมูลต้นฉบับอยู่ - ดังนั้นคุณต้องมีเครื่องมือฐานข้อมูลแยกต่างหากสำหรับเซิร์ฟเวอร์ SQL ทั้งหมดหรือไม่ ขอขอบคุณ - Dom

ใช่เรามีเอ็นจิ้นฐานข้อมูลแยกต่างหากในแต่ละเซิร์ฟเวอร์: เซิร์ฟเวอร์ db และเซิร์ฟเวอร์ DW ตั้งแต่ถามคำถามเราได้อยู่กับการออกแบบดั้งเดิมของเราในการเก็บรายงานในฐานข้อมูลเดียวกัน (และเซิร์ฟเวอร์เดียวกัน) เป็นแหล่งข้อมูล นอกจากนี้เรายังย้ายข้อมูลไปยังเซิร์ฟเวอร์คลังข้อมูลที่ผู้ใช้เข้าถึงผ่านคิวบ์การวิเคราะห์เซิร์ฟเวอร์ SQL

คำตอบ:


17

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

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

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

2

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

ฉันยังพบนี้บทความที่มีประโยชน์


1

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

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


1

ฉันขอแนะนำให้คุณใช้สองฐานข้อมูล

การรับรายงานจากฐานข้อมูล 'สด' ทำให้เกิดปัญหาประสิทธิภาพการทำงาน

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


0

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

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