Tại thời điểm nào một cơ sở dữ liệu trên mỗi khách hàng trở nên không khả thi?

31

Đối với một trong các hệ thống của chúng tôi, chúng tôi có dữ liệu khách hàng nhạy cảm và lưu trữ dữ liệu của từng khách hàng trong một cơ sở dữ liệu riêng biệt. Chúng tôi có khoảng 10-15 khách hàng cho hệ thống đó.

Tuy nhiên, chúng tôi đang phát triển một hệ thống mới sẽ có 50-100 khách hàng, có thể nhiều hơn nữa. Tôi nghĩ rằng có thể không có cơ sở dữ liệu cho mỗi khách hàng trong trường hợp này (để lưu trữ hồ sơ nhạy cảm và lịch sử kiểm toán). Tuy nhiên tôi không biết điều này có hoàn toàn bình thường hay không, hoặc nếu có một cách khác để duy trì an ninh.

Bất kỳ suy nghĩ về điều này?

database-design sql-server-2012

— NibblyPig
nguồn

Tôi không biết những ưu điểm của việc có nhiều cơ sở dữ liệu trên mỗi máy chủ (tôi chưa bao giờ gặp vấn đề gì với điều đó) nhưng nhiều khái niệm lược đồ technet.microsoft.com/en-us/l Library / dd207005.aspx trong cùng một cơ sở dữ liệu, cung cấp cả hai cách ly và bảo mật. Vì vậy, bạn có thể thử kiến trúc này là tốt.

— Alexandros

2

Phân tách lược đồ @Alexandros cung cấp một chút, nhưng nó không cho phép bạn sử dụng các mô hình khôi phục riêng biệt, sao lưu các lịch trình khác nhau, khôi phục một khách hàng đến một thời điểm cụ thể, dễ dàng xóa một khách hàng, dễ dàng di chuyển một khách hàng, v.v.

— Aaron Bertrand

4

Tôi đã thấy các hệ thống có hơn 3.000 cơ sở dữ liệu (1 trên mỗi máy khách) trên một máy chủ. Tôi sẽ không lo lắng quá nhiều - chỉ cần đảm bảo rằng bạn lập kế hoạch tài nguyên cẩn thận và theo dõi việc sử dụng khi số lượng khách hàng tăng lên.

— Max Vernon

Bạn có thể đọc nó, đặc biệt lưu ý ngày và các bình luận của ops: stackoverflow.com/questions/5596755/

— mẹo

48

Quản lý 100 hoặc 500 cơ sở dữ liệu thực sự không khác mấy so với quản lý 5 hoặc 10 - bạn chỉ cần nắm lấy tự động hóa và có kế hoạch mở rộng (và không có kế hoạch sử dụng các tính năng cơ sở dữ liệu chi phí cao như phản chiếu trên tất cả khách hàng).

Ở công việc trước đây của chúng tôi, chúng tôi đã sử dụng kiến trúc này và tôi chưa bao giờ nghĩ sẽ hợp nhất hai khách hàng vào một cơ sở dữ liệu, mặc dù một số thách thức có thể "khó khăn".

Những lợi ích lớn là các mô hình phục hồi độc lập ( acó thể đơn giản, bcó thể đầy đủ, v.v.), khả năng khôi phục đến một thời điểm (hoặc loại bỏ hoàn toàn) một khách hàng mà không làm gián đoạn các khách hàng khác, khả năng di chuyển liền mạch một máy khách nặng tài nguyên vào bộ lưu trữ của riêng nó hoặc đến một máy chủ hoàn toàn khác với rất ít cách thức minh bạch (bạn cập nhật tệp hoặc bảng cấu hình cho ứng dụng biết nơi tìm ứng dụng khách đó).

Tôi giải quyết một số phản đối và / hoặc cách tiếp cận vấn đề, trong các bài đăng này:

Như đã nói, tôi không nghĩ bất kỳ ai trong chúng ta có thể nói cho bạn biết thời điểm mà việc quản lý trở nên không thực tế đối với bạn - chỉ cần biết rằng bất kỳ thử thách cụ thể nào bạn gặp phải, bạn có thể hỏi về những vấn đề đó một cách riêng lẻ.

— Aaron Bertrand
nguồn

6

Bạn cũng sẽ cần một quy ước đặt tên tốt, được áp dụng nhất quán.

— Greenstone Walker

Cảm ơn đó là một số liên kết tuyệt vời. Đây thực sự không phải là một vấn đề quản lý (hiện tại), tôi chỉ lo lắng mọi thứ có thể bị đình trệ. Nhưng có vẻ như tôi không nên lo lắng về điều đó và chỉ cần đảm bảo rằng tôi có thể quản lý tất cả. Xin cảm ơn!

— NibblyPig

@Aaron tôi có kịch bản tương tự trong OMS nơi tôi có nhiều hội thảo xử lý một đơn đặt hàng và chúng độc lập. Hội thảo được lựa chọn dựa trên địa chỉ đặt hàng (Khách hàng). Vì vậy, một khách hàng có thể có đơn đặt hàng trong nhiều workshpose. Vì vậy, thật khó khăn khi cần tải lịch sử đặt hàng của khách hàng khi cần phải đi trên mỗi máy chủ cơ sở dữ liệu.

— Navrattan Yadav

15

Tôi khuyên bạn nên đọc Multi-Tenant Kiến trúc dữ liệu , một màu trắng giấy mà thảo luận về các tùy chọn mà bạn có, và những ưu và khuyết điểm. Tóm lại, nó cung cấp ba tùy chọn:

DB riêng
lược đồ riêng
lược đồ dùng chung

Bây giờ bạn đang ở giai đoạn DB riêng biệt, cung cấp sự tách biệt tốt nhất (cách ly giữa những người thuê nhà), nhưng khó quản lý nhất. Khi bạn phát triển thành hàng trăm người thuê, bạn sẽ nhận ra rằng hậu cần của việc quản lý 100 DB là không quan trọng. Hãy suy nghĩ sao lưu-khôi phục (vị trí của các tập tin sao lưu, công việc, lịch trình, vv). Hãy suy nghĩ làm thế nào bạn sẽ giám sát và quản lý phân bổ tệp, dung lượng ổ đĩa được sử dụng và tăng trưởng cơ sở dữ liệu trên hàng trăm DB. Hãy nghĩ điều gì sẽ là kịch bản Khả năng phục hồi / Thảm họa-Khả năng phục hồi cao của bạn trong tương lai gần với 1000 người thuê nhà? 1000 DB nhân đôi, 1000 phiên vận chuyển log? Hãy nghĩ xem nếu trong 6 tháng, nhóm phát triển của bạn đến gặp bạn và nói "Tôi biết cách cung cấp tính năng tuyệt vời này cho sản phẩm của chúng tôi, chúng tôi sẽ sử dụng Sao chép giao dịch!", Bạn sẽ nói gì? "chắc chắn, hãy để tôi thiết lập 500 nhà xuất bản,"! Không thể quản lý hàng trăm DB, nhưng nếu bạn có kế hoạch, tốt hơn hết bạn nên cải thiện các kỹ năng PowerShell của mình và ngừng sử dụng các công cụ quản lý UI ngay bây giờ .

Ngoài ra, bạn cần xem xét rằng nhiều (hàng trăm) DB có tác động có thể đo lường được đối với hiệu suất và chi phí:

không gian đĩa vật lý được sử dụng ít hiệu quả hơn (mỗi cơ sở dữ liệu phải có một số phòng dự phòng, bạn sẽ có phòng dự phòng đó nhân với số lượng DB)
Không có cách nào bạn có thể tạo đĩa nhật ký dành riêng để ghi các tác vụ chuyên sâu, bạn sẽ phải chuyển tất cả các LDF đó vào một (hoặc nhiều) bộ lưu trữ SSD
ghi nhật ký sẽ kém hiệu quả hơn đối với các cam kết thường xuyên khi chúng trải rộng trên nhiều bản ghi khối nhật ký riêng lẻ so với tổng hợp thành một (bạn sẽ nhận được các khối nhật ký được sử dụng). Xem LSN: Số thứ tự đăng nhập để hiểu những gì tôi đang nói.

Các DB tách biệt đi kèm với một số lợi thế mặc dù do cách ly, ưu điểm chính là sao lưu / khôi phục độc lập.

Kịch bản như của bạn mặc dù là một ứng cử viên hoàn hảo cho cơ sở dữ liệu SQL Azure . Không quản trị không gian đĩa, không cần cung cấp HA / DR, tăng lên hàng trăm / nghìn DB, v.v.

— Remus Rusanu
nguồn

Cảm ơn đây là một số lời khuyên tốt, đặc biệt có thể chuyển sang mô hình đám mây. Tôi sẽ phải suy nghĩ nghiêm túc về cách tôi sẽ xử lý việc sao lưu mọi thứ.

— NibblyPig

Và một khi tự động hóa của bạn được phát triển đủ tốt để hỗ trợ các cơ sở dữ liệu riêng biệt cho từng khách hàng, thì đó không phải là một bước nhảy vọt từ đó để cung cấp các VM riêng cho từng khách hàng. Rốt cuộc, đây là những gì các công ty lưu trữ "đám mây" làm. Đồng ý rằng đây có thể là trường hợp sử dụng tốt cho SQL Azure

— Gavin Campbell

2

Ở công việc trước đây của chúng tôi, chúng tôi đã lưu trữ không chỉ một cơ sở dữ liệu cho mỗi khách hàng - trong hầu hết các trường hợp, nó còn hơn thế nữa! Khi tôi rời đi, có hơn 4.500 cơ sở dữ liệu đang chạy trong một cụm MariaDB, gần 7.000 cơ sở trong một cụm khác (nhỏ hơn trớ trêu thay) và 4 "phân đoạn" (các máy chủ cơ sở dữ liệu và web hoàn toàn riêng biệt, ngay cả trong một trung tâm dữ liệu riêng biệt) 200-500 cơ sở dữ liệu trong một máy chủ MySQL. Và công ty đó vẫn đang phát triển ở một clip tốt.

Dài và ngắn là sự thành công của công ty đó chứng minh rằng một kiến trúc như vậy thực sự khả thi. (Hãy cẩn thận: Trái ngược với mức tăng rõ rệt khi sử dụng các cơ sở dữ liệu riêng biệt, tất cả dữ liệu được truy cập thông qua bộ ba ứng dụng được kết hợp chặt chẽ mà tất cả đều sử dụng cùng một người dùng / cơ sở dữ liệu! đã có một người dùng / pass riêng - nhưng chỉ một chút.)

Từ kinh nghiệm của tôi làm việc chặt chẽ với các quản trị viên hệ thống (về mặt kỹ thuật tôi là lập trình viên của công ty, nhưng thực tế tôi là DBA tốt nhất họ có, và là người duy nhất họ biết cách thiết lập tường lửa!), Liên quan đến hiệu suất mối quan tâm được rút ngắn để truy cập đồng thời, độ phức tạp / thời gian truy vấn, hiệu suất chỉ mục, v.v. - tất cả các nghi phạm thông thường, nói cách khác, và số lượng cơ sở dữ liệu trên máy chủ không có phần rõ ràng, một kết luận được khẳng định bởi chuyên gia được trả lương cao tư vấn chúng tôi tư vấn thường xuyên.

Điểm mấu chốt là bạn nên tập trung mối quan tâm của mình vào ứng dụng của bạn, vào cơ sở hạ tầng của bạn chứ không phải vào số lượng cơ sở dữ liệu bạn có. Tất cả những yếu tố khác sẽ là quá đủ để giữ cho bạn bận rộn giải quyết các vấn đề về hiệu suất và tắc nghẽn.

— Kromey
nguồn