Дизайн разделов DynamoDB - PullRequest
Новая
       8

Дизайн разделов DynamoDB

0 голосов
/ 10 октября 2018

Я относительно новичок в DynamoDB, и мы разрабатываем графический интерфейс поиска в свободной форме для одного из наших приложений.Основное хранилище данных, которое мы используем, - это традиционная реляционная база данных, мы планируем использовать DynamoDB в качестве постоянного слоя «кэша» поверх базы данных только для поиска.

В нашем случае у нас есть 3 ключа для определенияпокупатель .

мы храним клиента как комбинацию из 3 идентификаторов, указанных ниже:

  1. billingAccountNumber + customerId
  2. billingAccountNumber + InstanceId
  3. customerId
  4. InstanceId

Каждый элемент в DynamoDB представляет собой событие, которое происходит с клиентом в определенное время.

Каков наилучший способ создания этого шаблона в DynamoDB.Запрос будет что-то вроде

  1. событий для определенного billingAccountNumber за период времени.
  2. событий для определенного customerId за период времени
  3. событий для определенного instanceId за периодtime.

и т. д.

В настоящее время я использую BillingAccountNumber в качестве ключа раздела, поскольку он будет равномерно распределять нагрузку и метку времени в качестве ключа сортировки, чтобы мы могли получитьрезультат для данного диапазона.

Я спорю о том, могу ли я использовать customerId или instanceId в качестве ключа сортировки и метку времени в качестве фильтра, чтобы я мог выполнить запрос с помощью filterExpression для метки времени.

Какой способ является более эффективным с точки зрения производительности и стоимости?

1 Ответ

0 голосов
/ 13 октября 2018

Я спорю о том, могу ли я использовать customerId или instanceId в качестве ключа сортировки и метку времени в качестве фильтра, чтобы я мог выполнить запрос с помощью filterExpression для метки времени.

Ключ сортировки о сортировке.У вашего customerId есть смысл сортировки?Я думаю, нет, в большинстве случаев они подходят для ключа раздела.То же самое для instanceId.

Вместо этого timestamp очень подходит для ключа сортировки.Я настоятельно рекомендую вам использовать его так.Это очень эффективно.

Использование timestamp в filterExpression не является хорошей идеей, потому что ваш запрос выполнит scan и затем применит фильтр.На огромном столе это именно то, что не нужно делать .

См. Предложения ниже.

Ключ вашего стола должен обеспечивать уникальность для каждого элемента.Если billingAccountNumber полностью идентифицирует строку, отлично.Если он не помещает что-то в ключ сортировки для обеспечения уникальности.

Для ответа на запросы вам нужны глобальные вторичные индексы (GSI):

  1. событий для определенного billingAccountNumber за периодвремени • PK: billingAccountNumber, SK: отметка времени
  2. события для определенного customerId за период времени • PK: customerId, SK: отметка времени
  3. события для определенного instanceId за период времени • PK: instanceId, SK: отметка времени

Используйте запрос типа: "#customerId =: customerId И # timestamp IS МЕЖДУ: ts0 AND: ts1" Играть с запросами.

...