Моделирование данных DynamoDB

Question

Имея java BitSet, представляющий пользовательский интерфейс, я хотел бы хранить в DynamoDB, чтобы использовать такие запросы, как «дать мне все BitSets от даты X до даты Y с конкретным ключом».

Мой первый подход состоял в том, чтобы использовать первичный ключ, представляющий то, что я действительно хочу сосчитать, например, действие: «пользователи-кто-платит». Тогда ключ диапазона - это дата и, наконец, у меня есть значение в двоичном атрибуте.

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

Answer 1

Раздел документации DynamoDB касается аналогичного варианта использования. См http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForGSI.html#GuidelinesForGSI.SparseIndexes

воспользоваться разреженными индексами

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

Вы можете использовать разреженный глобальный вторичный индекс, чтобы эффективно находить элементы таблицы, которые имеют необычный атрибут. Для этого вы воспользуетесь тем фактом, что элементы таблицы, которые не содержат атрибутов глобальных вторичных индексов, вообще не индексируются. Например, в таблице GameScores некоторые игроки могли заработать определенное достижение для игры - например, «Champ», но большинство игроков этого не сделали. Вместо того, чтобы сканировать всю таблицу GameScores для Champs, вы можете создать глобальный вторичный индекс с хэш-ключом Champ и ключ диапазона UserId. Это позволит легко найти все Champs, запросив индекс вместо сканирования таблицы.

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

Пример звучит очень похоже на ваш «пользователь-платный» вариант использования - разница только в том, что (замените «champ» на «платный пользователь»). Тем не менее, речь идет о ситуации, когда очень мало пользователей - чемпионы (и именно поэтому это нормально, когда «champ» как хэш-ключ - читайте больше о хороших хеш-ключах здесь - http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html). Это можно было бы исправить, сказав, что у вас есть (скажем) 100 хэш-ключей для шампанских - champ00, champ01, ..., champ99. Одно из значений можно выбрать случайным образом во время записи записи в DynamoDB.

Answer 2

Как насчет использования HashMap<String userId, Integer>? Хорошая вещь об этом:

1- Размер карты будет таким большим, каким он должен быть.
2- Вы можете рассчитывать больше 1. С BitSet вы можете делать только 0 или 1.
3- Карты поддерживаются DynamoDb изначально.

РЕДАКТИРОВАТЬ: Если вам не нужно считать более одного, загар использовать HashSet. Если userId находится в HashSet, это означает, что вы получили удар. Если это не в HashSet, то он не попал.