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

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

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

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

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

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

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

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

• การจัดการจำนวนผู้เช่าที่เพิ่มขึ้นในสถาปัตยกรรมฐานข้อมูลผู้เช่าหลายคน

• ฐานข้อมูลหลายผู้เช่าใช้ SQL Server 2008

• ระบบอัตโนมัติของการสำรองข้อมูลของฐานข้อมูลจำนวนมาก

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

ฉันแนะนำให้คุณอ่าน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 เติบโตไปถึงหลายแสน / หลายพันฐานข้อมูลเป็นต้น

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

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

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

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