mayton2019

В S3 можно фолдеры создавть. Как часть ключа-пути.

s3://bucket/Bolage/file1.txt
s3://bucket/mayton2019/file1.txt

Фреймворк Apache Spark судя по документации умеет работать с zstd.

https://spark.apache.org/docs/latest/configuration.html

Я имею в виду что он может извлекать сведентья из архива не распаковывая.
Но если выбирать между форматами то я-бы посоветовал перепаковать в bzip2.
Он судя по документации - splittable, тоесть несколько Workers смогут работать
с архивом одновременно и независимо и таким образом ваш парсер будет быстрее в разы.

Тебе нужно проанализировать статистику по негативным ответам проверки прокси.
Если большая часть ответов - это socket timeout - то сделай таймаут не 5 секунд а 0.5 секунды.

Нужно откатить на предыдущий билд и дать возможность сайту работать.
А после этого - в спокойной обставновке смотреть что менялось и что привело к инцеденту.

Значит сразу скажу что у меня для вас - плохие новости. DynamoDb как и многие ему подобные облачные key-value решения расчитаны на выборку по сету ключевых полей. Обычно это хеш-ключ и ключ диапазона. В этом случае вы платите немного. Если вдруг вы решили выбирать по не-ключевым полям это уже будет другое тип запроса. Называется scan. Его можно писать на любом языке разработки но суть в том что будет выбрана ВСЯ таблица. Если она большая - то charge за текущий период вас неприятно удивит. Фиксить это почти невозможно. Это неправильный дизайн и неправильное использование AWS Dynamo. Вам следует вообще отказаться от использования Dynamo и думать над тем как НЕ делать сканов в будущем. Можете теоретически создать индекс по хвосту от строки. Но индекс с точки зрения Динамо - это копия таблицы просто по другому расположенная и реплицируемая. Вобщем не советую тоже.

Непотятно какой это язык? Go что-ли? Тут ошибка не про работу с AWS S3 bucket а просто про то что сериализация структуры params почему-то на выходе выдала НЕ-Xml строку. А ожидалась Xml.

Вот тут пишут как структуры сливать в XML

https://www.golangprograms.com/golang-write-struct...

Непонятно зачем автору здесь grafana и prometheus. Выглядит ненужным обвесом. Кроме того требует полноценного и дорогого EC2 на фоне всего остального которое почти serverless.

Правильно сказано про миллион.

Но смущает 1) Хеш тег Node.JS. Этот фреймворк архитектурно был однопроцессным. Возможно тут автор решает задачу которая решается на самом деле по другому. 2) Непонятна "выделенная среда". Что это? Еще один процесс в текущей ОС? Еще процесс в контейнерах LXC/Docker? Процесс в виртуалке? Процесс в другой EC2 ?

Наиболее дешевый вариант масштабирования - это переписать REST-приложение vasya на AWS Lambda. Это не всегда архитектурно возможно ввиду ограничений на сеанс и объемы ресурсов. Но если получится - то можно запускать до 1000 экземпляров Васи в параллель.

Ни один архитектор наперед не скажет вам сколько вы заплатите за AWS услуги. Формула биллинга там - сложная и учитываем и транзакции и трафик и каллбеки (AWS-lambda) и ресурсы времени для инстансов. Поэтому единственные правильный путь - собрать работающий макет. Задеплоить его в AWS и понаблюдать под нагрузкой в течение месяца. Посмотреть какой пришел счет. И соотвествтенно экстраполировать на другие объемы.

Упирается в возможности Питона и AWS-Lambda. Насколько я помню там есть ограничения на память для лямбды и лимит на время для 1 сеанса хендлера. Но я думаю что можно решить эту задачу. Библиотеки сжатия должны быть потоковые. Тоесть без накопления результата в памяти. И степень сжатия надо поставить на store чтоб было максимально быстро.

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