Обсуждали ли вы с вашим AWS Solutions Architect пример использования?Им нравятся такие вещи, они будут рады помочь вам определить правильную архитектуру.Это может хорошо подойти для Сервисов IoT AWS ?
Если вы не используете управляемые сервисы IoT, вам нужно отправить сообщения в масштабируемую очередь, такую как Kafkaили Kinesis (IMO, если вы обрабатываете 18M * 5 датчиков = 90M событий в день, это> 1000 событий в секунду. Кафка здесь не излишняя; многие другие стеки будут under-kill ).
Из Kinesis вы затем перемещаете данные в более быстрый стек для аналитики / запросов, таких как HBase, Cassandra, Druid или ElasticSearch, в зависимости от предпочтений вашей команды.Кто-то скажет, что это данные временных рядов, поэтому вам следует использовать базу данных временных рядов , такую как InfluxDB;но опять же, решать вам.Просто убедитесь, что это база данных, которая работает хорошо (и ведет себя сама!) При постоянной загрузке 1000 записей в секунду.Я бы не советовал использовать для этого СУБД, даже Postgres.Все упомянутые выше должны справиться с этим.
Кроме того, не забудьте передать ваши сообщения из Kinesis на S3 для безопасного хранения, даже если вы не намерены хранить сообщения вечно (просто установите жизненный циклправило, чтобы удалить старые данные из корзины, если это так).В конце концов, это большие данные, и правило: « все ломается, все время ».Если ваш аналитический стек выходит из строя, вы, вероятно, не хотите полностью потерять данные.
Что касается оповещений, это зависит от того, 1) какой стек вы выбрали для аналитической части, и 2) какие виды триггеров вы хотитеиспользовать.Из вашего описания, я полагаю, вы скоро захотите создать более продвинутые триггеры, такие как модели машинного обучения для обнаружения аномалий, и для этого вам может потребоваться что-то, что не опрашивает аналитический стек, а скорее прямо потребляет события.Кинезис.