Hướng dẫn kiến ​​trúc máy chủ SQL

Question

Chúng tôi đang thiết kế phiên bản mới của sản phẩm hiện có của chúng tôi trên một lược đồ mới. Ứng dụng web nội bộ của nó với 100 người dùng đồng thời (tối đa) Điều này sẽ chạy trên cơ sở dữ liệu SQL Server 2008.

Trên các mục thảo luận gần đây là liệu chúng ta nên có một cơ sở dữ liệu tách cơ sở dữ liệu cho các lý do hiệu suất trên 2 cơ sở dữ liệu riêng biệt.

Cơ sở dữ liệu có thể phát triển ở bất kỳ đâu từ 50-100GB trong 5 năm.

Chúng tôi là Nhà phát triển chứ không phải DBA nên sẽ rất tuyệt khi nhận được một số hướng dẫn chung.

[Tôi biết câu trả lời là không đơn giản vì nó phụ thuộc vào lược đồ, lưu trữ chính sách, số lượng dữ liệu vv]

Lựa chọn 1 đơn chính Cơ sở dữ liệu [Đây là lựa chọn ưa thích của tôi].

Kế hoạch sẽ có tất cả các bảng trong một cơ sở dữ liệu và có thể sử dụng các nhóm tệp và phân đoạn để tách dữ liệu nếu được yêu cầu trên nhiều đĩa. [Sử dụng lược đồ nếu thích hợp]. Điều này nên đối phó với các mối quan tâm hiệu suất Một trong những ý kiến ​​wrt này là một cá thể máy chủ duy nhất vẫn sẽ được xử lý dữ liệu này vì vậy vẫn sẽ có một cổ chai xử lý.

Để báo cáo, chúng tôi có thể có DB báo cáo riêng nhưng điều này vẫn đang được thảo luận.

Lựa chọn 2 Tách cơ sở dữ liệu thành 2 cơ sở dữ liệu riêng biệt

DB1 - Khách hàng, tài khoản, tài nguyên khách hàng vv

DB2 - Đây sẽ chứa phần lớn các dữ liệu [ví dụ: Dữ liệu theo dõi xe, bảng giao dịch tài chính, v.v.].

Các bảng này thường chứa rất nhiều dữ liệu. [Nó có thể nằm trên một máy chủ riêng biệt nếu được yêu cầu]

Kế hoạch này sẽ liên quan đến việc giữ dữ liệu chính trong cơ sở dữ liệu nhỏ hơn [DB1] và giữ lại [chủ yếu] chỉ đọc dữ liệu loại giao dịch trong một DB riêng biệt [DB2]. Giao diện người dùng chủ yếu sẽ đọc từ DB1 và ​​do đó sẽ phản hồi nhanh hơn. [Tôi biết rằng tùy chọn này làm cho việc thực thi tính toàn vẹn tham chiếu trở nên khó khăn hơn.]

Điểm cần xem xét Vì chúng tôi đang ở giai đoạn thiết kế, ít nhất chúng tôi có thể sử dụng đúng các chỉ mục để giải quyết các vấn đề về hiệu suất tại sao tùy chọn 1 với tôi là hấp dẫn và nhiều hơn một cách tiếp cận tiêu chuẩn. Đối với cả hai tùy chọn, chúng tôi đang xem xét triển khai cơ sở dữ liệu lưu trữ.

Xin lỗi cho câu hỏi dài. Tóm lại câu hỏi là 1 DB hoặc 2?

Cảm ơn trước,

Liam

Answer 1

Lựa chọn 1 trong quan điểm của tôi là con đường để đi.

CPU rất khó có thể là nút cổ chai của bạn với 100 người dùng đồng thời cung cấp khối lượng công việc của bạn.Bạn có thể có được một máy chủ đa ổ cắm duy nhất với công suất CPU bổ sung có sẵn thông qua công nghệ trao đổi nóng để cung cấp phòng để phát triển nếu bạn muốn. Phụ thuộc vào các yêu cầu về tính khả dụng của bạn, bạn cũng có thể cân nhắc việc sử dụng giải pháp Clustering để cho phép trao đổi trong nhiều tài nguyên CPU xử lý hơn bằng cách buộc phải chuyển sang một nút khác.

Hiệu suất của hệ thống phụ đĩa sẽ là mối quan tâm lớn nhất của bạn. Các quyết định thiết kế của bạn sẽ bị ảnh hưởng bởi giải pháp lưu trữ mà bạn sử dụng, mà tôi cho là công nghệ SAN.

Tối thiểu bạn sẽ muốn đặt các tệp LOG (RAID 1) và DATA (RAID 10 hoặc 5 phụ thuộc vào khối lượng công việc) trên LUNS riêng biệt.

Tùy thuộc vào quyền truy cập bảng của bạn, bạn có thể cân nhắc việc đặt các Nhóm tệp khác nhau trên LUN riêng biệt. Phân vùng dữ liệu bảng của bạn có thể chứng minh thuận lợi cho bạn nhưng chỉ cho các bảng lớn.

Answer 2

50 đến 100GB và 100 người dùng là một cơ sở dữ liệu khá nhỏ theo hầu hết các tiêu chuẩn hiện nay. Đừng qua kỹ sư giải pháp của bạn bằng cách cố gắng giải quyết các vấn đề mà bạn chưa từng thấy. Chia nó thành hai cơ sở dữ liệu, đặc biệt là trên hai máy chủ khác nhau sẽ tạo ra một loạt các cơn đau đầu mà bạn tốt hơn mà không có. Tập trung nỗ lực của bạn vào việc tạo ra một sản phẩm hữu ích để thay thế.

Answer 3

Tôi đồng ý với các nhận xét khác cho biết rằng từ 50 đến 100 GB là nhỏ trong những ngày này. Tôi cũng đồng ý rằng bạn không nên overengineer. Tuy nhiên, nếu có sự tách biệt hợp lý (hoặc không rõ ràng) giữa các thực thể bạn lưu trữ (như bạn nói, một là đọc-ghi và các phần khác chủ yếu là chỉ đọc), tôi vẫn chia nó ra. trong các dbs khác nhau. Ít nhất tôi sẽ thiết kế nó theo cách mà tôi có thể dễ dàng tạo ra một phần. An ninh sẽ là một lý do, quản lý/sao lưu/khôi phục khác, dễ bảo trì hơn (vì vốn dĩ là thiết kế tốt hơn và các bộ phận được tách biệt tốt hơn), và trong SQL Server, khả năng mở rộng (hoặc thiếu nó nếu nó là một cơ sở dữ liệu duy nhất). Việc tách cơ sở dữ liệu đăng nhập và nội dung ví dụ thường có ý nghĩa đối với các ứng dụng web lớn hơn. Và, nếu bạn thực sự muốn có một thiết kế âm thanh, hãy tách riêng các thực thể của bạn trong một db duy nhất, sử dụng các lược đồ khác nhau, đặt quyền thích hợp trên các đối tượng, bạn kết thúc với nỗ lực tương tự trong mắt tôi.

Các sản phẩm của Microsoft như SharePoint, TFS và BizTalk đều sử dụng một số cơ sở dữ liệu khác nhau (Mặc dù tôi không giả vờ nhận thức được lý do/có lẽ chỉ là kết quả của cách tổ chức nhóm của họ).

Đặc biệt liên quan đến điều đó bạn không thể mở rộng một cá thể cơ sở dữ liệu duy nhất trên SQL Server (phân cụm cần nhiều phiên bản), tôi muốn bị chia nhỏ nó.

@John: Tôi sẽ không bao giờ sử dụng RAID5. Không giải quyết được mục đích nào ngoài việc làm tổn thương hiệu suất. Tôi đồng ý với phương pháp RAID10.

Answer 4

Đưa dữ liệu vào cơ sở dữ liệu khác sẽ không tạo ra sự khác biệt nhỏ nhất về hiệu suất. Hiệu suất là một yếu tố hoàn toàn khác.

Lý do để tạo cơ sở dữ liệu mới là vì lý do bảo trì và quản trị. Ví dụ: nếu một tập hợp dữ liệu cần một chính sách sao lưu và khôi phục khác hoặc có yêu cầu về tính khả dụng cao hơn.