Xin lưu ý: Tôi đang trả lời từ góc độ Máy chủ SQL, vì vậy tôi đề cập đến một số khái niệm dành riêng cho SQL Server, nhưng tôi tin rằng tất cả các khái niệm này đều có tương đương trong các nền tảng RDBMS chính khác, với những lợi ích và hạn chế tương tự.
Tôi cũng có thể sẽ tiếp tục chỉnh sửa câu trả lời này khi tôi nghĩ về những ưu / nhược điểm tiềm năng khác.
Vâng, nó thực sự phụ thuộc vào lược đồ, khối lượng, vv Chính xác thì một cửa hàng lưu trữ là gì? Làm thế nào khác với việc lưu trữ dữ liệu khoảng 50.000 con mèo hoặc 50.000 sản phẩm hoặc 50.000 hạt dẻ?
Có một số lý do (không chỉ riêng về khía cạnh kích thước) tại sao bạn không muốn lưu trữ dữ liệu cho 50.000 khách hàng khác nhau trong một cơ sở dữ liệu, nếu thực sự dữ liệu có thể được tách biệt hoàn toàn bởi khách hàng (không bao gồm các bảng tra cứu như mã zip hoặc các bảng dành riêng cho ứng dụng, có thể đi vào một cơ sở dữ liệu trung tâm duy nhất):
nếu một khách hàng vượt xa ứng dụng, không có cách nào dễ dàng trích xuất dữ liệu của họ và chuyển nó sang một thể hiện khác, máy chủ, v.v., trừ khi bạn lên kế hoạch trước và phân vùng trên một cái gì đó như CustomerIDvà có 50.000 filegroup (bạn bị giới hạn dù sao cũng có tới 15.000 phân vùng hoặc 1.000 nếu bạn sử dụng phiên bản SQL Server cũ hơn và việc có quá nhiều nhóm fileg có thể là thảm họa ). Cũng lưu ý rằng phân vùng yêu cầu Phiên bản doanh nghiệp.
nếu nó chỉ ra rằng tất cả các khách hàng của bạn chỉ đơn giản là quá lớn trong trường hợp này, nhân rộng ra có nghĩa là có được phần cứng mới và di chuyển toàn bộ cơ sở dữ liệu ở đó (và có khả năng làm điều đó một lần nữa).
xóa một khách hàng có thể gây đau đớn không kém, vì bạn sẽ phải xóa một số% hàng khỏi các bảng rất lớn và điều đó sẽ không rẻ.
bạn có thể sẽ phân phối rộng rãi dữ liệu khách hàng (một khách hàng với một tỷ hàng, một khách hàng khác với 5.000). Điều này có thể dẫn đến những thứ như đánh hơi thông số và hiệu suất bất lợi liên quan đến tính chính xác và chất lượng kế hoạch (vì bạn có thể sẽ sử dụng lại cùng một gói cho cùng một truy vấn đối với các tập dữ liệu rất khác nhau).
tất cả khách hàng của bạn phải tuân theo các gói SLA và HA / DR chính xác giống nhau. Bạn có toàn bộ cơ sở dữ liệu ở chế độ khôi phục hoàn toàn với các bản sao lưu nhật ký trong một phút hoặc bạn đơn giản và dựa vào các bản sao lưu đầy đủ + diff. Nếu bạn phải hoàn nguyên vì lỗi của khách hàng hoặc cần khôi phục cơ sở dữ liệu đến một thời điểm, điều đó ảnh hưởng đến từng khách hàng.
có khả năng xảy ra lỗi khi truy xuất dữ liệu - ví dụ, các lỗi trong đó các mệnh đề có thể dẫn đến một khách hàng nhìn thấy dữ liệu của khách hàng khác hoặc tất cả dữ liệu của các khách hàng khác.
có thể có ý nghĩa pháp lý (một số công ty sẽ có những yêu cầu khắt khe rằng bạn không đặt dữ liệu của họ vào cùng một cơ sở dữ liệu như bất kỳ công ty nào khác, và đặc biệt là đối thủ cạnh tranh của họ).
nếu bảo mật dữ liệu của một khách hàng là quan trọng, thì việc đạt được việc sử dụng phân tách cơ sở dữ liệu sẽ dễ dàng hơn nhiều so với phân tách trong bảng.
Một số lợi thế để có mỗi khách hàng trong một cơ sở dữ liệu riêng biệt (hoặc ít nhất là có nhiều cơ sở dữ liệu, mỗi cơ sở cho một nhóm khách hàng):
- về kích thước, nó sẽ có cùng kích thước trên đĩa.
- nhân rộng ra dễ dàng hơn, vì bạn chỉ có thể di chuyển một cơ sở dữ liệu (hoặc nhiều) đến một máy chủ khác.
- xóa một khách hàng và tất cả dữ liệu của nó gần tương đương với
DROP DATABASE.
- bạn đang sử dụng nhiều bộ nhớ hơn cho các gói (hoặc bạn có ít bộ nhớ cache hơn cho mỗi khách hàng), nhưng ít nhất các gói đó có liên quan đến dữ liệu trong cơ sở dữ liệu tương ứng của họ và ít bị các vấn đề đánh hơi thông số / thống kê.
- bạn có thể dễ dàng có các gói SLA và DR khác nhau, đặt một số cơ sở dữ liệu đầy đủ và các cơ sở dữ liệu khác một cách đơn giản. Đồng thời hoàn nguyên hoặc khôi phục đến một thời điểm chỉ ảnh hưởng đến khách hàng đó.
- bạn có thể dễ dàng đặt các cơ sở dữ liệu khác nhau (giả sử, khách hàng ưu tiên cao của bạn) vào I / O nhanh hơn. Bạn có thể làm điều này trong một cơ sở dữ liệu duy nhất với các nhóm fileg, nhưng điều đó khó hơn nhiều để quản lý (ít nhất là IMHO).
Một số nhược điểm:
- bỏ qua một bên, có lẽ bạn sẽ không muốn có 50.000 cơ sở dữ liệu trên một phiên bản SQL Server duy nhất, vì vậy điều này có thể có nghĩa là nhân rộng ra nhiều máy chủ.
- thời gian khởi động tăng lên vì có một số chi phí cố hữu khi khởi động mỗi cơ sở dữ liệu.
- ứng dụng phải thông minh hơn một chút - thay vì chỉ có CustomerID ở mệnh đề where, nó phải tự động kết nối với cơ sở dữ liệu của CustomerID. Điều này không khó với tầng trung lưu thích hợp nhưng nó là một sự thay đổi.
- vâng, bạn có nhiều bản sao của cùng một bảng và quy trình, nhưng mã và lược đồ giống hệt nhau trên các cơ sở dữ liệu, chỉ là dữ liệu là khác nhau. Vì vậy, việc triển khai thay đổi mã / lược đồ bây giờ chỉ là một vòng lặp thay vì thực thi đơn lẻ.
- bảo trì hơi khác một chút khi bạn đang quản lý 50.000 cơ sở dữ liệu - một lần nữa kích thước tổng thể gần như nhau nhưng quy trình phải thay đổi - bạn không thể chỉ phân mảnh / reindex / sao lưu tất cả 50.000 cơ sở dữ liệu cùng một lúc. Phải nói rằng, ở công việc trước đây của tôi, tôi đã quản lý các trường hợp có 500-1.000 cơ sở dữ liệu giống hệt nhau và sự khác biệt giữa việc quản lý 3 cơ sở dữ liệu giống hệt nhau và 750 cơ sở dữ liệu giống hệt nhau chỉ đơn giản là thời gian cần thiết.