คำถามติดแท็ก multi-tenant

ฉันกำลังสร้างแอพหลายผู้เช่า (ฐานข้อมูลเดียวสกีมาเดียว) โดยใช้ ASP Web API, Entity Framework และฐานข้อมูล SQL Server / Azure แอปนี้จะใช้งานโดยลูกค้า 1,000-5,000 คน ตารางทั้งหมดจะมีฟิลด์TenantId(Guid / UNIQUEIDENTIFIER) ตอนนี้ฉันใช้คีย์หลักของฟิลด์เดียวซึ่งเป็นรหัส (Guid) แต่ด้วยการใช้เพียงแค่รหัสเขตข้อมูลฉันต้องตรวจสอบว่าข้อมูลที่ให้โดยผู้ใช้นั้นมาจาก / สำหรับผู้เช่าที่เหมาะสมหรือไม่ ตัวอย่างเช่นฉันมีSalesOrderตารางที่มีCustomerIdเขตข้อมูล ทุกครั้งที่ผู้ใช้โพสต์ / อัปเดตคำสั่งขายฉันต้องตรวจสอบว่าCustomerIdมาจากผู้เช่ารายเดียวกันหรือไม่ แย่ลงเพราะผู้เช่าแต่ละรายอาจมีหลายสาขา แล้วฉันจะมีการตรวจสอบและTenantId OutletIdมันเป็นฝันร้ายของการบำรุงรักษาและไม่ดีต่อประสิทธิภาพ ฉันคิดว่าจะเพิ่มไปยังคีย์หลักพร้อมกับTenantId Idและอาจเพิ่มOutletIdด้วย ดังนั้นหลักสำคัญในSalesOrderตารางจะเป็น: Id, และTenantId OutletIdข้อเสียของวิธีการนี้คืออะไร? ประสิทธิภาพจะเจ็บอย่างรุนแรงโดยใช้คีย์ผสมหรือไม่ คีย์ใบสั่งผสมมีความสำคัญหรือไม่ มีวิธีแก้ปัญหาที่ดีกว่าสำหรับฉันหรือไม่?

16 sql-server  index  multi-tenant  design-pattern  physical-design 

รับกรณีการใช้งาน: ข้อมูลผู้เช่าไม่ควรพูดคุยข้าม, ผู้เช่ารายหนึ่งไม่ต้องการข้อมูลของผู้เช่ารายอื่น ผู้เช่าแต่ละรายอาจมีปริมาณข้อมูลประวัติขนาดใหญ่ได้ SQL Server โฮสต์อยู่ในอินสแตนซ์ของ AWS EC2 ผู้เช่าแต่ละรายอยู่ห่างจากพื้นที่ทางภูมิศาสตร์ มีความตั้งใจที่จะใช้เครื่องมือสร้างภาพข้อมูลบุคคลที่สามเช่น PowerBI Embedded คาดว่าปริมาณข้อมูลจะเพิ่มขึ้นเมื่อเวลาผ่านไป ค่าใช้จ่ายของระบบถูก จำกัด การแก้ปัญหาจะต้องสามารถบำรุงรักษาได้โดยไม่ต้องมี DBA ผลิต 24/7 การแก้ปัญหาควรจะสามารถปรับขนาดในแนวนอน จำนวนผู้เช่าทั้งหมดน้อยกว่า 50 สิ่งที่จะเป็นสถาปัตยกรรมที่แนะนำมีการใช้งานอ้างอิงสำหรับกรณีการใช้งานนี้หรือไม่? ฉันเชื่อว่าหลายคนอาจประสบปัญหานี้แล้วสำหรับการพัฒนาซอฟต์แวร์ระดับองค์กร ผมคิดว่านี่เป็นสถานการณ์ที่แตกต่างจากการจัดการตัวเลขการเติบโตของผู้เช่าในหลายลูกสถาปัตยกรรมฐานข้อมูล กรณีการใช้ที่กล่าวถึงในคำถามนั้นเกี่ยวข้องกับผู้เช่าจำนวนมากซึ่งแตกต่างจากการมีผู้เช่ารายใหญ่น้อยมาก (50) คน สถาปัตยกรรมที่กล่าวถึงอาจเป็นวิธีแก้ปัญหาที่นี่ซึ่งเป็นสิ่งที่ฉันต้องการทราบเพิ่มเติมเกี่ยวกับ

12 sql-server  database-design  sharding  scalability  multi-tenant