AWS DynamoDB против RDS для Lambda безсерверной архитектуры

Question

Я являюсь частью команды, в настоящее время разрабатывающей архитектуру / приложение Proof of Concept для службы связи между правительственными учреждениями и общественностью (в настоящее время сужена до сектора здравоохранения).Заказчик специально запросил в основном серверный подход с помощью сервисов AWS, и мне нужен совет по настройке этой архитектуры, а именно, отношения Lambda к базе данных.

Грубо говоря, архитектура будет использовать API-шлюз для обработки запросов, которые будут вызывать разные Lambdas, как микро-сервисы, которые обращаются к БД.

На следующем рисунке показана схема быстрых отношений.По сути, пациент вводит описание своего состояния, которое составляет основу для случая.Это дело обрабатывается во время одной или нескольких сессий одной или несколькими медсестрами, которые принимают примечания, связанные с делом. Схема БД (недостаточно репутации)

Из моего исследования я понял, что в случае с RDS существует компромисс между безопасностью (сохранение Lambdas вне публичного доступа).VPC, содержащий экземпляр RDS, предшествующие рекомендации по безопасности, запрет на использование в государственном секторе) и производительность (помещение Lambda в частный VPC с экземпляром RDS и тяжелые времена холодного запуска из-за предоставления ENI).Однако время холодного запуска можно свести на нет с помощью проверки связи с CloudWatch, что может быть или не быть оптимальным.

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

Такое ощущение, что SQL / RDS является более подходящим с точки зрения данных / отношений, но DynamoDB создает меньше проблем для сервисов Lambda / AWS, если найдена подходящая модель данных.Поэтому мой вопрос заключается в том, было бы предпочтительнее использовать частный экземпляр RDS и попытаться свести на нет «холодный старт», прогревая наиболее важные Lambdas, или существует модель NoSQL, которая не вызывала бы головные боли для сложных запросов, среди прочеговещи?Я упускаю какие-либо ключевые аспекты, которые могут перевесить шкалу?

Answer 1

Давайте начнем с выяснения некоторых довольно радикальных заблуждений с вашей стороны:

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

1. RDS - сервер базы данных.Вы ничего не запускаете ни внутри, ни снаружи.
2. Возможно, вы думаете о VPC или виртуальном частном облаке.Это изолированная сеть, в которой вы можете запускать экземпляры RDS и Lambdas.
3. Работа внутри или вне VPC не влияет на время холодного запуска.Вы платите штраф за холодный запуск, когда AWS должен запустить новый контейнер для запуска Lambda.Это может произойти либо потому, что он не был запущен в последнее время, либо потому, что его необходимо масштабировать для удовлетворения одновременных запросов.Фактическое время холодного запуска будет зависеть от вашего языка: например, Java значительно медленнее, чем Python, потому что ему нужно запустить JVM и загрузить классы, прежде чем что-либо делать.

Теперь для вашего реального вопроса

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

Этот может быть реализован в базе данных NoSQL, такой как DynamoDB.Без дополнительной информации я бы, вероятно, сделал бы Session базовым документом, используя идентификатор случая в качестве ключа раздела и идентификатор сеанса в качестве ключа сортировки.Если вы не понимаете, что означают эти термины, и как вы будете структурировать документ, основанный на этом ключе, то вам, вероятно, не стоит использовать DynamoDB.

Более веская причина, чтобы не использоватьDynamoDB имеет отношение к шаблонам доступа.Вы когда-нибудь захотите найти все дела, которые выполняла данная медсестра?Или связаны с данным пациентом?Эти типы запросов предназначены для реляционных баз данных.

В случае DynamoDB я лично очень неопытен (больше, чем в MySQL)

есть кто-нибудь в вашей команде, кто знаком с базами данных NoSQL?Если нет, то я думаю, что вы должны придерживаться MySQL.У вас будет достаточно проблем, чтобы научиться использовать лямбду.