Запрос DynamoDB на логический ключ

Я новичок в DynamoDB (и вообще в noSQL), и немного борюсь за то, чтобы окунуться в некоторые из концепций. Одна вещь, в частности, дает мне некоторые проблемы, связанные с запросом таблицы на основе логического ключа.

Я понимаю, что я не могу создать первичный или вторичный индекс для логического ключа, но я не вижу, как я должен идеально индексировать и запрашивать таблицу со следующей структурой:

reportId: string (uuid)
reportText: string
isActive: boolean
category: string

Я хотел бы иметь возможность выполнить следующие поисковые запросы:

  • Доступ к конкретному отчету напрямую (первичный хеш-индекс reportId)
  • Список отчетов определенной категории (первичный хеш-индекс на категория)

Это просто, но я хотел бы выполнить два других запроса:

  • Список всех отчетов, отмеченных как isActive = true
  • Список всех отчетов определенной категории, помеченных как isActive = true

Моим первым подходом было бы создать первичный индекс hashkey на isActive, с ключом range на category, но я могу выбрать String, Number of Boolean как тип ключа.

Сохранение isActive в виде строки (сохраняется как "истина", а не логическая истина) решает проблему, но ее ужасно использует строку для логического свойства.

Я что-то упустил? Есть ли простой способ запросить таблицу непосредственно по логическому значению?

Любые советы, должным образом оцененные.

Спасибо заранее.

Ответы

Ответ 1

Мой проект включает в себя этот конкретный сценарий, и я следил за лучшей практикой DynamoDB по использованию разреженных индексов по локальным и глобальным вторичным индексам. Вот что я сделал бы с вашим примером:

Table: reportId (string, hash key) || reportText (string) || isActive (string, marked as "x") || category (string)

ActiveReportsIndex (Local Secondary Index): reportID (hash key) || isActive (range key)

ActiveReportsByCategoryIndex (Global Secondary Index): category (hash key) || isActive (range key) || reportId

Идея разреженных индексов состоит в том, что в ваших индексах будут отображаться только сообщения, помеченные как isActive: "x", поэтому они должны требовать меньше хранения и обработки, чем ваша основная таблица. Вместо того, чтобы атрибут isActive представляет собой логический тип, который всегда будет хранить значение true или false, используйте строку типа "x" или что-то еще, что вы хотите, когда отчет активен, и DELETE атрибут полностью, когда отчет не активен. Имеет смысл?