2010-07-19 71 views
12

Tôi đang làm việc với một ứng dụng mà chúng tôi lưu trữ dữ liệu khách hàng của chúng tôi trong cơ sở dữ liệu SQL riêng biệt cho từng khách hàng. Cho đến nay điều này đã làm rất tốt, thậm chí có trường hợp một số mã sai đã chọn sai id khách hàng từ cơ sở dữ liệu và vì dữ liệu duy nhất trong cơ sở dữ liệu thuộc về máy khách đó, thiệt hại không tồi như nó có thể. Mối quan tâm của tôi là về số lượng cơ sở dữ liệu mà bạn thực tế có trên SQL Server.Có bao nhiêu cơ sở dữ liệu quá nhiều trên SQL Server?

Có thêm chi phí bổ sung nào cho mỗi cơ sở dữ liệu mới mà bạn tạo không? Chúng tôi cuối cùng đã đánh một bức tường nơi chúng tôi chỉ có nhiều cơ sở dữ liệu trên một máy chủ? Các thông số kỹ thuật của SQL Server nói rằng bạn có thể có thứ gì đó giống như 32000 cơ sở dữ liệu nhưng có thể, có ai có số lượng lớn cơ sở dữ liệu trên một máy chủ hay không và bạn đang gặp phải vấn đề gì.

Cảm ơn,

Frank

+0

tôi đang xem xét một thiết lập tương tự cho một ứng dụng tổ chức chúng tôi hiện đang phát triển, vì vậy bất kỳ những câu chuyện chiến tranh trong thế giới thực sẽ được chào đón nhiều nhất :) – elo80ka

+0

Cho đến nay ý tưởng đã hoạt động rất tốt nhưng nó đòi hỏi rất nhiều mã công cụ để hỗ trợ. Ví dụ: chúng tôi có ứng dụng quản trị để tạo trang web mới và công cụ nhập/xuất để di chuyển khách hàng từ máy chủ này sang máy chủ khác. Di chuyển đã được gỡ lỗi chủ yếu, nhưng trong tương lai chúng tôi dự định có hai máy chủ prod mà chúng tôi sẽ sử dụng để cân bằng tải. – Frank

+0

Hiệu ứng phụ tuyệt vời khác của cơ sở dữ liệu riêng biệt cho mỗi khách hàng là nó buộc bạn thiết kế một môi trường có thể đặt lại nơi bạn có thể nhanh chóng tạo ra một cá thể mới của ứng dụng của bạn và chạy các bài kiểm tra đơn vị/thủ công. – Frank

Trả lời

13

Các giới hạn trên là

  • không gian đĩa
  • nhớ
  • bảo trì

Ví dụ:

  • chỉ số Xây dựng lại cho 32k cơ sở dữ liệu? Khi nào?
  • Nếu 10% 32k cơ sở dữ liệu mỗi người đều có một bộ tích cực của dữ liệu 100MB bộ nhớ trong cùng một lúc, bạn đã ở 320GB bộ nhớ máy chủ mục tiêu
  • biết những gì DB bạn đã kết nối quá
  • ...

Giới hạn hiệu quả phụ thuộc vào tải, sử dụng, kích thước cơ sở dữ liệu, vv

Edit: Và băng thông như Wyatt Barnett nói .. tôi quên mất mạng, các nút cổ chai mọi người quên về ...

+2

Tôi chắc chắn có giới hạn thực sự đối với số lượng DB, nhưng như bạn nói, bạn sẽ đạt đến giới hạn tài nguyên thực tế sớm hơn nhiều. – CJM

+0

vì vậy đối với bộ nhớ, là có một cơ sở dữ liệu với 500 megs dữ liệu bất kỳ khác biệt với việc có 5 cơ sở dữ liệu với mỗi 100 megs dữ liệu? Là số lượng bộ nhớ một cấu trúc cơ sở dữ liệu đòi hỏi rất nhiều? – Frank

+0

@Frank: nếu tất cả được sử dụng cùng một lúc, không. Đó là dữ liệu trong cơ sở dữ liệu của bạn, không phải cấu trúc, chiếm không gian – gbn

2

ISP thường có một máy chủ cơ sở dữ liệu được chia sẻ bởi hàng trăm hoặc hàng ngàn cơ sở dữ liệu.

7

Vấn đề lớn nhất với tất cả các cơ sở dữ liệu là giữ cho chúng tất cả đồng bộ khi bạn thực hiện thay đổi lược đồ. Theo như số lượng thực tế của cơ sở dữ liệu bạn có thể có và có hệ thống hoạt động tốt, như thường lệ nó phụ thuộc. Nó phụ thuộc vào mức độ mạnh mẽ của máy chủ và cơ sở dữ liệu lớn đến mức nào. Có thể bạn sẽ muốn có nhiều máy chủ tại một số thời điểm không chỉ vì nó sẽ nhanh hơn cho khách hàng của bạn, nhưng bởi vì nó sẽ đặt ít khách hàng có nguy cơ tại một thời điểm nếu một cái gì đó xảy ra với máy chủ. Tại thời điểm đó, chỉ có công ty của bạn mới có thể quyết định. Chắc chắn nếu bạn bắt đầu nhận được rất nhiều thời gian-outs máy chủ khác có thể được chỉ định (hoặc sửa chữa các truy vấn nghèo của bạn cũng có thể làm điều đó). Khách hàng lớn thường sẽ trả phí bảo hiểm trên một máy chủ riêng biệt, vì vậy hãy cân nhắc điều đó trong giá của bạn. Chúng tôi đã có một khách hàng quá hoang tưởng về dữ liệu của họ, chúng tôi phải có một máy chủ riêng biệt thậm chí không được đặt cùng với các máy chủ khác. Họ trả tiền lớn cho điều đó vì chúng tôi phải thuê thêm không gian.

1

Điều bạn thực sự hỏi là Khả năng mở rộng; Mặc dù, lý tưởng thiết lập 32.000 cơ sở dữ liệu trên một máy chủ có lẽ không thuận lợi nhưng có thể (mặc dù không được khuyến nghị).

Đọc - http://www.sql-server-performance.com/articles/clustering/massive_scalability_p1.aspx

+0

Tôi đặt liên kết ở dưới cùng làm tham chiếu và không lưu. Tôi xin lỗi vì sự hiểu nhầm. –

2

Kiến trúc, đây là cuộc gọi phù hợp nói chung. Bạn đã thấy lợi thế khổng lồ đầu tiên - đôi khi, thiệt hại có thể bị giới hạn ở một khách hàng và bạn có nguy cơ gần như bằng không của khách hàng vào dữ liệu của khách hàng khác. Nhưng bạn đang thiếu một lợi thế lớn khác - bạn không phải giữ tất cả các máy khách trên cùng một máy chủ cơ sở dữ liệu. Khi bạn nhận được đủ lớn mà máy chủ của bạn là đau khổ, bạn có thể offload khách hàng vào một hộp hoàn toàn với nỗ lực tối thiểu.

Tôi cũng đặt cược bạn sẽ hết băng thông để quản lý cơ sở dữ liệu trước khi máy chủ của bạn hết hơi để xử lý nhiều cơ sở dữ liệu hơn. . .

1

Tôi biết đây là một chuỗi cũ nhưng đó là cấu trúc tương tự mà chúng tôi đã có trong 2 năm qua và hiện tại chạy 1768 cơ sở dữ liệu trên 3 máy chủ.

Chúng tôi đã thiết lập sau (không bao gồm gương và vân vân): Máy chủ trang trại

  • 2 web và 4 máy chủ nội dung
  • dụ
  • SQL chỉ cho một cơ sở dữ liệu tổng thể của khách hàng, mà được truy vấn khi họ truy cập trang web của họ bằng ID để lấy tên máy chủ/cá thể và tên cơ sở dữ liệu mà dữ liệu của họ cư trú. Điều này sau đó được lưu trữ trong vé xác thực.
  • 3 máy chủ SQL để lưu trữ cơ sở dữ liệu khách hàng trên cơ sở tổng số người học hiện tại trong tất cả các cơ sở dữ liệu trên mỗi máy chủ (được tính nhanh bằng trường số giấy phép trong cơ sở dữ liệu chính).
  • Trên mỗi máy chủ SQL, có một cơ sở dữ liệu chủ nhỏ hơn chứa dữ liệu tĩnh dùng chung cho tất cả các máy khách, do đó cho phép cơ sở dữ liệu khách hàng nhỏ hơn và cập nhật nội dung nhanh hơn.

Điều lớn nhất như đã đề cập ở trên là giữ cấu trúc cơ sở dữ liệu đồng bộ hóa! Đối với điều này, tôi đã lập trình một biểu mẫu .NET nhỏ để tra cứu tất cả các khách hàng trong cơ sở dữ liệu chủ và bạn dán mã vào để thực thi và nó sẽ lặp lại thông qua việc lấy vị trí cơ sở dữ liệu và thực thi SQL bạn đã qua.

Tạo khách hàng mới cũng gây ra một số vấn đề cho chúng tôi, vì vậy tôi đã lập một hệ thống quản lý cho nhân viên bán hàng của mình và tạo cơ sở dữ liệu mới dựa trên bản sao lưu của cơ sở dữ liệu "trống", do đó chúng tôi có DB mới nhất mà không cần phải tái kịch bản toàn bộ tập lệnh tạo cơ sở dữ liệu. Sau đó nó chèn các chi tiết khách hàng bên trong cơ sở dữ liệu chủ với vị trí nơi cơ sở dữ liệu được tạo và di chuyển bất kỳ dữ liệu cũ nào từ một phiên bản cũ của phần mềm của chúng tôi. Tất cả điều này được thực hiện trên một cá thể riêng biệt trước khi di chuyển, do đó giảm bất kỳ khóa SQL nào.

Chúng tôi hiện đang chuyển sang một cơ sở dữ liệu duy nhất cho phiên bản tiếp theo của phần mềm như dự phòng cơ sở dữ liệu gần như không thể với nhiều cơ sở dữ liệu! Đây là một điều rất quan trọng để xem xét khi SQL tạo ra một vài nhiệm vụ chờ đợi để phản chiếu dữ liệu của bạn trên cơ sở dữ liệu, một khi bạn bắt đầu nhân các cơ sở dữ liệu nó bị mất và hệ thống hầu như chỉ được giao nhiệm vụ đồng bộ hóa và có thể khóa. số của chủ đề. Xem trang 30 của Microsoft tài liệu dưới đây:

SQLCAT's Guide to High Availability Disaster Recovery.pdf

tuy nhiên tôi có nghi ngờ về việc chuyển sang một cơ sở dữ liệu duy nhất, do một số vấn đề như đã đề cập ở trên, chẳng hạn như liên tục kiểm tra trong mỗi quy trình đơn lẻ mà khách hàng hiện có truy cập vào chỉ dữ liệu của họ và cũng có những thứ dọc theo dòng của một vấn đề nhỏ bây giờ sẽ ảnh hưởng đến mọi cơ sở dữ liệu duy nhất, chẳng hạn như lập chỉ mục bảng và như vậy.Cũng tại phút, khách hàng của chúng tôi có khoảng cách trên 3 máy chủ, nhưng cơ sở dữ liệu duy nhất có nghĩa là chúng tôi có dự phòng, nhưng nếu lỗi nằm trong cơ sở dữ liệu thay vì máy chủ đi xuống, thì đó là tất cả khách hàng xuống, không chỉ 1 cơ sở dữ liệu khách hàng.

Tất cả trong tất cả, nó phụ thuộc vào những gì bạn đang làm và nếu bạn muốn dự phòng; đối với tôi, dự phòng giờ đây là chìa khóa và mọi thứ khác trong một thế giới hoàn hảo không nên xảy ra (chẳng hạn như lỗi gây ra lỗi trong cơ sở dữ liệu cho tất cả mọi người). Chúng tôi chỉ bắt đầu mong đợi một trăm hoặc hơn để chuyển sang hệ thống từ phần mềm tự lưu trữ cũ và nhanh chóng chuyển thành 200.500.1000.100 ... Chúng tôi hiện có hơn 750.000 người dùng sử dụng hệ thống của chúng tôi mỗi năm và vào tháng 8/tháng 9, chúng tôi có hơn 15.000 người dùng đồng thời trực tuyến (dự kiến ​​đạt 20.000 trong năm nay).

Hope rằng đây là sự giúp đỡ một người nào đó dọc theo dòng :-)

Trân

Liam

+0

Wow đó là rất nhiều cơ sở dữ liệu! Tôi đã kết thúc việc triển khai cấu trúc này cũng như dự án mà tôi đang làm việc và gặp phải những cạm bẫy tương tự. Kiểu thiết lập này đòi hỏi nhiều kiến ​​trúc và công cụ tùy chỉnh hơn sau đó là một hệ thống cơ sở dữ liệu duy nhất để mọi người xem xét, được cảnh báo, nó không dành cho những người yếu tim. – Frank

+0

Hoàn toàn đồng ý về "không dành cho những người yếu tim" vì chúng tôi phải tùy chỉnh rất nhiều để làm cho cuộc sống dễ dàng hơn. Tôi đã tùy chỉnh thói quen sao lưu để sao lưu và tải lên từng bản sao lưu vào bộ lưu trữ Amazon S3. Như tôi đã nói, điểm phá vỡ chính đối với tôi bây giờ là chúng tôi không thể cung cấp dự phòng với mô hình này, mà không có đầu vào thủ công lớn để di chuyển mọi người xung quanh cơ sở dữ liệu. –

Các vấn đề liên quan