Những loại hệ thống nào có thể mở rộng quy mô trên phạm vi thay vì quy mô trên phạm vi khác?

Tôi đã băn khoăn trong một thời gian dài nếu có những hệ thống phải "mở rộng quy mô" (lên một máy chủ mạnh hơn, đắt tiền hơn) thay vì "mở rộng quy mô" bằng cách chia thành nhiều máy chủ nhỏ hơn.

Các hệ thống như vậy có tồn tại không, và nếu vậy, có điều gì đặc biệt có xu hướng khiến các hệ thống cần phải được nhân rộng, thay vì thu nhỏ lại không? (Ví dụ: có thể các giao dịch cơ sở dữ liệu khiếu nại ACID hoặc các yêu cầu toàn vẹn dữ liệu mạnh khác tạo ra nhu cầu này.)

Vì việc nhân rộng có vẻ như sẽ mang lại chi phí phần cứng cao hơn nhiều so với việc nhân rộng ra, có vẻ như đó là điều bạn muốn tránh, nếu có thể, nhưng tôi không chắc liệu điều đó có luôn tránh được hay không.

Vì vậy, có những hệ thống không thể được thu nhỏ lại và thay vào đó phải được nhân rộng? Điều gì có thể gây ra điều này, và làm thế nào bạn sẽ xác định một hệ thống như vậy? (Họ có thường chia sẻ một số đặc điểm chung có thể khiến chúng dễ nhận dạng hơn không?)

Tôi chủ yếu làm việc với một ứng dụng mà có zero tiềm năng mở rộng quy mô ngang . Mặc dù nó chạy trên Linux, nhưng các ứng dụng, cấu trúc dữ liệu và các yêu cầu I / O buộc tôi phải "tăng quy mô" lên các hệ thống lớn hơn để đáp ứng khối lượng công việc của người dùng tăng lên.

Nhiều ứng dụng giao dịch và kinh doanh kế thừa có các loại ràng buộc này. Đó là một lý do tôi nhấn mạnh rằng ngành công nghiệp tập trung vào các giải pháp đám mây và các kiến ​​trúc quy mô web dựa trên DevOps bỏ qua một tỷ lệ tốt trong thế giới điện toán.

Thật không may, các hệ thống mở rộng mà tôi mô tả là thực sự không rõ ràng , vì vậy ngành công nghiệp có xu hướng bỏ qua giá trị của chúng hoặc coi thường các kỹ năng cần thiết để giải quyết các hệ thống quan trọng, lớn (ví dụ gia súc so với vật nuôi ).

Từ góc độ nhà phát triển, tôi có thể nói rằng gần như mọi công cụ cơ sở dữ liệu chính thống truyền thống ngoài kia chỉ có thể mở rộng quy mô và nhân rộng ra rất nhiều sau khi nghĩ.

Trong những năm gần đây với nhu cầu về khả năng mở rộng lớn hơn và các hệ thống có tính sẵn sàng cao, đã có những nỗ lực để làm cho các cơ sở dữ liệu hiện có mở rộng ra. Nhưng bởi vì các thiết kế bị cản trở bởi mã kế thừa, nên nó chỉ được củng cố chứ không phải là cơ bản cho thiết kế. Bạn sẽ gặp phải điều này nếu cố gắng mở rộng hầu hết các công cụ cơ sở dữ liệu nổi tiếng. Thêm máy chủ nô lệ có thể khá khó để thiết lập và bạn sẽ nhận thấy rằng nó đi kèm với những hạn chế đáng kể, một số trong đó có thể yêu cầu sắp xếp lại các bảng cơ sở dữ liệu của bạn.

Ví dụ, hầu hết trong số chúng là nô lệ chủ / (đa-) thay vì thiết kế đa chủ. Nói cách khác, bạn có thể có toàn bộ máy chủ chỉ ngồi đó và không thể xử lý các truy vấn. Một số làm, nhưng với những hạn chế ... ví dụ chỉ đọc thiết kế đa nô lệ. Vì vậy, bạn có thể có một máy chủ ghi và tất cả các máy chủ khác cung cấp dữ liệu chỉ đọc. Bạn sẽ nhận thấy khi bạn thiết lập các hệ thống này, nó không phải lúc nào cũng là một quá trình đơn giản và khó để hoạt động tốt. Nó cảm thấy rất nhiều một tia trên ngoài trong nhiều trường hợp.

Mặt khác, có một số công cụ cơ sở dữ liệu mới hơn đang được phát triển với thiết kế đồng thời và đa chủ ngay từ đầu. NOSQL và NewQuery là lớp thiết kế mới.

Vì vậy, có vẻ như cách tốt nhất để có được hiệu suất tốt hơn từ máy chủ SQL truyền thống là tăng quy mô! Trong khi với NOSQL & NewQuery, cả hai đều mở rộng và mở rộng quy mô.

Lý do các hệ thống RDBMS truyền thống được kết hợp chặt chẽ là bởi vì tất cả chúng đều cần một cái nhìn nhất quán về cùng một dữ liệu. Khi bạn có nhiều máy chủ chấp nhận cập nhật cho cùng một dữ liệu từ các máy khách khác nhau, bạn tin tưởng vào máy chủ nào? Bất kỳ phương pháp nào cố gắng đảm bảo dữ liệu nhất quán thông qua một số loại cơ chế khóa đều cần có sự hợp tác từ các máy chủ khác làm giảm hiệu suất hoặc ảnh hưởng đến chất lượng dữ liệu trong đó mọi dữ liệu được đọc từ máy khách có thể bị lỗi thời. Và các máy chủ cần tự quyết định dữ liệu nào gần đây nhất khi ghi vào cùng một bản ghi. Như bạn có thể thấy đó là một vấn đề phức tạp trở nên phức tạp hơn bởi thực tế là khối lượng công việc được trải đều trên các máy chủ và không chỉ giữa các quy trình hoặc luồng mà việc truy cập dữ liệu vẫn còn khá nhanh.

Theo tôi, việc phân chia tỷ lệ lên / xuống được xác định dựa trên mức độ song song của một luồng công việc và các luồng song song cần phối hợp chặt chẽ với nhau như thế nào.

Single Threaded
Vì bất kỳ lý do gì, quy trình công việc này chỉ có thể hoạt động trong một luồng duy nhất.

Một luồng có nghĩa là một hệ thống có nghĩa là tăng quy mô để làm cho nó đi nhanh hơn.

Song song liên kết chặt chẽ
Đây là một hệ thống đa luồng, trong đó các luồng cần phải được liên kết chặt chẽ với nhau. Có lẽ giao tiếp giữa các quá trình cần phải rất nhanh, hoặc tất cả cần phải được quản lý thông qua một trình quản lý bộ nhớ duy nhất. Hầu hết các hệ thống RDBMS là loại tính toán song song này.

Đối với hầu hết các phần, các hệ thống này là những người mà quy mô lên hơn ra mặc dù có những ngoại lệ. Ví dụ, các quy trình công việc sẽ hoạt động trên cụm kiểu Ảnh hệ thống đơn, không gian bộ nhớ đơn nhưng độ trễ cao giữa các luồng, có thể giúp thu nhỏ dễ dàng hơn. Nhưng các hệ thống SSI như vậy rất khó để làm việc với hầu hết các kỹ sư chỉ tạo ra một hộp lớn hơn.

Song song liên kết lỏng lẻo
Đây là một hệ thống đa luồng / quy trình trong đó các luồng đều ổn với độ trễ cao giữa nhau. Hoặc không cần nói chuyện với nhau. Mở rộng quy mô phục vụ web và trang trại kết xuất là những ví dụ kinh điển của loại hệ thống này. Các hệ thống như thế này dễ dàng hơn nhiều để tạo ra lớn hơn so với song song kết hợp chặt chẽ, đó là lý do tại sao có rất nhiều hứng thú về phong cách hệ thống này.

Đây là phong cách mà quy mô ra dễ dàng hơn rất nhiều.