AWS: Как сохранить потоковые данные в базе данных, размещенной на EC2 (например, MySQL / MongoDB)

Question

Мы можем легко сохранять данные между различными AWS Сервисами, например. Кинезис в ДинамоДБ; или AWS IoT для Redshift et c.

Но какова лучшая стратегия сохранения потоковых данных для предположения, что MongoDB (который НЕ имеет AWS PaaS; Атлас есть, но не имеет интеграции с другими AWS Сервисами)

I можно увидеть некоторые сторонние решения есть; но какую стратегию лучше реализовать на самом AWS ... Является ли выполнение лямбда-функции для каждой вставки (пакетной обработки) единственной возможностью?

Answer 1

Я предполагаю, что вы используете Kinesis Firehose. Если это так, то вы можете сделать следующее:

• Из Firehose пишите в S3 каждые 5 минут.

• Firehose будет создавать новый файл на S3 каждые 5 минут.

• Запуск лямбда-функции для чтения нового файла на S3.

• Запись данных нового файла в MongoDB.

Если вы используете Kinesis (не пожарный шланг), вы можете просто написать потребителя Kinesis, который будет читать данные из Kinesis и записывать напрямую yo MongoDB.

FYI, есть DocumentDB с MongoDB как API, вы можете использовать его как AWS Hosted MongoDB

Answer 2

Вы можете вызывать лямбда-функцию при каждом вызове FireHose. И эту лямбду можно вставить в mongodb на EC2. Вы можете выполнять пакетные операции, чтобы уменьшить количество лямбда-вызовов (и, в свою очередь, уменьшить стоимость)

Answer 3

Решение зависит в основном от вашего варианта использования. Как быстро вам нужно вставить данные в MongoDB?

, если вам нужно решение, близкое к реальному времени, тогда Kinesis и Lambdas - ваш лучший вариант (если вы не хотите вкладывать средства в сторонние продукты) , Если вы можете позволить себе задержку и выполнить пакетную обработку, то вы можете сохранить поток кинезиса в S3 и затем использовать AWS Glue для обработки и загрузки ваших данных в базу данных.

То, что вам нужно думать, это в основном то, что вам нужно делать с данными.

Если вы собираете данные датчика, где вас интересуют только агрегаты (например, щелчки в пользовательском интерфейсе), то лучше сохранить исходные данные в s3 и затем выполнить конвейер данных (используя AWS Клей например) для хранения агрегированных данных в MongoDB. S3 будет быстрее и дешевле для этих типов данных.

Если вы используете поток для передачи бизнес-сущностей (например, документов, которые представляют ценность самостоятельно), то лучшим решением будет решение, близкое к реальному времени, с использованием AWS lambda.

Не зная точного варианта использования, я бы предложил хранить в вашей базе данных только те данные, которые обеспечивают ценность (например, отчеты по агрегированным данным), и использовать S3 с политикой жизненного цикла для необработанных данных «датчиков».