#amazon-web-services #amazon-dynamodb
#amazon-web-services #amazon-dynamodb
Вопрос:
Я хочу создать веб-интерфейс DynamoDB. Это позволяет создавать и читать сообщения. Теперь я хотел бы реализовать счетчик кликов, который обновляет популярность публикации каждый раз, когда пользователь запрашивает ее. По этой причине каждый раз, когда поступает запрос GET для сообщений, я бы изменил сам объект Post.
Но я знаю, что DynamoDB оптимизирован для чтения, а не для записи. Поэтому обновление объекта, который извлекается каждый раз, вероятно, будет проблемой. Итак, как я могу измерить популярность сообщений, не замедляя работу самого API? Я думал о том, чтобы генерировать случайное число для каждой выборки и обновлять его только в том случае, если оно ниже 0,05 или что-то подобное. Но есть ли лучшее решение для этого?
Комментарии:
1. Я думаю, что для реализации службы подсчета просмотров можно использовать другую службу. Информация о счетчике не обязательно должна храниться в той же базе данных, что и сами данные. Например, для хранения данных счетчика можно использовать решение для реляционной базы данных. Если использование DynamoDB является обязательным требованием, альтернативным решением может быть запуск обновления количества просмотров асинхронно после возврата запрошенного сообщения.
2. Разве реляционные базы данных не медленнее, чем DynamoDB?
3. Может быть медленнее, в зависимости от варианта использования и управления параллелизмом. Однако я хотел сказать, что управление счетчиками количества посещений должно выполняться отдельной службой, предпочтительно поддерживаемой отдельным решением для хранения данных, обновляемым асинхронно.
4. хорошо, это имеет смысл. Но почему я должен использовать отдельное решение для хранения? Почему бы просто не создать еще одну таблицу в DynamoDB?
5. Под отдельным решением для хранения я подразумевал объект / запись, которая отделена от исходной сохраненной сущности / записи. Таким образом, отдельная таблица также должна работать. Разделение требуется, чтобы не блокировать запросы на чтение записей запросами на запись с помощью количества обращений. Извините, это был неудачный выбор слов с моей стороны.
Ответ №1:
Dynamo DB не «оптимизирована для чтения», она оптимизирована для обеспечения «согласованного времени отклика в миллисекундах с одной цифрой в любом масштабе».
Чтобы оптимизировать DDB для чтения, вы должны поместить перед ним экземпляр ускорителя Amazon DynamoDB (DAX) для «более быстрого доступа с задержкой в микросекунду».
На самом деле производительность чтения / записи DDB не будет проблемой. В вашем случае задержка в сети между вашим приложением и DDB будет на порядок выше. Выполняя два вызова синхронно один за другим, вы удвоите время отклика; независимо от того, какую облачную базу данных вы тоже пишете.
Предполагая, что данные и счетчик находятся в одной и той же записи, простым решением DDB в этом случае было бы не совершать вызов GetItem() и один к UpdateItem() . Вместо этого просто вызовите UpdateItem() an UpdateExpression , который использует ADD выражение для добавления 1 к вашему счетчику и ReturnValues атрибут для возврата либо ALL_OLD или ALL_NEW .
Другие более сложные решения
- предполагая, что у вас уже есть данные для отображения, выполните асинхронный вызов updateItem() .
- При масштабировании вы можете рассмотреть возможность отключения обновления счетчика от вашего приложения. Ваше приложение отправляет сообщение SQS, которое обрабатывается лямбдой, которая может использовать пакетные обновления для DDB.
Комментарии:
1. под приложением вы подразумеваете внутренний лямбда-код или js-код веб-сайта?