มีการ จำกัด จำนวนฐานข้อมูลที่คุณสามารถวางบนเซิร์ฟเวอร์ SQL เครื่องเดียวหรือไม่?

ฉันกำลังตั้งค่าระบบ SaaS ที่เราวางแผนที่จะให้ฐานข้อมูลลูกค้าของพวกเขาแต่ละคน ระบบได้รับการตั้งค่าไว้แล้วเพื่อให้เราสามารถขยายไปยังเซิร์ฟเวอร์เพิ่มเติมได้อย่างง่ายดายหากโหลดมากเกินไป เราหวังว่าจะมีลูกค้าเป็นพันหรือเป็นหมื่น

คำถาม

• มีข้อ จำกัด ในทางปฏิบัติเกี่ยวกับจำนวนฐานข้อมูลขนาดเล็กที่คุณสามารถ / ควรมีใน SQL Server เดียวหรือไม่?
• มันมีผลต่อประสิทธิภาพของเซิร์ฟเวอร์หรือไม่
• มันจะดีกว่าหรือถ้ามี 10,000 ฐานข้อมูลละ 100 MB หรือหนึ่งฐานข้อมูล 1 TB

ข้อมูลเพิ่มเติม

เมื่อฉันพูดว่า "ฐานข้อมูลไมโคร" ฉันไม่ได้หมายถึง "ไมโคร" ฉันแค่หมายถึงว่าเรากำลังตั้งเป้าให้ลูกค้าหลายพันรายดังนั้นแต่ละฐานข้อมูลจะเป็นหนึ่งในพันหรือน้อยกว่าของพื้นที่จัดเก็บข้อมูลทั้งหมด ในความเป็นจริงแต่ละฐานข้อมูลจะอยู่ที่ประมาณ 100MB โดยขึ้นอยู่กับจำนวนการใช้งานที่ได้รับ

เหตุผลหลักในการใช้ 10,000 ฐานข้อมูลเพื่อความยืดหยุ่น ความจริงก็คือ V1 ของระบบมีฐานข้อมูลเดียวและเรามีช่วงเวลาที่อึดอัดเมื่อฐานข้อมูลกำลังถูกบีบให้โหลด

มันกำลังทำให้เครียด CPU, หน่วยความจำ, I / O - ทั้งหมดข้างต้น แม้ว่าเราจะแก้ไขปัญหาเหล่านั้นพวกเขาก็ทำให้เราตระหนักว่าในบางจุดแม้จะมีการจัดทำดัชนีที่ดีที่สุดในโลกหากเราประสบความสำเร็จอย่างที่เราหวังว่าจะเป็นเราก็ไม่สามารถใส่ข้อมูลทั้งหมดของเราได้ ฐานข้อมูล ดังนั้นสำหรับ V2 เรากำลังแบ่งส่วนดังนั้นเราจึงสามารถแยกโหลดระหว่างเซิร์ฟเวอร์ DB หลายตัวได้

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

เราได้ลองใช้Azure SQL Database Elastic Poolsแล้ว ประสิทธิภาพค่อนข้างน่าผิดหวังดังนั้นเราจึงเปลี่ยนกลับไปใช้ VM ปกติ

ฉันทำงานกับเซิร์ฟเวอร์ SQL ด้วยฐานข้อมูล 8-10,000 รายการในอินสแตนซ์เดียว มันไม่สวย

การรีสตาร์ทเซิร์ฟเวอร์อาจใช้เวลานานถึงหนึ่งชั่วโมงหรือนานกว่านั้น คิดเกี่ยวกับกระบวนการกู้คืนฐานข้อมูล 10,000

คุณไม่สามารถใช้ Studio จัดการเซิร์ฟเวอร์ SQL เพื่อค้นหาฐานข้อมูลใน Object Explorer ได้อย่างน่าเชื่อถือ

การสำรองข้อมูลเป็นฝันร้ายเนื่องจากการสำรองข้อมูลจะคุ้มค่าคุณต้องมีโซลูชันการกู้คืนความเสียหายที่ใช้งานได้ หวังว่าทีมงานของคุณเป็นที่ดีในการเขียนสคริปต์ทุกอย่าง

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

การจัดสรรหน่วยความจำสำหรับฐานข้อมูลหลาย ๆ แห่งนั้นสามารถระทมทุกข์ได้ SQL Server สิ้นสุดลงด้วยการทำ I / O จำนวนมากซึ่งสามารถดึงประสิทธิภาพได้อย่างแท้จริง พิจารณาระบบที่บันทึกรายละเอียดการใช้คาร์บอนใน 4 ตารางสำหรับ บริษัท 10,000 แห่ง หากคุณทำเช่นนั้นในฐานข้อมูลเดียวคุณจะต้อง 4 ตารางเท่านั้น หากคุณทำเช่นนั้นใน 10,000 ฐานข้อมูลคุณต้องมีหน่วยความจำ 40,000 ตารางในทันที ค่าใช้จ่ายในการจัดการกับจำนวนของตารางในหน่วยความจำนั้นเป็นเรื่องสำคัญ แบบสอบถามใด ๆ ที่คุณออกแบบซึ่งจะวิ่งกับตารางเหล่านั้นจะต้องใช้แผนอย่างน้อย 10,000 แผนในแคชแผนหากมีฐานข้อมูล 10,000 ฐานที่ใช้อยู่

รายการด้านบนเป็นเพียงตัวอย่างเล็ก ๆ ของปัญหาที่คุณต้องวางแผนเมื่อใช้งานกับเครื่องชั่งชนิดนั้น

คุณอาจพบปัญหาหลายอย่างเช่นบริการ SQL Server ซึ่งใช้เวลานานในการเริ่มต้นซึ่งอาจทำให้เกิดข้อผิดพลาดของ Service Controller คุณสามารถเพิ่มเวลาเริ่มต้นบริการด้วยตัวเองสร้างรายการรีจิสทรีต่อไปนี้:

คีย์ย่อย: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control
ชื่อ: ServicesPipeTimeout
ประเภท: REG_DWORD
ข้อมูล: จำนวนมิลลิวินาทีก่อนที่การหมดเวลาจะเกิดขึ้นระหว่างการเริ่มบริการ

ตัวอย่างเช่นหากต้องการรอ 600 วินาที (10 นาที) ก่อนที่บริการจะหมดให้พิมพ์ 600000

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

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

กรณีของฉันสำหรับเหตุผลที่คุณควรใช้ 1 ฐานข้อมูลสำหรับลูกค้าทั้งหมด

ข้อดี

• บำรุงรักษาง่าย การมีหนึ่งฐานข้อมูลหมายความว่าคุณต้องทำงานบำรุงรักษาในที่เดียวแทนที่จะเป็นหลาย ๆ ลองนึกภาพฝันร้ายของการจัดการฐานข้อมูล 1,000 ฐานเพื่อสำรองข้อมูล วิธีการเกี่ยวกับการปรับปรุงสถิติ 1000 DB หรือดัชนีการสร้างหรือDBCC CHECKDB?

• การปรับใช้รหัส สมมติว่าคุณมีปัญหากับขั้นตอนการจัดเก็บในรหัสแอปพลิเคชันหรือการรายงานของคุณ คุณต้องทำการเปลี่ยนแปลงอย่างรวดเร็ว ... ตอนนี้คุณต้องปรับใช้การเปลี่ยนแปลงนั้นกับ 1,000+ ฐานข้อมูล ไม่ขอบคุณฉันไม่อยากทำ

• ทัศนวิสัยที่ง่าย เพียงภาพ SSMS พยายามที่จะเปิด 1000 + ของ DB (สั่น) มันจะทำให้ปัญหาไร้ประโยชน์และใช้เวลาในการเปิดและทำให้ SSMS น่าประหลาดใจ โปรดจำไว้ว่าหากคุณสามารถกำหนดแผนการตั้งชื่อที่เหมาะสมได้

จุดด้อย

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

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

ในที่สุดฉันคิดว่าทางออกที่ดีที่สุดของคุณคือมีหนึ่งฐานข้อมูลสำหรับคุณและแยกข้อมูลลูกค้าออกจากฐานข้อมูล ปัญหาที่จะทำให้คุณไม่มีอะไรเทียบกับฝันร้ายในการจัดการฐานข้อมูลกว่า 1,000 รายการ

ข้อมูลจำเพาะความจุสูงสุดสำหรับ SQL Serverระบุว่ามีขีด จำกัด 32,767

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

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

สิ่งที่คุณกำลังพูดถึงที่นี่คือสถาปัตยกรรมแบบผู้เช่าหลายรายเทียบกับหลายอินสแตนซ์ ฉันแค่นำคำศัพท์เหล่านี้มาใช้เพราะคุณไม่ได้ใช้มันในคำถามของคุณ แต่นี่คือสิ่งที่คุณกำลังพูดคุยกันเรียกว่าและถ้าคุณเพียงแค่เสียบ "สถาปัตยกรรมผู้เช่าหลายคน" เข้ากับ Google คุณจะพบทรัพยากรและการสนทนามากมาย เกี่ยวกับมันหนังสือทั้งหมดได้รับการเขียนเกี่ยวกับมัน

ทรัพยากรที่ดีเกี่ยวกับ SQL Server โดยเฉพาะที่นี่:

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

ฉันจะมีคำตอบอื่น ๆ ในการที่ฉันจะยันขอต่อหลายลูกเป็นค่าเริ่มต้นถ้าคุณมีเหตุผลที่น่าสนใจที่จะสนับสนุนหลายเช่น

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

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

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

ข้อเสียอย่างหนึ่งที่ฉันเห็นได้จากข้อเสนอแนะฐานข้อมูลเดียวคือการย้อนกลับข้อมูล - ถ้าคุณมีฐานข้อมูลต่อการตั้งค่าผู้เช่าคุณสามารถกู้คืนข้อมูลของลูกค้าแต่ละรายได้อย่างอิสระ หากทั้งหมดอยู่ในฐานข้อมูลเดียวสิ่งนี้จะกลายเป็นเรื่องยากมากขึ้น (และมีแนวโน้มที่จะเกิดข้อผิดพลาดมากขึ้นเนื่องจากอาจต้องทำผ่านคำสั่ง INSERT / UPDATE / DELETE)

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

แรงจูงใจในการแยกส่วน

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

ตอบข้อกังวล

• การรีสตาร์ทเซิร์ฟเวอร์ใช้เวลานาน:ตกลง แต่ในการทำงานปกติเราไม่ต้องการรีสตาร์ทเซิร์ฟเวอร์ใด ๆ ในที่สุดระบบจะต้องออนไลน์ตลอด 24 ชั่วโมงดังนั้นหากเรากำลังจะหยุดทำงานระบบจะต้องกำหนดเวลาอยู่ดี
• การสำรองข้อมูล / การกู้คืนความเสียหาย:เรากำลังใช้ CloudBerry ซึ่งดำเนินการทุกอย่างโดยอัตโนมัติ ไม่ใช่ปัญหา.
• การตั้งชื่อฐานข้อมูล / การค้นหาใน SSMS:หลักการตั้งชื่อนั้นง่ายเพียงแค่ยึดตามชื่อลูกค้า เพิ่มเลขซีเรียลถ้ามีการแชร์ชื่อ
• การบำรุงรักษา:ถ้าแต่ละฐานข้อมูลมีขนาดเล็กเท่าที่ฉันจินตนาการไม่จำเป็นต้องสร้างดัชนีใหม่ด้วยตนเอง
• การปรับใช้รหัส:เราใช้ Entity Framework ดังนั้นการเปลี่ยนแปลงสคีมาทั้งหมดจะถูกนำไปใช้กับฐานข้อมูลแต่ละอันโดยอัตโนมัติด้วยรีลีสใหม่ แม้ว่าจะเป็นเรื่องจริงก็ตามหากเราค้นพบปัญหาด้านประสิทธิภาพในการผลิตซึ่งสามารถแก้ไขได้ด้วยการปรับแต่งดัชนีอย่างง่ายมันไม่ง่ายเลยที่จะผลักมันออกไปที่นั่น ในทางกลับกันเมื่อฐานข้อมูลแต่ละตัวมีขนาดเล็กมากจึงไม่น่าที่จะมีปัญหาประสิทธิภาพการแสดงบนชิ้นส่วนการผลิต และฐานข้อมูลทั่วไปยังคงเป็นฐานข้อมูลเดียวซึ่งไม่มีข้อกังวลเหล่านี้

ฉันยินดีที่จะตอบกลับจากคุณในความคิดเห็นหากคุณคิดว่าฉันไม่มีอะไร!