Блог

У меня есть модель данных, состоящая из 8 типов сущностей, и мне нужно разработать модель NoSQL DynamoDB на основе некоторых шаблонов доступа. Шаблоны доступа не являются специфичными для сущности, поэтому я нахожусь в процессе их перевода, но большинство шаблонов доступа основаны на получении элементов по диапазону дат. Из предыдущих связанных вопросов люди обычно предполагают, что получение элемента как по идентификатору элемента (Ключ раздела), так и по диапазону дат (Ключ сортировки) является нормой, но в моем случае мне нужно получить все объекты по диапазону дат.

Это означало бы, что ключ раздела-это тип сущности, а ключ сортировки-диапазон дат. Прав ли я в этом утверждении?

Учитывая большой размер данных (>100 ГБ), я не уверен, что это правда.

Обновление: Список шаблонов доступа и пример данных

Шаблоны доступа до сих пор выглядят следующим образом:

 Get all transactions during a given date range
Get all transactions during a given date range for a given locationId
Get all transactions during a given date range for a given departmentId
Get all transactions during a given date range for a given categoryId
Get all transactions during a given date range for a given productId
Get all transactions during a given date range for a given transactionItemId
Get all transactions during a given date range for a given supplierId
Get all product on transactions during a given date range
 

И объект транзакции имеет следующие атрибуты (я включил только фрагмент, но всего 52 атрибута):

 identifier  
confirmationNumber **(contains date information)**
priceCurrency   
discount    
discountInvoiced    
price   
shippingAmount  
subtotal    
subtotalInclTax 
.
.
.
 

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

Реализация потребует большого дублирования данных с помощью глобальных вторичных индексов, а также проблем с горячими разделами. Общий подход может заключаться в том, чтобы иметь базовую таблицу с PK в качестве даты и меткой времени в качестве SK. Затем вы создаете глобальные вторичные индексы на основе идентификатора местоположения, идентификатора отдела и других категорий, по которым вы фильтруете. Это приведет к дублированию данных и, в зависимости от ваших категорий фильтров, горячим разделам.

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