В настоящее время у меня есть веб-приложение и база данных на одном сервере. Я перемещаю базу данных на новый сервер, который является базой данных. Теперь у меня есть ночные скрипты, которые запускаются в веб-приложении, которые вставляют и обновляют данные для приложения из нашей системы ERP. Должны ли сценарии, выполняющие этот импорт, запускаться с сервера базы данных или с сервера приложений? Для меня имеет смысл хранить всю логику приложения вместе, но с точки зрения производительности имеет больше смысла (я думаю) иметь скрипты, обновляющие базу данных каждую ночь, для запуска с реального сервера базы данных.
Может понадобиться, а может и нет, но у меня есть веб-сайт и 3 веб-приложения, которые все преобразуются из установок локальной базы данных в новую центральную базу данных.
Последний вопрос: должен ли сервер базы данных находиться в демилитаризованной зоне, но заблокирован, чтобы принимать соединения только для IP-адресов, обслуживающих приложение, или он должен находиться за брандмауэром?
Дополнительная информация, если она полезна: все приложения Python (TG и Flask) работают на postgresql 9.
Изменить: если это неправильное место для этого, дайте мне знать, где это должно быть размещено. Изначально у меня было это у программистов, но я не получил никаких ответов, и после перечитывания моих вопросов этот сайт стал просто "лучше".
Предполагая малую задержку между сервером приложений и сервером базы данных, производительность будет в основном одинаковой независимо от того, на какой стороне вы запускаете сценарии.
Я голосую за то, что легче всего поддерживать. Две причины хранить скрипты на сервере приложений:
1) Меньше изменений в вашем существующем способе ведения дел
2) Весь ваш код (включая эти скрипты) находится в одном месте. Это может иметь преимущества при управлении версиями / развертывании.
А для брандмауэра / DMZ: чем меньше доверие между базой данных и приложением, тем лучше. Если вы можете поместить сервер базы данных за брандмауэр и разрешить только порты PostgreSQL (5432 / tcp по умолчанию) только с вашего сервера приложений в DMZ, тогда скомпрометированная учетная запись приложения должна будет пройти через порт PostgreSQL для дальнейшего проникновения или выбросить ваши данные.
Затем вы можете дополнительно ограничить приложение на уровне базы данных с помощью:
1) Минимальные разрешения для базы данных приложения (только выбор, если необходимо, ...)
2) Обновляемые представления (метод, который может обеспечить более ограниченное обновление данных)
3) Триггеры при обновлении (еще один метод, который может ограничивать обновления)
Многослойная безопасность :)