Дает ли перегрузка DynamoDB GSI преимущества в производительности или просто гибкость - PullRequest
Новая
       15

Дает ли перегрузка DynamoDB GSI преимущества в производительности или просто гибкость

0 голосов
/ 13 марта 2019

Предоставляет ли GSI Overloading какие-либо преимущества в производительности, например, позволяя более эффективно маршрутизировать кэшированные ключи разделов?Или это в основном о том, чтобы не дать вам закончиться GSI?Или, может быть, открытие других шаблонов запросов, которые могут быть не столь очевидны сразу.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-gsi-overloading.html

например, если у вас есть базовая таблица, и вы хотите разделить ее, чтобы можно было запросить определенный атрибут(который становится PK GSI) в двух измерениях, имеет ли какое-либо значение, если вы создаете 1 перегруженный GSI или 2 незагруженных GSI.

Пример того, что я имею в виду, чтобы увидетьПрикрепленное изображение:

https://drive.google.com/file/d/1fsI50oUOFIx-CFp7zcYMij7KQc5hJGIa/view?usp=sharing

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

  1. Опубликованные документы по дате
  2. Черновики документов по дате

Я спрашиваю в отношениив соответствии с более поздней передовой практикой DynamoDB, которая подразумевает, что для всех приложений требуется только таблица one.Некоторые из методов, показанных в этой документации, показывают, как достаточно сложная реляционная модель может быть сведена в 1 таблицу DynamoDB и 2 GSI, и при этом все еще поддерживает 10-15 шаблонов запросов.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-relational-modeling.html

Я пытаюсь понять, почему кто-то пошел по этому пути, поскольку он кажется невероятно сложным.

1 Ответ

1 голос
/ 13 марта 2019

Идея, в двух словах, состоит в том, чтобы не создавать накладных расходов на выполнение объединений на уровне базы данных или возвращаться к базе данных, чтобы эффективно попытаться выполнить объединение на уровне приложений. Имея данные, нарезанные уже в формате, который требуется вашему приложению, все, что вам действительно нужно сделать, это в основном сделать один вызов select * from table where x = y, который возвращает несколько объектов за один вызов (в вашем примере это могут быть Users и Documents) , Это означает, что он будет чрезвычайно эффективным и масштабируемым на уровне БД. Но это также означает, что вы будете менее гибкими, поскольку вам нужно заранее знать шаблоны доступа и соответствующим образом моделировать свои данные.

См. Превосходную речь Рика Хулихана об этом https://www.youtube.com/watch?v=HaEPXoXVf2k, почему вы хотите это сделать.

...