Я работаю с DynamoDB приложением и имею вопрос о структуре таблицы и индекса. Объем данных, хранимых в таблице, будет большим, но я не могу знать, сколько это, и не могу предсказать, как они вырастут.
response:
id: uuidString
survey: surveyIdString
surveyLink: surveyLinkIdString
created: date-time
status: enumeration (open/closed/etc)
questionNumber: number of current question
questionAnswer1: answer1 any valid JSON here
questionAnswer2: answer2 any valid JSON here
...
questionAnswerN: answers number is variable and depednds on survey and current status
other: {here is JSON-like object}
Я создам новую таблицу. В этой таблице будут храниться ответы на опросы. Каждый ответ имеет атрибут uuid, и я сделаю его ключом раздела. Приятно - горячего раздела нет пока пиши ответы! Ключ поиска будет содержать имя атрибута, например, опрос, surveyLink, созданный, статус и т. Д. Теперь я могу легко получить доступ к статусу, прежде чем показывать следующий вопрос или показывать ранее отвеченное значение. Насколько хорошо.
А теперь мне нужно реализовать поиск для построения отчета. Я хочу получить все ответы, для какого-то опроса . Я мог бы создать глобальный вторичный индекс GSI-1, где ключом раздела является опрос, а ключом сортировки является id (строка uuid). Хотя это может сделать значение моего идентификатора опроса горячей клавишей - это плохо!
Как видно из документов https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-indexes-gsi-sharding.html, я мог бы сгенерировать некоторый суффикс хеш-функции и добавить его в первичный ключ конца идентификатора опроса,Или используйте случайное число вместо [0-N]. Но проблема в том, что это число N зависит от ItemsPerRCU и MaxRequiredIO https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-modeling-nosql-B.html,, но я не могу знать эти значения заранее!
Еще одна проблема, которую я вижу, это количество ответов в каждом опросе. Некоторые опросы могут иметь много, а другие мало. Ответы на один опрос могут быть очень маленькими, в то время как другие могут содержать более крупный объект, такой как текст или изображение. Означает ли это, что я должен принимать это во внимание при вычислении N?
Означает ли это, что мое приложение должно отслеживать хранилище ItemsPerRCU и MaxRequiredIO, и как только вычисленное N станет больше, чем текущее, N назначит новое большее значение? В этом случае мои старые записи будут записаны с ключом раздела, содержащим небольшие начальные номера суффиксов N диапазона, хотя для построения отчета мне нужно использовать весь диапазон N номеров!
Я полностью потерян здесь. Кто-нибудь может мне помочь построить правильную структуру GSI или уточнить, если я ошибаюсь? Должен ли я поддерживать вычисление и обновление числа N в моем приложении или мне нужно присвоить константу N один раз, прежде чем мое приложение будет запущено в производство, и не трогать его до его закрытия или перехода на новую базу данных?