Ưu / nhược điểm của việc sử dụng nhiều cơ sở dữ liệu so với sử dụng một cơ sở dữ liệu

Tôi đang làm việc trên một dự án mới có yêu cầu sử dụng 7 cơ sở dữ liệu, lập luận rằng hiệu suất, tính ổn định, tối ưu hóa được thực hiện dễ dàng hơn.

Mặc dù tôi không đồng ý, tôi gặp khó khăn khi thu thập các đối số tốt để sử dụng một cơ sở dữ liệu duy nhất (chia các bảng thành các miền logic).

Một đối số tôi có cho đến nay là tính toàn vẹn dữ liệu (Tôi không thể sử dụng khóa ngoại giữa các cơ sở dữ liệu).

Những ưu / nhược điểm tốt khi sử dụng một hoặc nhiều cơ sở dữ liệu là gì?

[tóm tắt cho đến nay]

Đối số chống lại nhiều cơ sở dữ liệu:

• Mất tính toàn vẹn dữ liệu (không thể sử dụng khóa ngoại trên cơ sở dữ liệu)

• Mất khôi phục tính toàn vẹn

• Đạt được độ phức tạp (người dùng db / vai trò)

• Máy chủ / cơ sở dữ liệu tỷ lệ cược nhỏ sẽ đi xuống

Các giải pháp:

• Sử dụng lược đồ để phân tách các miền.

• POC: Sử dụng dữ liệu giả để chứng minh điểm trong kế hoạch thực hiện 7/1 db

Không có hiệu suất, sự ổn định, tối ưu hóa là đúng. Có ai có một lập luận vững chắc hoặc bài viết tham khảo tại sao những điều này sẽ là đúng?

Tài nguyên không được phân bổ cho cơ sở dữ liệu: Trường hợp SQL Server cân bằng tài nguyên để nó tạo ra không có sự khác biệt

Bạn đã thua:

• toàn vẹn dữ liệu
• khôi phục tính toàn vẹn (dữ liệu trong DB7 sẽ muộn hơn DB1)

Bạn đạt được sự phức tạp:

• bảo mật (người dùng, vai trò, v.v.) phải có trong tất cả các cơ sở dữ liệu
• bạn sẽ có một số dữ liệu không phù hợp với 1 cơ sở dữ liệu

Tùy chọn:

• việc tách cơ sở dữ liệu thành các đĩa riêng biệt có thể được thực hiện với các nhóm
• sử dụng lược đồ để phân tách dữ liệu một cách hợp lý (dựa trên câu trả lời khác)

Những lý do chính đáng để tạo cơ sở dữ liệu riêng biệt sẽ là để hỗ trợ các yêu cầu sẵn có khác nhau hoặc đơn giản hóa việc quản trị. Ví dụ: nếu cơ sở dữ liệu của bạn yêu cầu lịch sao lưu rất khác nhau hoặc các mô hình khôi phục khác nhau. Một lý do khác là nếu bạn có thể muốn chạy chúng trong các trường hợp khác nhau.

Không có tối ưu hóa hiệu suất có sẵn với nhiều cơ sở dữ liệu mà bạn cũng không thể đạt được với một cơ sở dữ liệu. Bạn có thể cung cấp thêm chi tiết về những gì bạn có nghĩa là "hiệu suất, ổn định, tối ưu hóa"?

Nếu bạn sau khi chia dữ liệu theo miền logic, bạn luôn có thể xem xét sử dụng các lược đồ trong SQL2008 (đi từ mặc định của dbo.) Nhưng thậm chí điều đó gây đau đớn và có thể gây ra sự cố với OR / Ms mà không mong đợi lược đồ tiêu chuẩn.

Tôi đã ở vị trí đối chiếu dữ liệu từ nhiều hơn một cơ sở dữ liệu và điều đó thật đau đớn và khác xa với hiệu suất cao. Bạn kết thúc bộ nhớ cache dữ liệu hoặc ít nhất là sử dụng các thủ thuật để duy trì tốc độ.

Như một thử nghiệm, xây dựng 7 cơ sở dữ liệu giả. Xây dựng một truy vấn yêu cầu dữ liệu đồng thời từ tất cả 7 hoặc ít nhất là một số lượng tốt.

Sau đó so sánh các kế hoạch thực hiện! Tôi nghĩ bạn sẽ thắng vụ kiện của bạn ngay tại đó.

Thử nghiệm suy nghĩ: Thay vì chia cơ sở dữ liệu của bạn thành bảy mảnh, thay vào đó hãy chia nó thành 7.000 mảnh. Khả năng một lỗi phần cứng sẽ ảnh hưởng đến ứng dụng của bạn là gì? Nếu có 0,1% khả năng bất kỳ máy chủ cụ thể nào có thể chết vào một ngày cụ thể, thì khả năng của bạn sẽ tốt hơn hay tệ hơn là bạn sẽ bị ảnh hưởng bởi lỗi phần cứng khi tăng số lượng máy bạn phụ thuộc?

Tôi nghĩ điều quan trọng là chia khái niệm "cơ sở dữ liệu" thành hai phần: lược đồ và dữ liệu so với phần cứng được sử dụng để phục vụ dữ liệu.

Phá vỡ cơ sở dữ liệu trên nhiều máy không tốt cho nhiều lý do được giải thích bởi các câu trả lời khác trong chủ đề này.

Nếu bạn sẽ sử dụng nhiều máy để tăng độ tin cậy và hiệu suất, có lẽ bạn có thể cấu trúc chúng để bạn có một máy chủ chính có nhiều máy dự phòng nóng / nóng cũng có thể được sử dụng để phân phối truy vấn. Bằng cách này, nếu bất kỳ một máy nào gặp sự cố, bạn sẽ không mất dữ liệu và tệ nhất là bạn sẽ phải khởi động lại một truy vấn. Tất nhiên, nó phức tạp hơn thế này, nhưng những điều cơ bản được áp dụng.

Tôi đồng tình với một DB và sử dụng các tùy chọn tệp và lược đồ thay thế.

Có trường hợp cạnh mà chia thành nhiều phần có ý nghĩa.

Cấu hình môi trường ứng dụng (dev, test, prod), chẳng hạn như máy chủ FTP, xuất đường dẫn tệp, v.v ..., Thứ bạn muốn lưu trữ trên mỗi máy chủ và không bị ghi đè khi khôi phục.

Cũng như một cách để cô lập các thay đổi thủ tục cụ thể của khách hàng.

Nhưng đây là những vấn đề hỗ trợ và không hiệu suất.