Первичный ключ DynamoDB

Question

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

WeekStartingOn STRING (represents the Monday of the week the transaction posted) 
    TransactionID STRING (UUID - unique) 
    VendorID   STRING (UUID - unique by vendor) 
    dccAmount  NUMBER 
    pointOfSaleTime STRING (Storing UNIX timestamp) 
    TerminalID  NUMBER (UUID) 

первичный ключ определение стола:

weekStartingON  PRIMARY PARTITION KEY 
TransactionID  PRIMARY SORT KEY 

Текущий GSI-х: vendorIDIndex

VendorID    PARITITON KEY 
pointOfSaleTime  SORT KEY 

Образец данных:

DynamoDb screenshot

Основной тип запроса:

For a vendor, show all the transactions in the past day, week, month, year, etc. 

Я считаю, что стоит за нынешней раскладке группировать все сделки на прошлой неделе смежно, а затем оттуда, выберите транзакции поставщика.
Я уверен, что этот дизайн неправильный. Использование weekStartingOn в качестве ключа раздела приведет к горячим клавишам, так как большинство поставщиков захотят посмотреть, например, все, начиная с weekStartingOn = 2016-12-05. Кроме того, сортировка по транзакцииID не имеет никакого смысла. я был бы более склонен иметь первичный ключ базовой таблицы, определенный в соответствии с vendorIDIndex, т.е.

VendorID   PARTITION KEY 
pointOfSaleTime SORT KEY 

Тем не менее, я до сих пор есть несколько проблем с этим дизайном. Некоторые из наших Продавцов намного больше, чем другие, и сделают распределение чтения/записи по разделам несбалансированным. Например, VendorA может иметь 500000 ежедневных транзакций, но VendorB может иметь только 10 ежедневных транзакций. Кроме того, я не совсем уверен, что комбинация VendorID и pointOfSaleTime гарантированно будет уникальной.

Или, чуть более сложным и требует работы для разработчиков:

1 - Randomise the VendorID by adding a suffix, i.e. -1 
2 - Depending on the number of suffixes, query the VendorID + Suffix, X amount of times 
3 - Merge the results 

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

Какой был бы лучший дизайн для этого?

Большое спасибо

Answer 1

В конце концов, я пошел с ключом раздела (первичный) из «TransactionID». Это глобально уникально и достигается 100% -ная пропускная способность записи. Недостатки:

1) LSI избыточен. Нет точки, имеющей ключ диапазона для UUID

2) Мы не запрашиваем непосредственно по транзакционному идентификатору, не зная VendorID. Итак, чтобы получить транзакцию Продавца из базовой таблицы, нам пришлось бы сканировать все транзакции для поиска всех транзакций для Продавца

3) Необходимо создать дополнительные GSI для запросов VendorID. Тем не менее, у нас есть узкие критерии запроса, поэтому не проблема

Answer 2

Я бы передал обновления этой таблице AWS ElasticSearch с использованием лямбда-функции для генерации требуемых агрегатов. Кроме того, похоже, что большинство ваших запросов имеют временные рамки, поэтому может стоить использовать шаблон дизайна .Имейте таблицу для каждого месяца данных и отрегулируйте пропускную способность для старых таблиц по мере того, как они становятся холодными. Вы ограничены 256 tables per account per region, поэтому, возможно, сохраните данные за год в DynamoDB и переместите остальные в более холодное хранилище (например, S3). Вы не потеряете возможность запросить ваши данные за 1 год, даже если вы сохраните их в S3, потому что теперь вы можете запросить ведра S3 с помощью SQL с помощью службы AWS Athena.