Чего типы систем должны “увеличить масштаб”, а не “масштабировать горизонтально”?

Я в основном работаю с приложением, которое имеет нулевой горизонтальный масштабирующий потенциал . Несмотря на то, что он работает в Linux, требования к приложениям, структурам данных и вводу-выводу вынуждают меня «масштабироваться» на все более крупные системы, чтобы приспособиться к возрастающим нагрузкам пользователей.

Многие унаследованные бизнес-приложения и транзакционные приложения имеют эти типы ограничений. Это одна из причин, по которой я подчеркиваю, что промышленность сосредотачивается на облачных решениях и архитектурах веб-масштаба, управляемых DevOps, игнорирует значительную часть компьютерного мира.

К сожалению, описываемые мной системы масштабирования действительно несексуальны , поэтому отрасль имеет тенденцию игнорировать их ценность или приуменьшать значение навыков, необходимых для работы с крупными критически важными системами (например, крупный рогатый скот против домашних животных ).

С точки зрения разработчика могу сказать, что почти каждый традиционный мейнстримовый движок баз данных там может только масштабироваться, а масштабирование - это в значительной степени последумка.

В последние годы, с учетом необходимости большей масштабируемости и высокой доступности систем, предпринимались усилия по масштабированию существующих баз данных. Но поскольку проектированию мешает унаследованный код, он в значительной степени просто закрепляется, а не является фундаментальным для проектирования. Вы столкнетесь с этим, если попытаетесь масштабировать большинство известных движков баз данных. Добавление ведомых серверов может быть довольно сложным в настройке, и вы заметите, что это накладывает существенные ограничения, некоторые из которых могут потребовать перетасовки таблиц БД.

Например, большинство из них являются главными/(много)ведомыми, а не многомассивными конструкциями. Другими словами, у вас может быть просто целый сервер, который просто сидит и не может обрабатывать запросы. Некоторые могут, но с ограничениями... например, читать только мульти-ведомые конструкции. Таким образом, у вас может быть один сервер, который принимает записи, а все остальные предоставляют данные только для чтения. Вы заметите, что при настройке этих систем, это не всегда простой процесс и трудно получить хорошую работу. Во многих случаях это кажется очень сложным дополнением.

С другой стороны, есть несколько более новых движков баз данных, которые с самого начала разрабатывались с параллельным и мультимастерным дизайном. NOSQL и NewSQL - это новый класс проектирования.

Так что, казалось бы, лучший способ получить лучшую производительность от традиционного SQL-сервера - это масштабирование! В то время как с NOSQL и NewSQL это и масштабирование, и масштабирование.

Причина, по которой традиционные системы СУБД тесно связаны друг с другом, заключается в том, что все они нуждаются в последовательном представлении одних и тех же данных. Когда у вас несколько серверов, принимающих обновления одних и тех же данных от разных клиентов, какому из них вы доверяете? Любой метод, который пытается обеспечить согласованность данных с помощью какого-то механизма блокировки, требует взаимодействия с другими серверами, что либо снижает производительность, либо влияет на качество данных, поскольку любые данные, считанные с клиента, могут быть устаревшими. И при записи на одну и ту же запись серверы должны сами решать, какие данные являются самыми свежими. Как вы можете видеть, это сложная проблема, которая усложняется тем, что нагрузка распределена между серверами, а не только между процессами или потоками, где доступ к данным все еще довольно быстрый.

На мой взгляд, масштабирование демаркации определяется тем, насколько параллельным может быть рабочий процесс, и насколько плотно параллельные потоки должны координировать друг с другом.

Single Threaded
По какой-то причине, этот рабочий процесс может работать только в одном потоке.

Одна резьба означает одну систему, означающую масштабирование вверх для ускорения процесса.

Тесно связанная параллельность
Это многопоточная система, в которой резьбы должны быть плотно связаны друг с другом. Возможно, межпроцессное взаимодействие должно быть очень быстрым, или все это должно управляться через один менеджер памяти. Большинство систем СУБД являются именно такими параллельными вычислениями.

В основном это системы, которые масштабируются лучше , чем из , хотя есть и исключения. Например, рабочие процессы, которые работали бы на кластере стиля Single System Image, едином пространстве памяти, но высокой латентности между потоками, могут облегчить масштабирование. Но с такими SSI-системами очень сложно работать, поэтому большинство инженеров просто делают большую коробку.

Слабо связанный параллелизм
Это многопоточная/процессорная система, в которой потоки не испытывают проблем с высокими латентностями между ними. Или вообще не нужно разговаривать друг с другом. Классическими примерами таких систем являются масштабируемые web-сервисы и рендер-фермы. Такие системы намного проще сделать больше, чем плотно связанный параллелизм, поэтому такой стиль системы вызывает большой ажиотаж.

Это стиль, в котором шкала из намного проще.