Я долгое время задавался вопросом, есть ли системы, которые должны «масштабироваться» (на более мощный и более дорогой сервер), а не «масштабироваться» путем разделения на множество меньших серверов.
Существуют ли такие системы, и если да, то есть ли что-то конкретное, что заставляет системы увеличиваться, а не масштабироваться? (Например, эта потребность может возникнуть из-за транзакций базы данных с жалобами на ACID или других строгих требований к целостности данных.)
Поскольку масштабирование, похоже, приведет к гораздо более высоким затратам на оборудование, чем масштабирование, похоже, что вы хотели бы избежать, если возможно, но я не уверен, всегда ли этого можно избежать или нет.
Итак, есть ли системы, которые нельзя масштабировать, а их нужно масштабировать? Что может быть причиной этого и как бы вы идентифицировали такую систему? (Есть ли у них какие-то общие характеристики, которые могут облегчить их идентификацию?)
Я в основном работаю с приложением, в котором нуль потенциал горизонтального масштабирования. Несмотря на то, что он работает в Linux, требования к приложениям, структурам данных и вводу-выводу вынуждают меня «масштабироваться» на все более крупные системы, чтобы приспособиться к возрастающим пользовательским нагрузкам.
Многие унаследованные бизнес-приложения и транзакционные приложения имеют такие ограничения. Это одна из причин, по которой я подчеркиваю, что отрасль фокусируется на облачные решения а архитектуры веб-масштаба, основанные на DevOps, игнорируют значительную часть компьютерного мира.
К сожалению, описываемые мной системы масштабирования действительно несексуальный, поэтому отрасль имеет тенденцию игнорировать их ценность или недооценивать навыки, необходимые для работы с большими критическими системами (например, крупный рогатый скот против домашних животных).
С точки зрения разработчика я могу сказать, что почти каждый традиционный основной движок баз данных может только масштабироваться, а масштабирование - это очень поздно.
В последние годы, когда возникла потребность в большей масштабируемости и высокой доступности систем, были предприняты попытки масштабировать существующие базы данных. Но поскольку дизайну препятствует унаследованный код, он во многом привязан к дизайну, а не является основополагающим. Вы столкнетесь с этим, если попытаетесь масштабировать большинство известных движков баз данных. Добавление подчиненных серверов может быть довольно сложным в настройке, и вы заметите, что оно имеет существенные ограничения, некоторые из которых могут потребовать повторного переноса таблиц базы данных.
Например, большинство из них являются схемами типа "ведущий / (много) ведомый", а не с несколькими ведущими. Другими словами, у вас может быть целый сервер, который просто сидит и не может обрабатывать запросы. Некоторые делают, но с ограничениями ... например, читать только мульти-раб дизайн. Таким образом, у вас может быть один сервер, который принимает записи, а все остальные предоставляют данные только для чтения. Вы заметите, что когда вы настраиваете эти системы, это не всегда простой процесс, и его сложно наладить. Во многих случаях он кажется очень неприятным.
С другой стороны, есть несколько новых движков баз данных, которые с самого начала разрабатываются с параллелизмом и несколькими мастерами. NOSQL и NewSQL новый класс дизайна.
Казалось бы, лучший способ повысить производительность традиционного SQL-сервера - это масштабирование! В то время как с NOSQL и NewSQL он масштабируется и масштабируется.
Причина, по которой традиционные системы СУБД тесно связаны, заключается в том, что всем им требуется согласованное представление одних и тех же данных. Когда у вас есть несколько серверов, принимающих обновления одних и тех же данных от разных клиентов, какому из них вы доверяете? Любой метод, который пытается обеспечить согласованность данных с помощью какого-либо механизма блокировки, требует взаимодействия с другими серверами, что либо снижает производительность, либо влияет на качество данных, поскольку любые данные, считанные с клиента, могут быть устаревшими. И серверы должны решить между собой, какие данные самые последние при записи в одну и ту же запись. Как видите, это сложная проблема, усложняющаяся тем фактом, что рабочая нагрузка распределяется по серверам, а не только между процессами или потоками, где доступ к данным по-прежнему довольно быстрый.
На мой взгляд, разграничение масштабирования / уменьшения определяется тем, насколько параллельным может быть рабочий процесс и насколько тесно параллельные потоки должны координироваться друг с другом.
Одинарная резьба
По какой-то причине этот рабочий процесс может работать только в одном потоке.
Один поток означает, что одна система означает масштаб вверх чтобы он пошел быстрее.
Сильно связанный параллелизм
Это многопоточная система, в которой нити должны быть плотно связаны друг с другом. Возможно, взаимодействие между процессами должно быть очень быстрым, или всем этим нужно управлять с помощью единого диспетчера памяти. Большинство систем РСУБД - это такие параллельные вычисления.
По большей части эти системы масштабируются вверх лучше чем вне хотя бывают исключения. Например, рабочие процессы, которые будут работать на Единый образ системы кластер стиля, единое пространство памяти, но высокая задержка между потоками, может упростить масштабирование. Но с такими системами SSI очень сложно работать, поэтому большинство инженеров просто делают коробку побольше.
Слабо связанный параллелизм
Это многопоточная / процессная система, в которой потоки работают нормально с большими задержками между собой. Или вообще не нужно друг с другом разговаривать. Масштабируемые веб-серверы и рендер-фермы являются классическими примерами такого рода систем. Такие системы намного легче сделать больше, чем тесно связанный параллелизм, поэтому такой стиль системы вызывает много восторга.
Это стиль, в котором масштаб вне намного проще.