Multi-tenancy - ฐานข้อมูลเดียวเทียบกับหลายฐานข้อมูล


20

เรามีลูกค้าจำนวนมากที่มีระบบแบ่งปันฟังก์ชั่นบางอย่าง แต่ก็มีความหลากหลายในระดับหนึ่ง จำนวนลูกค้ากำลังเติบโต - เป็นสิ่งที่ดีต่อสุขภาพเสมอ! - และความหลากหลายระหว่างธุรกิจของพวกเขาก็เพิ่มขึ้นเช่นกัน

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

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

ความกังวลหลักภายในธุรกิจมีมากกว่า:

  • การบำรุงรักษาสินทรัพย์หลายรายการ - การสำรองข้อมูลการควบคุมเวอร์ชันและสิ่งที่คล้ายกัน
  • ส่งเสริมการใช้ซ้ำให้มากที่สุด

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


มีโอกาสหรือไม่ที่จะย้ายไปยังสภาพแวดล้อมคลาวด์ PaaS เช่น Azure ถ้าเป็นเช่นนั้นคุณจะต้องพิจารณาแนวทางปฏิบัติที่ดีที่สุดสำหรับสภาพแวดล้อมเช่นกัน ครั้งล่าสุดที่ฉันดู MS แนะนำให้ใช้หลายฐานข้อมูลสำหรับซอฟต์แวร์หลายรายการใน Azure
Harper Shelby

ขอบคุณที่ถาม. ฉันสงสัยในสิ่งที่คล้ายกัน แต่ไม่สามารถจัดรูปแบบคำถามได้อย่างคล่องแคล่วเหมือนคุณ
MathAttack

คุณควรอ่านซีรี่ส์บล็อกที่มีหลายผู้เช่าของ Ayende เขาทำคะแนนได้ดีมากเกี่ยวกับฐานข้อมูลหลายตัวและฐานข้อมูลเดียว
Sebazzz

คำตอบ:


12

นี่คือไฮไลท์จากการวิจัยจากแหล่งอื่น ๆ (มาจากการแก้ไข 2 ของคำถาม ):


10

หากคุณใช้ SQL Server ให้ใช้ฐานข้อมูลเดียว แต่ใช้สกีมา ใช้ dbo สำหรับสิ่งต่าง ๆ ที่ใช้กับไคลเอนต์ทั้งหมดและสร้างสคีมาสำหรับแต่ละไคลเอนต์และสร้างสคีมาเริ่มต้นสำหรับผู้ใช้จากไคลเอนต์นั้น ตอนนี้คุณสามารถมีวัตถุทั่วไป (เช่น getBudget proc) ใน dbo schema และวัตถุที่กำหนดเองสำหรับลูกค้าใน schema ของพวกเขาด้วยชื่อเดียวกัน


+1 สิ่งนี้จะช่วยให้คุณหลีกเลี่ยงการกำหนดค่า MSDTC และรับภาระค่าใช้จ่ายที่เกี่ยวข้อง (สองขั้นตอน)
brian

และหวังว่าคุณจะหลีกเลี่ยงกับดักของการมีคอลัมน์เช่น CustomField1 ถึง CustomField30 และ / หรือมีตารางเช่น Budget, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName ฯลฯ
jfrankcarr

มีเลเยอร์การเข้าถึงข้อมูลที่มีอยู่ซึ่งใช้กระบวนงานที่เก็บไว้จำนวนมาก - 190 ตารางขั้นตอนที่สร้างรหัส 5 ต่อตารางรวมถึงบางส่วนที่กำหนดเอง - ในขณะที่เป้าหมายระยะกลางคือการแนะนำ Entity Framework จะต้องทำซ้ำการจัดเก็บ ขั้นตอนสำหรับแต่ละ schema หรือไม่
RichardW1001

@ RichardW1001: ขึ้นอยู่กับ คุณสามารถทำ SQL แบบไดนามิกใน sp เพื่อทำให้เป็นแบบทั่วไป แต่แน่นอนว่าขึ้นอยู่กับพวกเขาที่มีโครงสร้างคล้ายกันเป็นอย่างน้อย ทางเลือกที่เป็นไปได้สำหรับไดนามิก sql น่าจะเป็นคำพ้องขออภัยที่ฉันเข้าใจพวกเขาพวกเขาทั้งระบบและไม่ได้อยู่ในการทำธุรกรรมดังนั้นจึงไม่เหมาะสำหรับการใช้งานพร้อมกันด้วยค่าที่แตกต่างกัน
jmoreno

หากเราใช้ schema หลาย ๆ ตัวโดยใช้ EF Code First จะสามารถโยกย้าย schemas ทั้งหมดไปเป็นเวอร์ชั่นล่าสุดได้หรือไม่หลังจากที่ระบบใช้งานจริง
Yashvit

4

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

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


ข้อเสนอแนะของคุณจะเป็นอย่างไรเกี่ยวกับวิธีการจัดการฟังก์ชั่นทั่วไปด้วยความเจ็บปวดน้อยที่สุด?
RichardW1001

1
ในระบบควบคุมเวอร์ชันของคุณรักษาหัวสำหรับแอปพลิเคชันหลักและสร้างสาขาหลักสำหรับลูกค้าแต่ละรายพร้อมด้วยสาขาย่อยสำหรับคุณลักษณะใหม่ที่พวกเขาต้องการรักษา พัฒนาคุณลักษณะเฉพาะของลูกค้าในสาขาพร้อมตัวเลือกในการอัปเดตลำตัว ฯลฯ คุณสามารถเพิ่มสภาพแวดล้อมเฉพาะของลูกค้าได้อย่างง่ายดายทุกครั้งที่ต้องการ
Stephen Senkomago Musoke

3

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

ดังนั้นอย่าลืมว่ามันมีราคาถูกกว่าหลายเท่าและง่ายกว่าในการขยายฐานข้อมูลที่แตกต่างกันน้อยกว่าฐานข้อมูลขนาดใหญ่)


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

1

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

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