Aws Лямбда — Dynamodb Против Rds Для Хранилища Счетчиков?

У меня есть несколько лямбда-функций, через которые файл проходит для обработки, и я хочу сохранять статус каждого вычисления в счетчике для лучшего протоколирования и мониторинга.

Текущий план — зарегистрировать это следующим образом:

 Done 

И я буду обновлять значения как In-process , Received и file-name Lambda1 Lambda2 Lambda3 Name1 Done Done In-process under the respective Lambda functions for the file.

Итак, два сомнения:

1. Это хорошая практика? Если нет, то есть ли лучшая альтернатива тому же самому?
2. Если да, то что могло бы сделать магазин лучше/дешевле? RDS или DynamoDB?

#aws-lambda #amazon-rds #базы данных

Почему не что-то вроде Redis? (можно использовать через ElastiCache). Трудно ответить на этот вопрос, не зная эксплуатационных требований этого проекта. Эти данные предназначены исключительно для регистрации/исследований или они оперативны (т. е. к этой «таблице» обращаются, чтобы узнать, какую лямбду вызывать).

Динамо против RDS — зависит от того, насколько резкий у вас трафик. Dynamo очень масштабируема и обеспечит вам гарантированную пропускную способность. Но если ваш трафик может вырасти в 10 раз в течение нескольких часов (резко), Dynamo может оказаться слишком дорогим, поскольку вам потребуется обеспечить максимальную пропускную способность, иначе вы будете ограничены.

RDS по сути представляет собой управляемую СУБД для выбранного вами типа экземпляра, поэтому она может обрабатывать более крупные всплески, но в конечном итоге не так масштабируема, как Dynamo.

Опять же, я бы выбрал Redis из-за его простоты (кажется, вам просто нужно хранилище KV/счетчиков) и невероятной скорости/эффективности. Если это просто для ведения журнала, то, вероятно, этого достаточно.

По вопросу №1)

Я думаю, что на этот вопрос лучше ответить на SoftwareEngineering SE.

Тем не менее, я рискну ответить: для такого рода информации (состояний), поступающей из такой архитектуры (распределенной), я рекомендую источник событий. Это устраняет сложности и многие головные боли, связанные с природой распределенных систем, если кто-то попытается использовать традиционные парадигмы баз данных.

По вопросу №2: оба будут работать. Чтобы узнать, что лучше и дешевле, нам нужно больше узнать о вашем сценарии использования.

Стоимость будет зависеть от количества сообщений, которые вы пишете в секунду. Чаще всего DDB дешевле. Если у вас большая пропускная способность, 10 000 запросов в секунду, необходимо тщательно оценить затраты на DDB по сравнению с RDS.

Однако в этом случае я бы рекомендовал использовать S3 для вывода сообщений журнала в файл. Я думаю, что технически это будет достаточно хорошее решение, стоимость установки и обслуживания которого будет значительно ниже, чем у DDB или RDS.