Backend: удаленная или локальная база данных sql

Question

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

Я вижу, что большинство препятствует этомуподход со следующими основными аргументами:

• Масштабируемость более сложна
• Безопасность (как для AppServer, так и для БД в одной среде)
• Конкуренция ресурсов БД и AppServer
• Одиночная точка отказа

Тем не менее, я все еще вижу множество преимуществ, используя подход, позволяющий установить оба на одном сервере:

• Затраты: в частности, выходные расходы: наличие отдельного сервера для моей базы данных приведет к почти удвоению затрат на исходящую передачу (один раз от базы данных до сервера приложений и один раз от сервера приложений обратно к клиенту).По крайней мере, так обстоит дело почти со всеми провайдерами, которые взимают плату за исходящий трафик вашего сервера.Вопрос, с которым я бы не столкнулся, если бы БД была просто на том же сервере.Конечно, вы можете уменьшить его, эффективно используя кэш вашего сервера приложений, но основная проблема все еще остается.
• Скорость: даже если вы по-прежнему будете обращаться к локальной базе данных через TCP, localhost будет просто быстрее
• Масштабируемость: где проблема на самом деле, я мог бы просто запустить БД в собственной виртуальной машине и масштабировать, модернизируя оборудование и назначая оборудование виртуальной машине, которая в этом нуждается.Или масштабируйте горизонтально с новым экземпляром VM / K8s / любым другим, даже если мои AppServers и моя БД находятся на одной машине
• Одинаковые ресурсы: опять же, имея оба в своей виртуальной машине, я мог бы просто назначитьаппаратные ресурсы, где бы они ни были нужны - вообще нет конкуренции?

Исходя из того, что я вижу, вопрос о размещении БД на удаленном сервере может упростить вещи и улучшить вашу безопасность, но я также вижу многопреимуществ с другим подходом, таких как расходы на исходящий перевод.Так можно ли сказать, что он очень ситуативный и основан на реальных потребностях вашего проекта?

(я намеренно не упоминаю универсальные SOA-архитектуры от Google, AWS, MS Azure, поскольку их стоимость просто не стоитне делать их опцией).

Answer 1

Вот мои два цента на эту тему согласно моему пониманию:

Когда приложение новое и его объем и размер относительно невелики, может быть хорошо, если БД находится в той же коробке, что и сервер приложений. Однако со временем в этой настройке возникает несколько проблем. Точки, которые вы упомянули, действительны, однако в долгосрочной перспективе преимущества наличия db на отдельном сервере могут перевесить настройку отдельного сервера.

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

• Как уже упоминалось в вопросе, безопасность является еще одной проблемой. Серверы приложений, как правило, сталкиваются с внешним миром и более уязвимы для атак, и если база данных находится в том же блоке, она не обязательно столкнется с теми же рисками. Вместо этого, если база данных находится в отдельном блоке, она может находиться за брандмауэром и вообще не быть доступной для Интернета.

• Если сервер приложений или сервер БД приводят к сбою системы, оба компонента становятся недоступными (единая точка отказа).

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

• Требования к входам / выходам, процессорам и другим аппаратным средствам компонентов app и db могут сильно отличаться. И даже если применяется контейнеризация, может оказаться невозможным оптимальное распределение ресурсов блока. Вместо этого гораздо проще выполнить планирование емкости, если оба компонента развернуты по отдельности.

Так можно ли сказать, что это очень ситуативно и основано на ваших реальных потребностях проекта?

Любое развертывание всегда должно отвечать конкретным потребностям проекта. Тем не менее, в большинстве случаев, когда приложение становится больше, чтобы не помещаться на одной машине, обычно разделение уровней app и db на разных машинах имеет гораздо больше практических преимуществ, чем одна установка, как я понимаю.

Надеюсь, это поможет!