Có giới hạn nào về số lượng cơ sở dữ liệu bạn có thể đặt trên một máy chủ SQL không?

Tôi đang thiết lập một hệ thống SaaS, nơi chúng tôi dự định cung cấp cho mỗi khách hàng cơ sở dữ liệu của riêng họ. Hệ thống đã được thiết lập để chúng tôi có thể dễ dàng mở rộng ra các máy chủ bổ sung nếu tải quá lớn; chúng tôi hy vọng sẽ có hàng ngàn, thậm chí hàng chục ngàn khách hàng.

Câu hỏi

• Có giới hạn thực tế nào về số lượng cơ sở dữ liệu vi mô bạn có thể / nên có trên một Máy chủ SQL không?
• Nó có thể ảnh hưởng đến hiệu suất của máy chủ?
• Có tốt hơn khi có 10.000 cơ sở dữ liệu mỗi 100 MB, hoặc một cơ sở dữ liệu 1 TB?

Thông tin thêm

Khi tôi nói "cơ sở dữ liệu vi mô", tôi không thực sự có nghĩa là "vi mô"; Tôi chỉ có nghĩa là chúng tôi đang nhắm đến hàng ngàn khách hàng, vì vậy mỗi cơ sở dữ liệu riêng lẻ sẽ chỉ bằng một phần nghìn hoặc ít hơn tổng lưu trữ dữ liệu. Trong thực tế, mỗi cơ sở dữ liệu sẽ ở khoảng 100 MB, tùy thuộc vào mức độ sử dụng.

Lý do chính để sử dụng 10.000 cơ sở dữ liệu là cho khả năng mở rộng. Thực tế là, V1 của hệ thống có một cơ sở dữ liệu và chúng tôi đã có một số khoảnh khắc không thoải mái khi DB bị căng dưới tải.

Đó là làm căng CPU, bộ nhớ, I / O - tất cả những thứ trên. Mặc dù chúng tôi đã khắc phục những vấn đề đó, nhưng chúng khiến chúng tôi nhận ra rằng đến một lúc nào đó, ngay cả với việc lập chỉ mục tốt nhất trên thế giới, nếu chúng tôi thành công như chúng tôi hy vọng, chúng tôi chỉ đơn giản là không thể đưa tất cả dữ liệu của mình vào một honkin lớn 'cơ sở dữ liệu. Vì vậy, đối với V2, chúng tôi sẽ ngăn chặn, vì vậy chúng tôi có thể phân chia tải giữa nhiều máy chủ DB.

Tôi đã dành năm ngoái để phát triển giải pháp phân chia này. Đó là một giấy phép cho mỗi máy chủ, nhưng dù sao thì điều đó cũng được quan tâm vì chúng tôi đang sử dụng máy ảo trên Azure. Lý do câu hỏi được đưa ra là bởi vì trước đây chúng tôi chỉ cung cấp cho các tổ chức lớn và tự thiết lập mỗi tổ chức. Đơn hàng kinh doanh tiếp theo của chúng tôi là mô hình tự phục vụ trong đó bất kỳ ai có trình duyệt đều có thể đăng ký và tạo cơ sở dữ liệu của riêng họ. Cơ sở dữ liệu của họ sẽ nhỏ hơn và nhiều hơn nhiều so với các tổ chức lớn.

Chúng tôi đã thử Azure SQL cơ sở dữ liệu đàn hồi . Hiệu suất rất đáng thất vọng, vì vậy chúng tôi đã chuyển trở lại máy ảo thông thường.

Tôi đã làm việc trên Máy chủ SQL với 8 đến 10 nghìn cơ sở dữ liệu trên một ví dụ. Nó không đẹp.

Khởi động lại máy chủ có thể mất một giờ hoặc hơn. Hãy suy nghĩ về quá trình phục hồi cho 10.000 cơ sở dữ liệu.

Bạn không thể sử dụng SQL Server Management Studio để xác định vị trí cơ sở dữ liệu trong Object Explorer.

Sao lưu là một cơn ác mộng, vì để sao lưu có giá trị, bạn cần phải có một giải pháp khắc phục thảm họa khả thi. Hy vọng rằng nhóm của bạn là tuyệt vời trong kịch bản mọi thứ .

Bạn bắt đầu làm những việc như đặt tên cơ sở dữ liệu với các số, như M01022và T9945. Cố gắng đảm bảo rằng bạn đang làm việc trong cơ sở dữ liệu chính xác, ví dụ M001022thay vì M01022, có thể gây điên loạn.

Phân bổ bộ nhớ cho nhiều cơ sở dữ liệu có thể gây khó chịu; SQL Server kết thúc với rất nhiều I / O, đây có thể là một lực cản thực sự đối với hiệu suất. Hãy xem xét một hệ thống ghi lại chi tiết sử dụng carbon trên 4 bảng cho 10.000 công ty. Nếu bạn làm điều đó trong một cơ sở dữ liệu, bạn chỉ cần 4 bảng; nếu bạn làm điều đó trong 10.000 cơ sở dữ liệu, đột nhiên bạn cần 40.000 bảng trong bộ nhớ. Chi phí xử lý số lượng bảng trong bộ nhớ là đáng kể. Bất kỳ truy vấn nào bạn thiết kế sẽ được chạy với các bảng đó sẽ yêu cầu ít nhất 10.000 gói trong bộ đệm của gói nếu có 10.000 cơ sở dữ liệu đang sử dụng.

Danh sách trên chỉ là một ví dụ nhỏ về các vấn đề bạn cần lập kế hoạch khi vận hành ở quy mô đó.

Có thể bạn sẽ gặp phải những thứ như Dịch vụ SQL Server mất nhiều thời gian để khởi động, điều này có thể gây ra lỗi Trình điều khiển dịch vụ. Bạn có thể tự tăng thời gian khởi động dịch vụ, tạo mục đăng ký sau:

Khóa con: HKEY_LOCAL_MACHINE \ HỆ THỐNG \ CurrentControlset \ Control
Tên: ServicesPipeTimeout
Loại: REG_DWORD
Dữ liệu: Số mili giây trước khi hết thời gian trong khi khởi động dịch vụ

Ví dụ: để đợi 600 giây (10 phút) trước khi hết dịch vụ, hãy nhập 600000.

Kể từ khi viết câu trả lời, tôi nhận ra câu hỏi đang nói về Azure. Có lẽ làm điều này trên Cơ sở dữ liệu SQL không phải là vấn đề; có lẽ nó có vấn đề hơn Cá nhân, tôi có thể thiết kế một hệ thống bằng một cơ sở dữ liệu duy nhất, có thể được phân chia theo chiều dọc trên nhiều máy chủ, nhưng chắc chắn không phải là một cơ sở dữ liệu cho mỗi khách hàng.

Vì vậy, có những ưu và nhược điểm cho cả hai phương pháp. Nếu không biết thêm về ứng dụng của bạn hoặc các dịch vụ mà bạn đang tìm cách cung cấp, tôi sẽ không thể đưa ra câu trả lời dứt khoát nhưng tôi sẽ loại bỏ một số suy nghĩ của mình về vấn đề này.

Trường hợp của tôi về lý do tại sao bạn nên sử dụng 1 Cơ sở dữ liệu cho tất cả các khách hàng.

Ưu

• Bảo trì dễ dàng. Có một DB nghĩa là bạn chỉ phải thực hiện nhiệm vụ bảo trì của mình trên một địa điểm thay vì nhiều địa điểm. Hãy tưởng tượng cơn ác mộng xử lý 1000 cơ sở dữ liệu khác nhau để sao lưu. Làm thế nào về việc cập nhật số liệu thống kê trên 1000 DB hoặc xây dựng lại các chỉ mục hoặc DBCC CHECKDB?

• Mã triển khai. Giả sử bạn gặp sự cố với quy trình được lưu trữ trong mã ứng dụng hoặc báo cáo. Bạn cần thực hiện một thay đổi nhanh chóng ... Bây giờ bạn phải triển khai thay đổi đó lên hơn 1000 DB. Không, cảm ơn, tôi không muốn.

• Tầm nhìn dễ dàng. Chỉ cần hình ảnh SSMS đang cố mở 1000+ DB (rùng mình) . Nó thực tế sẽ làm cho vấn đề trở nên vô dụng và mất một lượng thời gian đáng ngạc nhiên để chỉ mở và kết xuất SSMS. Hãy ghi nhớ, đó là nếu bạn có thể đưa ra một quy ước đặt tên đàng hoàng.

Nhược điểm

• Bảo vệ. Sẽ dễ dàng hơn để ngăn mọi người nhìn vào dữ liệu của khách hàng khác nếu bạn có họ dưới dạng DB riêng biệt. Tuy nhiên, có một số điều rất đơn giản bạn có thể làm để ngăn chặn điều này xảy ra.

• Hiệu suất. Có thể lập luận rằng việc giới hạn nó một DB cho mỗi khách hàng có nghĩa là máy chủ SQL sẽ phải quét qua ít dữ liệu hơn để có được thông tin bạn đang truy vấn. Tuy nhiên với cấu trúc dữ liệu phù hợp và lập chỉ mục tốt (và phân vùng có thể), bạn có thể loại bỏ vấn đề này thành một vấn đề nếu được thực hiện cẩn thận. Tôi sẽ khuyên bạn nên cung cấp cho mỗi bảng có chứa dữ liệu cụ thể của khách hàng một số loại dẫn CompanyIDđến giảm chi phí đó.

Cuối cùng tôi nghĩ rằng đặt cược tốt nhất của bạn là có một DB cho ứng dụng của bạn và chỉ cần tách dữ liệu khách hàng bên trong chính DB. Những rắc rối nó sẽ mang lại cho bạn sẽ không là gì so với cơn ác mộng của việc quản lý hơn 1000 cơ sở dữ liệu.

Thông số kỹ thuật tối đa cho SQL Server nói rằng có giới hạn 32.767.

Về việc nó có ảnh hưởng đến hiệu suất hay không, câu trả lời là có, nhưng những cách nó sẽ ảnh hưởng đến hiệu suất, và liệu nó có đáng kể hay không, sẽ phụ thuộc vào vô số yếu tố.

Tôi sẽ đi với một cơ sở dữ liệu trừ khi có lý do chính đáng để tách nó ra thành 10.000 cơ sở dữ liệu. Một bản sao lưu hoặc 10.000 bản sao lưu? Một kiểm tra tính toàn vẹn, hoặc 10.000? Có thể có một lý do chính đáng để sử dụng 10.000 DB nhỏ, nhưng bạn chưa cung cấp đủ chi tiết để xác định điều đó. Câu hỏi bạn đã hỏi khá rộng và đơn giản là không có đủ thông tin cho bất cứ ai biết câu trả lời tốt nhất là gì.

Những gì bạn đang nói ở đây là kiến trúc nhiều người thuê và kiến trúc đa trường . Tôi chỉ đưa ra những điều khoản này khi bạn không sử dụng chúng trong câu hỏi của bạn nhưng đây là những gì bạn đang thảo luận được gọi và nếu bạn chỉ cắm "kiến trúc nhiều người thuê" vào Google, bạn sẽ tìm thấy vô số tài nguyên và thảo luận về nó, toàn bộ cuốn sách đã được viết trên đó.

Một số tài nguyên tốt về SQL Server cụ thể ở đây:

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

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

Tôi sẽ có câu trả lời khác, trong đó tôi sẽ nghiêng mạnh về phía đa người thuê nhà như một mặc định, trừ khi bạn có lý do thuyết phục để ủng hộ đa ví dụ.

Bạn không cần phải chia thành hàng ngàn cơ sở dữ liệu khách hàng cá nhân để mở rộng quy mô, có nhiều cách khác để làm điều đó, có khả năng sẽ được ưa thích hơn. Giống như phân cụm, nhân rộng, shending, phân vùng, vv Đừng phát minh lại bánh xe. Không có gì cố hữu nói rằng bạn cần phải tự chia nhỏ thủ công này ở cấp độ khách hàng cá nhân và thực sự làm như vậy có khả năng làm tăng đáng kể chi phí thêm mỗi khách hàng mới.

Bạn đang nói về "hàng triệu" khách hàng, nghĩ về bất kỳ phần mềm dựa trên đám mây quy mô lớn nào như một dịch vụ, Gmail, bất cứ điều gì, bạn khó nghĩ rằng họ tạo ra một cơ sở dữ liệu hoàn toàn mới cho mỗi lần đăng ký mới, phải không?

Có thể có những lý do mà bạn muốn tạo điều kiện thuận lợi cho việc này, ví dụ, nếu bạn đang bán sản phẩm của mình cho một khách hàng PHẢI lưu trữ nội bộ trên cơ sở hạ tầng của riêng họ. Nhưng như một quy tắc SAAS chung, hãy nghiêng về mặc định cho kiến ​​trúc nhiều bên thuê.

Một trong những nhược điểm tôi có thể thấy đối với đề xuất cơ sở dữ liệu duy nhất là thực hiện với việc khôi phục dữ liệu - nếu bạn có cơ sở dữ liệu cho mỗi người thuê thiết lập, bạn có thể khôi phục dữ liệu của từng khách hàng một cách độc lập (và đến một thời điểm cụ thể). Nếu tất cả chúng đều nằm trong một cơ sở dữ liệu, việc này sẽ trở nên khó khăn hơn nhiều (và dễ bị lỗi hơn vì có thể cần phải thực hiện thông qua các câu lệnh INSERT / UPDATE / DELETE).

Cảm ơn tất cả những người đã trả lời - thực sự đánh giá cao những điểm bạn đã cho tôi suy nghĩ. Cảm giác chung mà tôi nhận được là một cơ sở dữ liệu duy nhất là tốt hơn, nhưng tôi muốn thêm một số điểm đối nghịch có lợi cho kiến ​​trúc bị phân mảnh và giải quyết một số mối quan tâm mà người khác đã đề cập.

Động lực cho shending

Như đã đề cập trong câu hỏi (cập nhật), chúng tôi đang hướng tới doanh số lớn trên toàn thế giới, với hàng triệu người dùng theo nghĩa đen. Với phần cứng và lập chỉ mục tốt nhất trên thế giới, một máy chủ DB sẽ không tải, vì vậy chúng tôi phải có thể phân phối trên nhiều máy chủ. Và một khi bạn phải tìm kiếm máy chủ nào có dữ liệu của khách hàng, thì việc cung cấp cho họ một cơ sở dữ liệu chuyên dụng sẽ giúp mọi việc đơn giản hơn trong việc giữ dữ liệu của mọi người được tách biệt gọn gàng.

Trả lời các mối quan tâm

• Khởi động lại máy chủ mất nhiều thời gian: OK, nhưng trong hoạt động bình thường, chúng tôi không có ý định khởi động lại bất kỳ máy chủ nào. Cuối cùng, hệ thống phải trực tuyến 24/7, vì vậy nếu chúng ta sắp có thời gian chết thì nó sẽ phải được lên lịch.
• Sao lưu / phục hồi thảm họa: Chúng tôi đang sử dụng Cloud tweet, tự động hóa mọi thứ. Không thành vấn đề.
• Đặt tên cơ sở dữ liệu / định vị chúng trong SSMS: Quy ước đặt tên rất dễ dàng, chỉ dựa trên tên của khách hàng. Thêm chữ số nối tiếp nếu tên được chia sẻ.
• Bảo trì: Nếu mỗi cơ sở dữ liệu nhỏ như tôi hình dung, không cần phải xây dựng lại các chỉ mục theo cách thủ công.
• Mã triển khai: Chúng tôi sử dụng Entity Framework, vì vậy mọi thay đổi lược đồ sẽ tự động được triển khai cho từng cơ sở dữ liệu với các bản phát hành mới. Tuy nhiên, sự thật là nếu chúng ta phát hiện ra một vấn đề về hiệu suất trong sản xuất có thể được khắc phục bằng một điều chỉnh chỉ số đơn giản, thì không dễ để đẩy nó ra khỏi đó. Mặt khác, với mỗi cơ sở dữ liệu quá nhỏ, không chắc sẽ có vấn đề về hiệu suất showstopper trên các phân đoạn sản xuất. Và cơ sở dữ liệu chung vẫn là một DB duy nhất mà những mối quan tâm này không áp dụng.

Tôi sẽ rất vui khi được nghe lại từ bạn trong các bình luận nếu bạn nghĩ rằng tôi đang thiếu bất cứ điều gì!