Как эффективно разделить разделы DynamoDB?

Question

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

Допустим, у моего предмета есть несколько полей, и три из них organizationId, createdTime and itemType. Мы пытаемся выполнить нумерацию страниц и хотим получить элементы в порядке убывания созданного времени.

The GSI we had was organizationId (hash) and createdTime (range) (очень плохо). Причина, по которой мы выбрали это, потому что это единственный способ получить элементы в отсортированном порядке для всей организации. Позже мы начали добавлять itemType к organizationId, который затем стал хэш-ключом organizationId-itemType. Но эти itemTypes похожи на несколько из них, поэтому мы все еще сталкиваемся с проблемами регулирования.

Я хочу сделать это представление эффективным. Если мы разделим записи на, скажем, случайные разделы 10/20/50, сбор всех данных и их сортировка в отсортированном порядке - это слишком большая операция и отнимает много времени. Я знаю худшее.

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

Ваши идеи / предложения действительно помогут нам решить этот огромный сценарий использования.

Answer 1

Вы можете просто назначить уникальный идентификатор / хэш для каждой записи и создать таблицу только для хеша в uniqid.

Затем добавьте столько индексов GSI, сколько необходимо.
Например: OrganisationID + создал время

В большинстве случаев наилучшим вариантом является наличие индекса GSI с прогнозируемыми атрибутами = ТОЛЬКО KEYS, поскольку он небольшой и быстрый и может извлекать тысячи элементов за один запрос. Кроме того, чтение таблиц обходится дешевле, даже в 10 раз дешевле в случае несогласованных операций чтения, в то время как индексы не только KEYS ONLY также обновляют GSI, что требует затрат на запись.

Идеальный чехол только для ключей:
Отображение данных с разбивкой на страницы, для каждого куска 50/100 элементов выполните пакетное получение элементов.

Кроме того, вместо создания другого индекса для itemType, вы можете использовать filterExpression, чтобы выбрать только требуемые itemTypes и выполнять столько запросов, пока не получите нужное количество записей для возврата, а затем обогатите свои данные пакетным чтением