Нужно предложение: структура DynamoDB для новой модели, как говорит официальный документ

Question

В настоящее время в моей базе 3 коллекции.В основном, моя структура данных показана ниже.

xx: { 
   yy: { 
      zz: {
      }
   }
}

Где 'xx', 'yy', 'zz' - отдельные коллекции.и я сопоставил xx> yy >> zz , используя ключи.

xx: { 
     KEY: "123"
}

YY: { 
      xx_Key : "123",
      KEY : "456"
}

zz: { 
      yy_key: "456",
      KEY: "789"
}

---

1, вопрос в том, как я могу сделать эти 3 таблицы в одну таблицу,но нужно делать каждую операцию с каждым 'xx', 'yy', 'zz'.Так как DynamoDB позволяет только GSI на верхнем уровне.Итак, как я могу использовать операции CRUD для этих операций?

---

2, Другой подход заключается в сохранении данных как "один к одному" .Так что я могу получить XX, YY, ZZ в домене верхнего уровня, но увеличит ли это избыточность данных?По сути, измененные данные будут:

Entry1: { 
  XX: "123",
  YY:"456",
  ZZ: "789"
}

Entry2: { 
  XX: "123",
  YY:"456",
  ZZ: "790" //Change in value here. But same xx & yy repeated.
}

Итак, что же мне делать?

Answer 1

Другой подход заключается в сохранении данных как «один к одному».Так что я могу получить XX, YY, ZZ в домене верхнего уровня, но увеличит ли это избыточность данных?

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

С концепцией нормализации в NoSQL следует обращаться осторожно, поскольку JOIN в основном не поддерживаются, что приводит к увеличению задержки запросов.

Я нашел этот блог полезным при разработке таблицы DynamoDBсостав.Цитирую суть (которая фактически является заключением блога) блога здесь:

Не существует единого правила, подходящего для всех при выборе стратегии нормализации.Это особенно верно, если вы переносите приложение из реляционной базы данных.Многие из допущений, которые вы делаете для проектирования реляционной схемы, не применяются в базе данных NoSQL, такой как DynamoDB.

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