ฐานข้อมูลหนึ่งต่อไคลเอนต์กลายเป็นจุดที่ไม่สามารถทำได้?


31

สำหรับหนึ่งในระบบของเราเรามีข้อมูลลูกค้าที่ละเอียดอ่อนและจัดเก็บข้อมูลลูกค้าแต่ละรายในฐานข้อมูลแยกต่างหาก เรามีลูกค้าประมาณ 10-15 คนสำหรับระบบนั้น

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

ความคิดใด ๆ เกี่ยวกับเรื่องนี้?


ฉันไม่ทราบถึงข้อดีข้อเสียของการมีฐานข้อมูลหลายตัวต่อเซิร์ฟเวอร์ (ฉันไม่เคยมีปัญหาใด ๆ กับเรื่องนี้) แต่แนวคิด schemas หลายแนวคิดtechnet.microsoft.com/en-us/library/dd207005.aspxภายในฐานข้อมูลเดียวกันมีทั้ง การแยกและความปลอดภัย ดังนั้นคุณสามารถลองสถาปัตยกรรมนี้เช่นกัน
Alexandros

2
@Alexandros แยกสคีข้อเสนอเล็ก ๆ น้อย ๆ แต่ก็ไม่ได้ช่วยให้คุณสามารถใช้แบบจำลองการกู้คืนที่แยกจากกันกลับขึ้นไปบนตารางเวลาที่แตกต่างกันเรียกคืนลูกค้าคนหนึ่งไปยังจุดที่เฉพาะเจาะจงในเวลาเอาลูกค้าคนหนึ่งได้อย่างง่ายดายย้ายลูกค้าคนหนึ่งได้อย่างง่ายดายและอื่น ๆ
Aaron Bertrand

4
ฉันเคยเห็นระบบที่มีฐานข้อมูล 3,000+ (1 ต่อลูกค้า) บนเซิร์ฟเวอร์เดียว ฉันจะไม่กังวลมากเกินไป - เพียงให้แน่ใจว่าคุณวางแผนทรัพยากรอย่างรอบคอบและตรวจสอบการใช้งานเมื่อจำนวนลูกค้าเพิ่มขึ้น
Max Vernon

คุณอาจอ่านสิ่งนี้โดยเฉพาะบันทึกวันที่และความคิดเห็นของ ops: stackoverflow.com/questions/5596755/…
NotMe

คำตอบ:


48

การจัดการฐานข้อมูล 100 หรือ 500 นั้นไม่ใช่สิ่งที่แตกต่างจากการจัดการ 5 หรือ 10 - คุณเพียงแค่ต้องยอมรับระบบอัตโนมัติและมีแผนขยายขีดความสามารถในสถานที่ (และไม่ได้วางแผนที่จะใช้คุณสมบัติที่มีต้นทุนต่อฐานสูงเช่น ลูกค้า)

ที่งานก่อนหน้าของฉันเราใช้สถาปัตยกรรมนี้และฉันจะไม่เคยคิดที่จะรวมลูกค้าสองรายไว้ในฐานข้อมูลเดียวแม้ว่าความท้าทายบางอย่างอาจ "ยาก"

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

ฉันตอบข้อคัดค้านหลายข้อและ / หรือวิธีการแก้ไขปัญหาในโพสต์เหล่านี้:

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


6
คุณจะต้องมีหลักการตั้งชื่อที่ดีมีการนำไปใช้อย่างสม่ำเสมอ
Greenstone Walker

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

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

15

ฉันแนะนำให้คุณอ่านMulti-Tenant Data Architectureเอกสารทางเทคนิคที่กล่าวถึงตัวเลือกที่คุณมีข้อดีข้อเสีย เพื่อสรุปมันมีสามตัวเลือก:

  • แยกฐานข้อมูล
  • สคีแยกต่างหาก
  • สคีมาที่ใช้ร่วมกัน

ตอนนี้คุณอยู่ในระยะ DB ที่แยกจากกันซึ่งให้การแยกที่ดีที่สุด (แยกระหว่างผู้เช่า) แต่เป็นการจัดการที่ยากที่สุด ในขณะที่คุณเติบโตเป็นผู้เช่าหลายร้อยคนคุณจะรู้ว่าโลจิสติกส์ในการจัดการ 100s ของ DB อยู่ไกลจากเรื่องเล็กน้อย Think backup-restore (ตำแหน่งของไฟล์ที่สำรองข้อมูลงานตารางเวลา ฯลฯ ) คิดว่าคุณจะตรวจสอบและจัดการการจัดสรรไฟล์พื้นที่ดิสก์ที่ใช้และการเติบโตของฐานข้อมูลในฐานข้อมูลนับร้อย คิดว่าอะไรคือสถานการณ์จำลองความพร้อมใช้งานสูง / ความสามารถในการกู้คืนความเสียหายในอนาคตอันใกล้กับผู้เช่า 1,000 ราย 1,000 มิร์เรอร์ DBs, 1000 เซสชันการจัดส่งบันทึก? ลองคิดดูสิถ้าหากใน 6 เดือนทีมนักพัฒนาของคุณมาหาคุณและพูดว่า "ฉันรู้ว่าจะให้ฟีเจอร์ที่ยอดเยี่ยมนี้กับผลิตภัณฑ์ของเราได้อย่างไรเราจะใช้ Transactional Replication!" คุณจะพูดอย่างไร "แน่นอนให้ฉันตั้งค่าผู้เผยแพร่ 500 คน"เป็นไปไม่ได้ในการจัดการหลายร้อยดีบีเอส แต่ถ้าคุณวางแผนที่จะคุณดีกว่าขัดขึ้นของคุณPowerShellทักษะและหยุดการใช้เครื่องมือในการจัดการการ UI ในขณะนี้

นอกจากนี้คุณต้องพิจารณาว่าฐานข้อมูลหลายร้อย (DB) มีผลกระทบที่วัดได้ต่อประสิทธิภาพและต้นทุน:

  • ฟิสิคัลพื้นที่ว่างดิสก์ถูกใช้อย่างมีประสิทธิภาพน้อยกว่า (ฐานข้อมูลทุกห้องต้องมีห้องว่างบางห้องคุณจะมีห้องว่างคูณด้วยจำนวน DB)
  • ไม่มีวิธีที่คุณสามารถสร้างล็อกดิสก์สำหรับอุทิศงานเขียนได้คุณจะต้องย้าย LDF ทั้งหมดเหล่านั้นไปยังที่เก็บ SSD หนึ่ง (หรือมากกว่า)
  • บันทึกการเขียนจะมีประสิทธิภาพน้อยลงในการกระทำที่พบบ่อยในขณะที่พวกเขากระจายไปทั่วบันทึกการบล็อกแต่ละรายการเมื่อเทียบกับการรวมเป็นหนึ่ง (คุณจะได้รับการบันทึกบล็อก underused) ดูLSN คืออะไร: หมายเลขลำดับการบันทึกเพื่อทำความเข้าใจสิ่งที่ฉันกำลังพูดถึง

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

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


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

และเมื่อระบบอัตโนมัติของคุณได้รับการพัฒนาอย่างดีพอที่จะรองรับฐานข้อมูลแยกกันสำหรับไคลเอนต์แต่ละรายมันไม่ใช่การก้าวกระโดดครั้งใหญ่จากจุดนั้นไปสู่การจัดเตรียม VMs แยกสำหรับแต่ละไคลเอนต์ นี่คือสิ่งที่ บริษัท โฮสติ้ง "เมฆ" ทำ ยอมรับว่านี่อาจเป็นกรณีการใช้งานที่ดีสำหรับ SQL Azure
Gavin Campbell เมื่อ

2

ที่งานก่อนหน้าของฉันเราไม่ได้โฮสต์เพียงหนึ่งฐานข้อมูลต่อลูกค้า - ในกรณีส่วนใหญ่มันมากกว่านั้น! เมื่อฉันจากไปมีฐานข้อมูลมากกว่า 4,500 ฐานที่ทำงานในคลัสเตอร์ MariaDB หนึ่งคลัสเตอร์เกือบ 7,000 แห่งในคลัสเตอร์อื่น (เล็กกว่าแดกดัน) และ 4 "เศษ" (แยกจากกันอย่างสมบูรณ์เว็บอิสระและเซิร์ฟเวอร์ฐานข้อมูลแม้ในศูนย์ข้อมูลแยกต่างหาก) 200-500 ฐานข้อมูลในเซิร์ฟเวอร์ MySQL เครื่องเดียว และ บริษัท นั้นยังคงเติบโตในคลิปที่ดี

ความยาวและระยะสั้นคือความสำเร็จของ บริษัท นั้นพิสูจน์ได้ว่าสถาปัตยกรรมดังกล่าวเป็นไปได้แน่นอน (Caveat: ตรงกันข้ามกับการเพิ่มขึ้นอย่างชัดเจนในการแยกโดยใช้ฐานข้อมูลแยกต่างหากข้อมูลทั้งหมดถูกเข้าถึงผ่านแอพพลิเคชั่นที่เชื่อมต่อกันอย่างแน่นหนาทั้งสามที่ใช้ผู้ใช้ฐานข้อมูลเดียวกัน / ผ่าน! ฉันสงสัยว่าประสิทธิภาพอาจได้รับ มีผู้ใช้ / Pass แยกต่างหาก - แต่เพียงเล็กน้อยเท่านั้น)

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

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

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