Когда системе добавляют мощность одного сервера, когда делят работу между несколькими и почему увеличение ресурсов само по себе не решает любую проблему.
Когда одного сервера становится мало
Представим условный сервис, который каждое утро считает отчёты по продажам. Пока данных немного, один сервер успевает обработать всё до начала рабочего дня. Позже появляются новые магазины и дополнительные показатели, отчёт готовится всё дольше. Первая мысль — купить более мощную машину. Иногда это разумно, но сначала надо понять, ограничивает работу память, скорость вычислений, чтение данных или неудачная организация задачи.
Масштабирование означает изменение доступных ресурсов под нагрузку. Вертикальный путь усиливает отдельный узел. Горизонтальный добавляет узлы и распределяет между ними работу. Это архитектурный выбор, а не обещание, что отчёт автоматически ускорится. Если обработка ждёт медленный источник или повторно читает лишние данные, дополнительные мощности могут помочь меньше, чем ожидалось.
Усилить один узел
Вертикальное масштабирование похоже на замену небольшого рабочего стола на большой: можно разложить больше документов и быстрее находить нужное. Для сервера это обычно увеличение доступной памяти, вычислительной мощности или возможностей хранения. Такой шаг часто проще для уже работающей программы, потому что не требует сразу делить задачу между несколькими машинами.
Но у отдельного узла есть пределы. Более мощная конфигурация может стоить дороже, а одна машина остаётся местом возможного отказа, если не предусмотрены другие меры надёжности. Кроме того, нельзя ускорить строго последовательный шаг одним лишь добавлением памяти. Поэтому до покупки полезно измерить, какой ресурс действительно заканчивается в нужный момент.
Разделить работу между узлами
Горизонтальный путь напоминает команду, которая делит пачку документов между несколькими сотрудниками. Каждый обрабатывает свою часть, затем результаты объединяются. Google Cloud описывает распределённое выполнение запросов как последовательность этапов, где отдельные части могут работать параллельно, а данные передаются между этапами.
Параллельность полезна, если задачу можно разделить. Но она приносит новые расходы: части данных приходится распределять, передавать между узлами и снова собирать результат. Если один участок работы зависит от завершения предыдущего или весь набор постоянно перемещается по сети, простое добавление серверов не даст пропорционального выигрыша.
Условный пример и хранение
Допустим, отчёт строится по десяти независимым магазинам. Отдельные расчёты по магазинам можно выполнять параллельно, а общий итог собрать в конце. Если же сначала нужно получить единый справочник товаров, его подготовка может стать узким местом для всех параллельных частей. Команда должна видеть обе стадии, а не только итоговое время.
В архитектуре BigQuery хранение и вычисления разделены, поэтому их ресурсы могут меняться независимо. Это пример конкретной платформы, а не универсальное правило для любой базы. При выборе подхода нужно отдельно обсуждать объём хранения, скорость чтения и вычислительную нагрузку; слово «масштабирование» само по себе не указывает, что именно меняется.
Как выбрать путь
Сначала назовите проблему измеримо: какой отчёт не успевает, когда замедляется, как меняется объём данных и что происходит при пиковой нагрузке. Затем выясните, можно ли разделить задачу без постоянного обмена большими объёмами. Если нет, усиление одного узла или изменение самой обработки может оказаться проще. Если части независимы и нагрузка растёт неравномерно, распределение работы может дать больше гибкости.
У обоих путей есть пределы и организационная цена. Решение стоит проверять на типичном рабочем сценарии, а не на отвлечённом обещании ускорения. Чтобы понять, почему несколько машин вообще могут обрабатывать один набор, прочитайте объяснение распределённой обработки данных. Здесь же главный вопрос — где именно добавлять ресурсы и какую часть работы они действительно разгрузят.
По теме
Следующий шаг
Если хотите развить навыки в этой области, посмотрите курс Архитектор данных и сопоставьте программу со своими задачами. Материал объясняет отдельный вопрос, но не заменяет практику и разбор вашей ситуации.
