ข้อดี / ข้อเสียของการใช้หลายฐานข้อมูลเทียบกับการใช้ฐานข้อมูลเดียว


14

ฉันกำลังทำงานในโครงการใหม่ที่มีความต้องการใช้ฐานข้อมูล 7 ตัวโดยยืนยันว่าประสิทธิภาพเสถียรภาพการปรับให้เหมาะสมนั้นง่ายขึ้น

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

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

ข้อดี / ข้อเสียที่ดีในการใช้ฐานข้อมูลเดียวหรือหลายฐานข้อมูลคืออะไร

[สรุปแล้ว]

ข้อโต้แย้งกับฐานข้อมูลหลายแห่ง:

  • การสูญเสียความถูกต้องของข้อมูล (ไม่สามารถใช้ foreign key แทนฐานข้อมูล)

  • สูญเสียคืนความสมบูรณ์

  • การเพิ่มความซับซ้อน (ผู้ใช้ db / บทบาท)

  • เซิร์ฟเวอร์ / ฐานข้อมูลอัตราต่อรองขนาดเล็กจะลดลง

Solutions:

  • ใช้สกีมาเพื่อแยกโดเมน

  • POC: ใช้ข้อมูลจำลองเพื่อพิสูจน์จุดในแผนการดำเนินการของ 7/1 db


นี่คือพื้นที่ที่ซับซ้อนและมีข้อดีและข้อเสีย - ดูที่นี่และลิงค์ภายใน
Vérace

คำตอบ:


16

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

ทรัพยากรไม่ได้ถูกจัดสรรไปยังฐานข้อมูล: SQL Server Instance สร้างสมดุลของทรัพยากรดังนั้นจึงไม่แตกต่างกัน

คุณแพ้:

  • ความสมบูรณ์ของข้อมูล
  • คืนค่าความสมบูรณ์ (ข้อมูลใน DB7 จะเป็นภายหลังจากนั้น DB1)

คุณได้รับความซับซ้อน:

  • ความปลอดภัย (ผู้ใช้บทบาท ฯลฯ ) ต้องอยู่ในฐานข้อมูลทั้งหมด
  • คุณจะมีข้อมูลบางอย่างที่ไม่พอดีกับฐานข้อมูล 1 อย่าง

ตัวเลือก:

  • การแยกฐานข้อมูลลงในดิสก์แยกต่างหากสามารถทำได้ด้วยกลุ่มไฟล์
  • ใช้สกีมาเพื่อแยกข้อมูลอย่างมีเหตุผล (ขึ้นอยู่กับคำตอบอื่น ๆ )

6

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

ไม่มีการปรับประสิทธิภาพให้เหมาะสมกับฐานข้อมูลหลายตัวที่คุณไม่สามารถทำได้ด้วยฐานข้อมูลเดียว คุณสามารถให้รายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่คุณหมายถึงโดย "ประสิทธิภาพเสถียรภาพเพิ่มประสิทธิภาพ"


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

5

หากคุณแยกข้อมูลด้วยโดเมนแบบโลจิคัลคุณสามารถดูได้โดยใช้ schemas ภายใน SQL2008 (แยกจากค่าเริ่มต้นของ dbo) แต่ถึงแม้จะเจ็บปวดและอาจทำให้เกิดปัญหากับ OR / Ms ที่ไม่ได้คาดหวังว่า คีมามาตรฐาน

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

เป็นการทดสอบสร้างฐานข้อมูล 7 จำลอง สร้างแบบสอบถามที่ต้องการข้อมูลพร้อมกันจากทั้ง 7 หรืออย่างน้อยก็เป็นจำนวนที่ดีของพวกเขา

จากนั้นเปรียบเทียบแผนการดำเนินการ! ฉันคิดว่าคุณจะชนะคดีของคุณที่นั่น


ความคิดของฉันคือการใช้สคีมาของโดเมนโลจิคัล จะใช้โมเดลข้อมูลเอนทิตีด้วย เป็นอีกทางเลือกหนึ่งฉันจะลอง 8 dummy db's :)

4

การทดลองทางความคิด: แทนที่จะแบ่งฐานข้อมูลของคุณเป็นเจ็ดชิ้นให้แยกออกเป็น 7,000 ชิ้น โอกาสที่ความล้มเหลวของฮาร์ดแวร์จะส่งผลกระทบต่อแอปพลิเคชันของคุณคืออะไร หากมีโอกาส 0.1% ที่เซิร์ฟเวอร์เฉพาะใด ๆ อาจตายในแต่ละวันโอกาสของคุณดีกว่าหรือแย่กว่านั้นคือคุณจะได้รับผลกระทบจากความล้มเหลวของฮาร์ดแวร์เมื่อเพิ่มจำนวนเครื่องที่คุณต้องพึ่งพา

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

การทำลายฐานข้อมูลในหลาย ๆ เครื่องไม่ดีสำหรับหลาย ๆ เหตุผลที่อธิบายโดยคำตอบอื่น ๆ ในหัวข้อนี้

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


2

ฉันเห็นด้วยกับหนึ่งฐานข้อมูลและใช้ตัวเลือกไฟล์และสคีมาแทน

มีกล่องขอบที่แยกออกเป็นหลายชิ้นทำให้รู้สึก

การกำหนดค่าสภาพแวดล้อมของแอปพลิเคชัน (dev, test, prod), เช่นเซิร์ฟเวอร์ FTP, ส่งออกพา ธ ไฟล์, ฯลฯ ... , สิ่งที่คุณต้องการจัดเก็บต่อเซิร์ฟเวอร์และไม่ถูกเขียนทับในการกู้คืน

ยังเป็นวิธีในการแยกการเปลี่ยนแปลงขั้นตอนเฉพาะลูกค้า

แต่สิ่งเหล่านี้คือการสนับสนุนและไม่ใช่ปัญหาด้านประสิทธิภาพ

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