Ý nghĩa hiệu suất của việc chạy nhiều DB nhỏ hơn thay vì một DB lớn hơn trên máy chủ là gì?


7

Kiến trúc cơ sở dữ liệu của chúng tôi cho phép nhiều 'khách hàng' tồn tại trong cùng một cơ sở dữ liệu, tuy nhiên chúng tôi chia chúng thành cơ sở dữ liệu mulitple vì lý do quản trị [vá, sao lưu, v.v.]

Câu hỏi 1

Hiệu suất sẽ có ý nghĩa gì nếu chúng ta hợp nhất các khách hàng thành một DB duy nhất?

Câu hỏi 2

Chúng tôi hiện có nhiều khách hàng trong mỗi DB, nhưng chúng tôi có thể có 10 khách hàng trong mỗi DB và nói 5 cơ sở dữ liệu; vì vậy, nếu chúng tôi hợp nhất các DB, chúng tôi sẽ chỉ có một DB với 50 khách hàng; điều đó sẽ làm cho nhiều sự khác biệt để hiệu suất?


Trường hợp bạn hiện có 10 khách hàng trong mỗi 5 cơ sở dữ liệu, có bao nhiêu máy chủ vật lý và phiên bản SQL?
Mark Storey-Smith

Đây là những số liệu giả tưởng mà chúng tôi thực sự không có khách hàng, chúng tôi có một khách hàng, được chia thành các khu vực và tiểu vùng khác nhau nhưng phần mềm có thể hoạt động với chúng được phân chia thành các DB hoặc trong một DB duy nhất chúng tôi có nhiều hộp vật lý chạy nhiều DB .
Tai chó

1
Đây là một trong những tình huống "nó phụ thuộc" lớn. Có được một cơ sở cho việc các tài nguyên bị ảnh hưởng như thế nào khi sử dụng perfmon, và thông qua một số tính toán và thử nghiệm, bạn có thể có được một ý tưởng khá hay trước khi đưa sản phẩm này vào sản xuất.
Thomas Stringer

@ Surfer513 - tính toán và kiểm tra gì? Bạn có thể mở rộng trong một câu trả lời thực tế? Thsi là một câu hỏi khá cơ bản "Big v Nhiều nhỏ" - nhưng dường như tôi không thể tìm thấy bất cứ điều gì cụ thể trên mạng.
Tai chó

Cơ sở dữ liệu lớn như thế nào? Có bao nhiêu người dùng đồng thời của hệ thống?
Stuart Blackler

Câu trả lời:


7

Như những người khác đã chỉ ra trong các bình luận, thật khó để tạo ra một câu trả lời cho câu hỏi này mà không hiểu về ứng dụng. Nó phụ thuộc, nó thực sự thực sự làm .

Bản chất của câu hỏi (và câu trả lời) cũng thay đổi trên cơ sở môi trường vật lý tức là nhiều cơ sở dữ liệu trên một máy chủ hoặc trải rộng trên nhiều máy chủ? Là một khách hàng tiêu biểu, hay một số người tiêu thụ một tỷ lệ phần trăm không cân xứng của tài nguyên máy chủ? Trong 3 năm, sẽ có 50 khách hàng hay 50000?

Điều đó nói rằng, hãy có một vết nứt tại nó.

Hiệu suất sẽ có ý nghĩa gì nếu chúng ta hợp nhất các khách hàng thành một DB duy nhất?

Lợi ích tiềm năng

  • Giảm bộ nhớ cache kế hoạch. Nếu bạn có 5 cơ sở dữ liệu giống nhau, bạn có 5 bản sao của mỗi kế hoạch thực hiện.
  • Cải thiện việc sử dụng vùng đệm. Tương tự như trên, bất kỳ dữ liệu phổ biến nào bạn có trong mỗi cơ sở dữ liệu đều tồn tại trong vùng đệm cho mỗi cơ sở dữ liệu.
  • Cải thiện việc sử dụng cpu / bộ nhớ. Hợp nhất nhiều máy chủ cho một máy chủ sẽ loại bỏ chi phí hoạt động của hệ điều hành trên mỗi máy chủ.
  • Có thể cải thiện việc sử dụng IO. Kết hợp các mảng nhỏ hơn được phân bổ cho mỗi máy chủ có thể giúp cải thiện thông lượng tổng thể bằng cách có công suất cao hơn để xử lý các đỉnh.

Rủi ro tiềm tàng

  • $$$. Nhiều máy chủ thông số kỹ thuật thấp thường rẻ hơn so với một cường quốc hùng mạnh. Truyền tải tải trên các máy chủ tiện ích có thể rẻ hơn.
  • Mở rộng linh hoạt. Khi bạn có tất cả khách hàng trên tất cả máy chủ quyền lực hùng mạnh đó và nó hết hơi, việc nâng cấp rất khó khăn và phức tạp.
  • Khóa / chặn / khóa chết. Bất kỳ thiếu sót nào trong cơ sở dữ liệu và thiết kế ứng dụng có khả năng sẽ được phóng to trong một môi trường máy chủ duy nhất.

Từ ý kiến ​​của bạn, có vẻ như đây là những ngày đầu cho phần mềm và công ty của bạn. Vì vậy, tôi đang tìm cách để tối đa hóa sự linh hoạt và giảm thiểu chi tiêu vốn.

  • Cài đặt một mảng iSCSI có thể mở rộng. Với bộ nhớ riêng biệt, bạn có thể mở rộng cả dung lượng GB thô và IOPS tách biệt khỏi máy chủ.
  • Làm cho dữ liệu khách hàng của bạn di động. Có thể khó trang bị thêm nhưng nếu bạn có thể di chuyển dữ liệu của khách hàng từ hệ thống này sang hệ thống khác, bạn có thể di chuyển chúng giữa các hệ thống để cân bằng khối lượng công việc tốt hơn.
  • Cấp khách hàng của bạn. Phân bổ mỗi khách hàng vào một cấp tùy thuộc vào cách sử dụng của họ, có thể là 3 tầng ban đầu. Phân tích các mô hình sử dụng điển hình cho các tầng khách hàng này và phân bổ chúng cho các tài nguyên máy chủ phù hợp. Có thể là bạn có thể chứa 200 khách hàng cấp 3 trên một hộp hoặc 50 cấp 2 hoặc 10 cấp 1.

Có lẽ ảo hóa sẽ là một phù hợp tốt hơn. Có lẽ đám mây sẽ hoạt động. Có lẽ đám mây lai. Thành thật mà nói, nó thực sự phụ thuộc . Gọi một chuyên gia để giúp đỡ, họ có thể giúp bạn tiết kiệm một khoản tiền.


Ngoài ra, bạn càng có nhiều cơ sở dữ liệu trên một máy chủ nhất định, thì máy chủ đó sẽ mất nhiều thời gian hơn để khởi động lại sau khi khởi động lại, thất bại, v.v.
Eric Humphrey - lotahelp

4

Một trong những nhược điểm lớn nhất với rất nhiều cơ sở dữ liệu nhỏ hơn (và nhỏ hơn rõ ràng là kích thước tương đối), là quản lý nhật ký. Các tệp nhật ký được ghi theo tuần tự, không ngẫu nhiên. Với một cơ sở dữ liệu lớn, bạn có thể dành tệp nhật ký của mình cho một mảng đĩa đơn, mang lại hiệu suất tuần tự tối đa. Nếu bạn có 50 cơ sở dữ liệu trên cùng một mảng, dữ liệu sẽ thực sự là IO ngẫu nhiên, gây ra hiệu suất kém hơn.

Điều tương tự cũng xảy ra đối với các tệp dữ liệu ở một mức độ nào đó, nhưng vì chúng được ghi không đồng bộ bởi quy trình điểm kiểm tra, nên nó ít gặp vấn đề hơn vì nó chủ yếu sẽ được ghi tuần tự nhỏ hơn.

Chúng tôi đang chạy một kiến ​​trúc tương tự và trong khi tôi thực sự tận hưởng những lợi ích trong khả năng vá lỗi và chạy các phiên bản khác nhau, tôi chắc chắn sẽ tìm giải pháp hoàn toàn cho nhiều người thuê nếu tôi phải làm điều đó.


2

Hiệu suất sẽ có ý nghĩa gì nếu chúng ta hợp nhất các khách hàng thành một DB duy nhất?

Chỉ có bạn mới có thể trả lời câu hỏi này. Không biết môi trường của bạn hoặc cấu hình máy chủ của bạn, điều này sẽ khó dự đoán. Có những công cụ có thể được sử dụng để kiểm tra các cấu hình hiện tại của bạn để xem giới hạn mà chúng có thể xử lý.

Bạn nên thiết lập một tập lệnh để thu thập các bộ đếm hiệu suất trong một khoảng thời gian để bạn có một đường cơ sở tốt cho các hệ thống của mình. Bạn sẽ có thể sử dụng điều này để tìm thời gian lưu lượng truy cập cao nhất của mình cho từng người. Bạn có thể thực hiện tìm kiếm nhanh trên Google cho "bộ đếm hiệu suất SQL Server" có thể chỉ cho bạn đi đúng hướng. Tôi cũng chắc chắn rằng stackexchange cũng có nhiều bài đăng trên đó.

EDIT Đây sẽ là một liên kết tốt để bắt đầu với các bộ đếm hiệu suất.


Có lẽ tôi cần phải viết lại câu hỏi - Tôi đang trả lời chung chung, đưa ra hướng dẫn về cách tiếp cận tốt nhất được coi là và tổng quan về lý do tại sao. Câu trả lời của bạn có vẻ hơi giống câu trả lời kiểu 'Nó phụ thuộc', mặc dù có lẽ chính xác nhưng không thực sự giúp tôi :(
Dog Ears

0

Tôi biết câu hỏi này hỏi cụ thể về ý nghĩa hiệu suất, và đã có câu trả lời tốt ở đây, nhưng tôi nghĩ sẽ rất tiếc nếu không đề cập đến một chủ đề chưa được giới thiệu khi nói về các giải pháp nhiều người thuê: bảo mật .

Khi bạn giữ dữ liệu cho nhiều khách hàng trong một cơ sở dữ liệu, bạn phải cực kỳ cẩn thận khi nói đến bảo mật, không chỉ trong chính cơ sở dữ liệu mà còn trong (các) ứng dụng. Nói chung, một khách hàng sẽ không bao giờ có thể xem dữ liệu của khách hàng khác. Tôi không biết doanh nghiệp của bạn, nhưng đây thường là trường hợp.

Khi kiến ​​trúc một ứng dụng, việc tạo ranh giới bảo mật là mong muốn, do đó, nếu nhóm của bạn xảy ra một lỗi nhỏ, đã có một dự phòng tích hợp để ngăn điều xấu xảy ra. Cơ sở dữ liệu là một loại ranh giới bảo mật.

Sự tách biệt này (một yêu cầu kinh doanh, có thể tồn tại hoặc không tồn tại) cần được cân bằng với kế hoạch của bạn để quản lý dữ liệu, hiệu suất, v.v., mặc dù các yêu cầu bảo mật có thể (và nên) thổi phồng mọi thứ khác nếu doanh nghiệp coi là đủ quan trọng .

Vâng, có vẻ như có tiếng vang ở đây, nhưng nó thực sự phụ thuộc vào tình huống chính xác của bạn để đưa ra quyết định tốt nhất. Tất cả những gì chúng tôi có thể làm là cung cấp cho bạn những ý tưởng để giúp bạn đi đến kết luận đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.