Запрос последнего элемента и правильное использование ключей раздела в DynamoDB - PullRequest
Новая
       15

Запрос последнего элемента и правильное использование ключей раздела в DynamoDB

0 голосов
/ 04 мая 2018

Я создаю таблицу DynamoDB для поддержки Alexa Skill для использования в качестве игрока подкаста. Я предполагаю, что таблица будет использовать номер эпизода в качестве ключа раздела и PublicationDate в качестве необязательного ключа сортировки. У меня есть две проблемы по поводу разработки схемы таблицы таким образом.

Во-первых, скажем, я хотел запросить таблицу, чтобы получить последний эпизод - я не уверен, что могу сделать это таким образом, так как запрос требует операции эквивалентности на ключе раздела (episode = X), который Я бы не знал заранее. Правильно ли я считаю, что сканирование будет довольно дорогой операцией, если подкаст имеет большое количество эпизодов (скажем, более 1000)?

Мне нужно посмотреть на каждый элемент в таблице, сравнить его номер эпизода (значение ключа раздела) с предыдущим возвращенным элементом и обновить переменную с более новым элементом каждый раз, когда он был найден, пока все элементы в таблице не будут циклически таким образом.

Во-вторых, лучшие практики DynamoDB говорят о двух вещах, которые работают неконгруэнтно в моем случае использования (вероятно, признак того, что мой дизайн имеет недостатки). Во-первых, ключ раздела должен быть уникальным или близким к уникальному. Во-вторых, следует ожидать, что запросы будут более или менее равномерно распределены по ключам. Однако в моем случае, хотя ключ раздела действительно был бы уникальным, я ожидал, что подавляющее большинство запросов будет нацелено на последний ключ раздела в таблице для элемента, содержащего данные для последнего эпизода подкаста. Какое влияние это окажет на производительность, если, например, навык получает 1000 запросов в любой день, все они направлены на один и тот же ключ раздела?

Кто-нибудь имеет лучшее решение для архитектуры таблиц для этого типа данных?

Спасибо всем заранее!

1 Ответ

0 голосов
/ 08 мая 2018

Вопрос 1:

Сначала, скажем, я хотел запросить таблицу, чтобы получить последний эпизод - я не уверен, что я могу сделать это таким образом, так как запрос требует операция эквивалентности на ключе раздела (эпизод = X), который я не знал бы заранее. Правильно ли я считаю, что сканирование быть довольно дорогой операцией, если подкаст имеет большое количество эпизоды (скажем, более 1000)?

Вы правы, что НЕ сможете запросить последний эпизод, потому что каждый эпизод находится в своем собственном разделе. Разделы почти как разные изолированные таблицы, поэтому нет возможности запрашивать данные во всех разделах без сканирования (как вы сказали).

Вопрос 2:

Во-вторых, лучшие практики DynamoDB говорят о двух вещах, которые работают неуместно в моем случае использования (вероятно, признак того, что мой дизайн недостатки). Во-первых, ключ раздела должен быть уникальным или близким к уникальному. Во-вторых, следует ожидать, что запросы будут более или менее единообразными. рассеяны среди ключей. В моем случае, хотя, пока раздел Ключ действительно будет уникальным, я ожидаю, что подавляющее большинство запросы для таргетинга на последний ключ раздела в таблице, для Элемент, содержащий данные для последнего эпизода подкаста. Что будет влияние на производительность, если, например, навык получает 1000 запросов в любой день все нацелены на один ключ раздела?

Проблема здесь двоякая: AWS ожидает, что вы будете читать (и писать) одинаково для каждого раздела (или почти одинаково), поэтому в основном то, что произойдет, это то, что вы будете платить за единицы записи (и единицы чтения) ) на разделах, которые вы НЕ используете, даже если вы их не используете.

Точно, сколько еще будет выполняться, будет зависеть от того, сколько раз вы ЗАПРОСИТЕ базу данных, однако, Чтение намного дешевле, чем запись и 1000 операций чтения - это, по сути, ничто на столе с 1000 элементами. то есть. Вы МОЖЕТЕ иметь возможность сойти с рук, но это не идеально.

Схема альтернативной таблицы / Схема ключей

  1. Какие еще запросы вы будете делать? то есть. кроме «Проверить последний эпизод»
  2. Сколько подкастов добавляется в день? неделю? год
  3. Существует ли несколько «шоу» или категорий, которые можно использовать для ключей разделов, которые могут иметь более равномерное распределение и могут быть «известны»?
...