Lý do KHÔNG tăng tỷ lệ so với -out?

Question

Là một lập trình viên, tôi thực hiện các phát hiện mang tính cách mạng vài năm một lần. Tôi đang ở phía trước của đường cong, hoặc đằng sau nó bằng khoảng π trong pha. Một bài học khó khăn mà tôi đã học được là việc mở rộng quy mô OUT không phải lúc nào cũng tốt hơn, khá thường là hiệu suất đạt được lớn nhất là khi chúng tôi tập hợp lại và mở rộng quy mô.

Bạn có lý do gì để mở rộng quy mô so với không? Giá, hiệu suất, tầm nhìn, sử dụng dự kiến? Nếu vậy, làm thế nào điều này làm việc cho bạn?

Chúng tôi đã từng thu nhỏ tới hàng trăm nút sẽ tuần tự hóa và lưu trữ dữ liệu cần thiết cho mỗi nút và chạy các quy trình toán học trên các bản ghi. Nhiều, hàng tỷ bản ghi cần phải được phân tích chéo. Đó là trường hợp kinh doanh và kỹ thuật hoàn hảo để sử dụng quy mô. Chúng tôi tiếp tục tối ưu hóa cho đến khi chúng tôi xử lý khoảng 24 giờ dữ liệu trong 26 giờ wallclock. Thực sự dài câu chuyện ngắn, chúng tôi cho thuê một IBM khổng lồ (cho thời gian) pSeries, đưa Oracle Enterprise vào nó, lập chỉ mục dữ liệu của chúng tôi và kết thúc xử lý cùng 24 giờ dữ liệu trong khoảng 6 giờ. Cách mạng cho tôi.

Vì vậy, nhiều hệ thống doanh nghiệp là OLTP và dữ liệu không phải là shard'd, nhưng mong muốn của nhiều người là phân cụm hoặc mở rộng quy mô. Đây có phải là phản ứng đối với các kỹ thuật mới hoặc hiệu suất nhận thức không?

Thực hiện các ứng dụng nói chung ngày hôm nay hoặc matras chương trình của chúng tôi cho vay tốt hơn cho quy mô không? Chúng ta có nên đưa xu hướng này vào tài khoản trong tương lai không?

Answer 1

Không ngạc nhiên, tất cả đều phụ thuộc vào vấn đề của bạn. Nếu bạn có thể dễ dàng phân vùng nó thành các bài toán con không giao tiếp nhiều, hãy mở rộng quy mô cho các tăng tốc tầm thường. Ví dụ, tìm kiếm một từ trong các trang web 1B có thể được thực hiện bởi một máy tìm kiếm các trang 1B hoặc bằng các máy 1M làm 1000 trang mà không làm mất hiệu quả đáng kể (vì vậy với tốc độ 1.000.000x). Điều này được gọi là "lúng túng song song".

Các thuật toán khác, tuy nhiên, yêu cầu giao tiếp chuyên sâu hơn nhiều giữa các phân mục. Ví dụ của bạn yêu cầu phân tích chéo là ví dụ hoàn hảo về nơi giao tiếp thường có thể làm giảm hiệu suất hoạt động của việc thêm nhiều hộp. Trong những trường hợp này, bạn sẽ muốn giữ liên lạc bên trong một hộp (lớn hơn), đi qua các kết nối tốc độ cao, thay vì cái gì đó là 'phổ biến' như (10-) Gig-E.

Tất nhiên, đây là một quan điểm khá lý thuyết. Các yếu tố khác, chẳng hạn như I/O, độ tin cậy, dễ lập trình (một bộ nhớ chia sẻ lớn thường gây ra ít đau đầu hơn nhiều so với cụm) cũng có thể có ảnh hưởng lớn.

Cuối cùng, do lợi ích chi phí (thường cực) của việc mở rộng sử dụng phần cứng hàng hóa giá rẻ, phương pháp tiếp cận cụm/lưới gần đây đã thu hút nhiều nghiên cứu (thuật toán) hơn. Điều này làm cho các cách thức song song mới đã được phát triển để giảm thiểu giao tiếp, và do đó làm tốt hơn nhiều trên một cụm - trong khi kiến ​​thức phổ biến được sử dụng để chỉ ra rằng các loại thuật toán này chỉ có thể chạy hiệu quả trên các máy sắt lớn ...

Answer 2

Do mở rộng quy mô

• là giới hạn cuối cùng bởi kích thước của hộp bạn thực sự có thể mua
• có thể trở nên cực kỳ tiết kiệm chi phí hiệu quả, ví dụ một máy tính với 128 lõi và 128G ram là tốn kém hơn nhiều so với 16 với 8 lõi và 8G ram mỗi.
• Một số thứ không mở rộng tốt - chẳng hạn như thao tác đọc IO.
• Bằng cách mở rộng quy mô, nếu kiến ​​trúc của bạn là đúng, bạn cũng có thể đạt được tính sẵn sàng cao. Một máy ram 128G, 128G rất đắt, nhưng để có một máy dự phòng thứ 2 thì sẽ bị tống tiền.

Và cũng ở một mức độ nào đó, vì đó là những gì Google làm.

Answer 3

Chia tỷ lệ ra là tốt nhất cho các vấn đề embarrassingly parallel. Phải mất một số công việc, nhưng một số dịch vụ web phù hợp với loại đó (do đó phổ biến hiện nay). Nếu không, bạn chạy vào Amdahl's law, sau đó có nghĩa là để đạt được tốc độ bạn phải mở rộng quy mô. Tôi nghi ngờ bạn đã gặp phải vấn đề đó. Ngoài ra các hoạt động liên kết IO cũng có xu hướng hoạt động tốt với việc mở rộng quy mô lớn bởi vì chờ IO tăng% mà là song song.

Answer 4

Bài đăng trên blog Scaling Up vs. Scaling Out: Hidden Costs bởi Jeff Atwood có một số điểm thú vị cần xem xét, chẳng hạn như cấp phép phần mềm và chi phí điện năng.