Nhiều cơ sở dữ liệu hoặc nhiều nhiều bảng?

Question

Tôi đã thực hiện một số nghiên cứu về câu hỏi này (cả thông qua google và ở đây), nhưng không tìm thấy bất cứ điều gì tôi cảm thấy phù hợp với tình hình của tôi để yêu cầu.

Tôi có một dự án hiện có một tài khoản - một mô hình môi trường và đang tìm cách mở rộng sang một tài khoản - nhiều môi trường. Các môi trường sẽ giống nhau (ít nhất là theo cấu trúc bảng có liên quan) và sẽ yêu cầu khoảng 100 bảng. Tôi đang phân vân giữa hai cách tiếp cận có thể:

1. Sử dụng một cơ sở dữ liệu duy nhất, với bảng tiền tố để tách từng môi trường và một bảng tài khoản không tiền tố
2. Sử dụng nhiều cơ sở dữ liệu - một cơ sở dữ liệu tài khoản trung tâm, và một riêng biệt cho mỗi môi trường (trung tâm có thể sẽ có dữ liệu trung tâm, chỉ một lần khác, chẳng hạn như các bảng cho phần mềm diễn đàn của chúng tôi)

Có bất kỳ lợi ích/mối quan tâm nào về hiệu suất đáng kể không? Dữ liệu sẽ (ít nhất là bây giờ) tất cả nằm trên cùng một máy chủ vật lý. Truy vấn chỉ cần truy cập vào một môi trường duy nhất (ngoại trừ trong các trường hợp rất hiếm) - và tất nhiên là bản ghi tài khoản chính.

Answer 1

Câu hỏi thú vị. Là một câu trả lời tiêu chuẩn, tôi khuyên bạn nên để một cá thể chạy tất cả các tài khoản. I E. giải pháp tiền tố. Đây là cách tiếp cận được sử dụng bởi tất cả các nhà cung cấp hosting.

Có vẻ như có ý nghĩa khi có một RDBMS chạy chương trình. Sao lưu dễ dàng hơn và các tác vụ trên toàn hệ thống khác. Tôi sẽ đề nghị rằng về hiệu suất của một thể hiện đang chạy sẽ hiệu quả hơn nhiều so với việc chạy một quy trình riêng biệt cho mỗi tài khoản.

Nếu bạn cần bật cân bằng tải mô hình 'tiền tố' cũng sẽ dễ dàng hơn khi quy mô vì hầu hết các RDBMS hiện đại đều có phần bổ trợ/tính năng để hỗ trợ loại chức năng này, thay vì phải thiết lập nhiều lần cho mỗi trường hợp mỗi tài khoản.

Hệ thống cơ sở dữ liệu hiện đại có thể dễ dàng xử lý hàng nghìn yêu cầu mỗi giây, chúng sẽ không bị mất hiệu suất bằng cách tra cứu các tên bảng được tùy chỉnh (có tiền tố). Miễn là bạn có thể tìm ra cách phân cấp đơn giản (tiền tố tài khoản) cách tách tài khoản, bạn không nên gặp sự cố khi chạy hàng nghìn bảng.

Nhược điểm tiềm năng duy nhất là bảo mật. Và trong hầu hết các trường hợp, thậm chí có nhiều máy chủ sẽ không khắc phục được sự cố bảo mật của bạn.

Answer 2

Tôi sẽ nói sử dụng nhiều cơ sở dữ liệu để cho phép sửa đổi trong tương lai của các môi trường khác nhau. Bạn nghi ngờ rằng bạn đang nói về dữ liệu tĩnh mà tất cả trang web sẽ sử dụng, mỗi trang web đều phải có bộ dữ liệu riêng ...

Nếu không có lý do khác, (như tôi đã nói trước) để cho phép sửa đổi.

Answer 3

Tôi nghĩ sẽ đơn giản hơn nếu chỉ quản lý một cơ sở dữ liệu. Điều này sẽ làm cho việc phát triển và cấu hình trở nên dễ dàng hơn nhiều so với việc có nhiều cơ sở dữ liệu phải lo lắng về việc cấu hình đúng.

Về hiệu suất, bạn có thể cho phép DBMS xử lý các công cụ phân cụm/phân phối, vì vậy bạn sẽ không phải lo lắng về điều đó. Việc chia nhỏ dữ liệu cho chính bạn sẽ không làm mọi việc nhanh hơn thường xuyên, vì DBMS có thể (thường) làm một công việc tốt hơn nhiều ở đó, sau đó bạn có thể.

Answer 4

Chúng tôi có nhiều thứ cơ sở dữ liệu tại nơi làm việc - và các nhà cung cấp cơ sở dữ liệu khác nhau (DB2, Oracle, MySQL). HUGE PITA, mặc dù một số nỗi đau đó có thể đến từ thực tế là mỗi cơ sở dữ liệu được sở hữu bởi một nhóm khác . Nhưng nếu bạn cần tham gia dữ liệu (bạn nghĩ rằng hoàn cảnh hiếm có NGAY BÂY GIỜ, nhưng bạn chờ ...) trong cơ sở dữ liệu (trái ngược với ứng dụng), bạn sẽ hối tiếc về giải pháp đa máy chủ.

Answer 5

Dự án tôi hiện đang làm việc tương tự về mặt đó; một tài khoản cho nhiều trang web.

Giải pháp mà tôi đã thực hiện là xác thực được ủy quyền, một dịch vụ chỉ giao dịch với xác thực và đưa ra các xác nhận có thể xác minh về danh tính. Điều này có thể được kết hợp với ủy quyền là tốt. Để có ý tưởng về những gì được yêu cầu, bạn có thể xem dự án OpenID và OAuth2 để được cấp phép.

Thiết lập dịch vụ này không dễ dàng (mặc dù trang web OpenID có hướng dẫn thiết lập cho nó), nhưng nó cung cấp sự linh hoạt để di chuyển môi trường của bạn ra các địa điểm thực khác nhau mà không phải thay đổi mã của bạn. Trong thực tế, bạn có thể thậm chí giữ một cơ sở dữ liệu đơn lẻ và có thể di chuyển một môi trường sang một máy chuyên dụng khi nó tăng thêm lực kéo so với các máy khác.