Как обрабатывать потоковые данные AWS IOT в реляционной базе данных

Question

Общая информация : -я разрабатываю решение для одного из проблемных подходов IOT, в которых данные непрерывно передаются из plc (программируемый логический контроллер), plc имеют разные теги, эти теги представляют собой представление данных и данных телеметрии из этих тегов будет происходить непрерывная потоковая передача, каждое из устройств будет иметь теги тревоги, которые будут 0 или 1, 1 означает, что произошел сбой оборудования постановка задачи : - мне нужно прочитать тег тревоги и поднять тикет, если любое из значений тега тревоги равно 1, и мне нужно передать эти оповещения на панель инструментов, а также я должен сохранить историю заявок, поэтому оператор также может обновить статус заявки

Мое решение : - я использую aws IOT, я получаю данные в Dynamo DB, затем я использую Dynamo DB, чтобы проверить, добавлен ли какой-либо новый элемент в таблицу аварийных сигналов и будет ли он запускать лямбду функция (которую я реализовал в Java) лямбда-функция открывает новый тикет в реляционной базе данных, используя hibernate.

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

пожалуйста, дайте мне знать, могу ли я принять другой хороший дизайн?

Answer 1

Вы можете контролировать количество параллельных функций лямбда-функции. И это уменьшит количество лямбд, которые раскручиваются на основе событий динамо. Тем самым сокращается количество подключений к RDS.

https://aws.amazon.com/blogs/compute/managing-aws-lambda-function-concurrency/

Конечно, это душит события динамо.

Answer 2

Просто предложение ....

Из лямбды, не связывайся с RDS,

Скорее нажмите все аварийные сигналы в AWS SQS

тогда вы можете назначать друг другу лямбду на каждую минуту, используя AWS CloudWatch Rules, которые будут выбирать все элементы из AWS SQS и затем вставлять их в RDS сразу.

Answer 3

Я согласен с тем, что raevilman не разрешает Lambda напрямую связываться с RDS. Поскольку создание нового тикета - не единственная задача, которую выполняет функция Lambda, вы также направляете эти оповещения на панель инструментов. В зависимости от скорости потоковой передачи и ограничений RDS может потребоваться разбить эти задачи на несколько очередей.

Общее решение: я бы посоветовал вам перевести сигнал тревоги в режим разветвления, и этот обмен, в свою очередь, переместит сигнал тревоги в одну или несколько очередей по мере необходимости. Затем вы можете пакетировать сигналы тревоги и выполнять несколько записей одновременно, не выполняя цикл подключения / отключения несколько раз.

Специальное решение AWS: я не использовал SQS, поэтому не могу прокомментировать его архитектуру. Кроме того, вы можете создать тему SNS и опубликовать эти сообщения в этой теме. Затем вы можете иметь очереди SQS в качестве подписчиков на эту тему, которые, в свою очередь, будут использоваться для целей создания билетов и панели мониторинга независимо друг от друга.

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

Answer 4

ИСПОЛЬЗУЙТЕ Amazon Kinesis Analytics для обработки потоковых данных. Динамодб не подходит для этого.

Подробнее здесь

Ниже изображение даст вам представление о том же