Постоянно обновляемая база данных, совместно используемая несколькими экземплярами AWS EC2

Question

Для небольшого личного проекта я собирал некоторые данные каждые 5 минут и сохранял их в базе данных SQL.До сих пор я использовал крошечный экземпляр EC2 AWS в сочетании с хранилищем EBS объемом 100 ГБ.Это отлично работает для очистки, но становится непригодным для анализа результирующих данных, так как экземпляру EC2 не хватает памяти.

Анализ данных происходит нерегулярно, поэтому платить 24 часа в сутки за более крупный экземпляр EC2 было бы напрасно, поэтому я ищу что-то более гибкое.Из прочтения я узнал:

• Вы не можете подключить EBS к двум экземплярам EC2 одновременно, так что раскручивать второй временный большой экземпляр всякий раз, когда требуется анализ, не вариант.
• AWS EFS кажется решением, но намного дороже, и, учитывая мои ограниченные знания, я не уверен на 100%, что это идеальное решение.
• Бессерверные опции, такие как Amazon Athena, выглядят великолепно, но они основаны на S3, который не предназначен для данных, требующих постоянного обновления (?).

Я предполагаю, что это довольно распространенный вариант использования AWS, поэтому я надеюсь попытаться получить несколько указателей в правильном направлении.Есть варианты, которые я пропускаю, которые соответствуют моей проблеме?EFS - правильный путь?

Спасибо!

Answer 1

Ваши рабочие по очистке должны хранить данные в Amazon S3. Таким образом, рабочие экземпляры можно масштабировать (и даже отключать), не беспокоясь о хранении данных.Храните данные процесса (например, что было очищено, где очистить дальше) в базе данных, такой как DynamoDB.

Когда вам нужно запросить данные, сохраненные в Amazon S3, Amazon Athena идеально подходит, еслихранится в читаемом формате (CSV, ORC и т. д.).

Однако, если вам нужно прочитать неструктурированные данные, ваше приложение может получить прямой доступ к файлам S3 , загрузив ииспользуя их или читая их как потоки.Для этого типа обработки вы можете запустить большой экземпляр EC2 с большим количеством ресурсов, а затем отключить его, когда он не используется.А еще лучше, запустите его как Spot экземпляр , чтобы сэкономить деньги.(Это означает, что ваша система должна справиться с возможностью остановки на полпути.)

Answer 2

Ответы предыдущих пользователей отличные.Давайте разберем их в настройках.Мне кажется, что ваш начальный стек - это база данных SQL, которую вы установили в EC2.

Вариант 1 - Реплики чтения RDS

Переместите вашу БД в RDS, это даст вам много положительных моментов, но основной из них, который мы ищем, - это чтение реплик, если ваше чтение / с возрастаетВы можете создать дополнительные реплики чтения и поместить их за балансировщиком нагрузки.Эта настройка - самый низкий результат без слишком большого количества изменений кода.

Вариант 2 - EFS для обмена данными между экземплярами EC2

Использование EFS не является простым делом, ни в чем не виноват EFS.Некоторые базы данных сохраняют уникальные идентификаторы в файловой системе, что означает, что вы не можете использовать жесткий диск.EFS - это сервис, который добавляет некоторое отставание к каждой операции чтения / записи.В зависимости от того, как установлен дистрибутив базы данных, это может быть даже невозможно.

Вариант 3 - Athena и S3

Можно также сохранить рабочие файлы на S3 вместо SQL, но это означает переписываниеинструмент для соскоба.Вы можете вызвать S3 -> PutObject для одного и того же ключа несколько раз, и он заменит предыдущий объект.Затем вам нужно будет переписать свой аналитический инструмент для запроса S3.Этот вариант превосходен, и он, вероятно, самый дешевый по «стоимости эксплуатации», но это означает, что вы должны быть знакомы с S3 и, что более важно, с Athena.Вам также необходимо выяснить, как вы будете сохранять новые данные и какой формат файла подходит для вашего приложения.Вы можете начать с обычных BLOB-объектов JSON или CSV, а затем перейти к Apache Parquet для более низкой стоимости.(Для получения дополнительной информации о том, как этот оператор означает экономию, см. Здесь: https://aws.amazon.com/athena/pricing/)

Вариант 4 - RedShift

RedShift для BigData, я бы подождал, пока запрос обычного SQL не станет проблемой (несколько секундза запрос), а затем я бы начал изучать его. Конечно, это позволит вам делать очень дешевые запросы, но вам, вероятно, придется настроить конвейер, который слушает SQL (или запускается им), а затем обновляет RedShift. Причинапотому что RedShift масштабируется в зависимости от ваших запросов, и вы можете легко раскрутить несколько машин, чтобы сделать запросы быстрее.

Answer 3

1. Насколько я вижу, S3 и Афина - хороший вариант для этого.Я не уверен, что вы заинтересованы в том, чтобы НЕ использовать S3, но как только вы сможете сохранить очищенные данные в S3 и проанализировать их с помощью Athena (модель с оплатой за запрос).

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

Кроме того, вы можете использовать Kenisis Firehose, который можно использовать для анализа данных в режиме реального времени каки когда вы глотаете их.