Насколько эффективно использовать несколько глобальных индексов в одной таблице DynamoDB?

Выходит из набора данных, как описано в таблице ниже. Sr.no используется в таблице ниже только для справки.

|sr.no|    id    | tis |data-type|   b.id   |idType_2|  var_2 |     
|-----|----------|-----|---------|----------|--------|--------|
|  1  |abc-def-gi|12345|  a-type |1234567890| 843023 | NULL   |
|-----|----------|-----|---------|----------|--------|--------| 
|  2  |1234567890|12346|  b-type |    NULL  |  NULL  |40030230|
|-----|----------|-----|---------|----------|--------|--------|
|  3  |abc-def-gj|12347|  a-type |1234567890| 843023 |  NULL  |

Типы запросов

  1. Введите id и, если data-type a-type, верните поля tis,b.id,id_type2 ссылку sr.no=1
  2. Введите id и, если data-type равно b-type, верните поле var_2 ссылку sr.no=2
  3. Введите id_type2 поля возврата id,tis,b.id из sr.no=1,3
  4. Введите data-type, верните id на основе tis between 12345 and 12347

Примечание

  • sr.no=1,3 или a-type данных вставляется 100 тыс. Раз в день с уникальными id
  • sr.no=2 или b-type данных - это фиксированный набор данных.

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

Partition Key = id, чтобы позаботиться о запросе 1,2.

GSI1=id_type2 and GSI1SK=id для выполнения запроса 3

GSI2=data-type and GSI2SK=tis для выполнения запроса 4


amazon-web-services amazon-dynamodb amazon-dynamodb-index
person user2967920    schedule 05.02.2019    source источник
comment
Просто взглянув на предоставленную вами структуру данных и типы запросов, ваш подход кажется мне убедительным.   -  person namuny    schedule 05.02.2019
comment
Почему вы поместили два набора разных данных в одну таблицу?   -  person F_SO_K    schedule 05.02.2019
comment
@Stu следует шаблону noSQL, где для хранения данных используется одна таблица, также для вывода queryType4 требуются данные b.id с sk на отметках времени. b-тип производит данные, на которые ссылается a-тип   -  person user2967920    schedule 05.02.2019

Ответы (2)


arrow_upward
0
arrow_downward

Вот мои мысли:

1) если у вас есть данные с разными шаблонами доступа, вам следует рассмотреть возможность разделения данных на разные таблицы.

2) если данные доступны вместе, храните их вместе - это означает, что если всякий раз, когда вы читаете данные a-типа для некоторого смоделированного объекта, вам также необходимо прочитать одну или несколько записей b-типа для одного и того же объекта, это выгодно разместить все эти записи в одной таблице под одним и тем же ключом раздела

Чтобы привести все это домой, в вашем примере идентификатор для данных типа a и типа b отличается. Это означает, что вы получаете 0 преимуществ от хранения в одной таблице и типа a, и типа b. Используйте две разные таблицы.

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

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

person Mike Dinescu    schedule 05.02.2019
comment
Использовал этот docs.aws.amazon.com/amazondynamodb/latest/ developerguide / images / Причина, по которой типы a и b хранятся в одной таблице, заключалась в том, чтобы избежать создания двух таблиц для хранения данных, которые используются одними и теми же механизмами резервного копирования. Таким образом, механизм резервного копирования должен выполнить один запрос, чтобы получить все идентификаторы за день для выполнения запросов резервного копирования, данные которых находятся в отдельной таблице. данные типа b являются статическими, данные типа a - динамическими. Причина, по которой я не поместил данные типа b в сам тип a, заключалась в репликации статических данных. Так что, по вашему мнению, type-b принадлежит другой таблице? - person user2967920; 06.02.2019
comment
Если данные доступны вместе, они должны быть в одной таблице. Мне жаль, что говорить о type as и type bs - это немного абстрактно ... Кроме того, дело в том, что эти правила не являются абсолютными: есть много возможностей для компромиссов. - person Mike Dinescu; 06.02.2019

arrow_upward
0
arrow_downward

Это было решено с помощью следующей команды: DynamoDB без создания каких-либо GSI.

Когда создается GSI, все данные, записанные в основной таблице, копируются в таблицу GSI, поэтому WriteCost равна x Число GSI. Если у вас 1 GSI, это PrimaryWrite + GSIWrite, если у вас 2 GSI, то это Primary + GSI1 + GSI2. Кроме того, запись в GSI такая же, как и в первичном, поэтому, если вы подключаетесь к первичному серверу на 1000 WCU, то же самое будет применяться к GSI, так что всего будет 2000 WCU для 1GSI и 3000WCU для 2 GSI.

Что мы сделали

application_unique_id as hash key
timestamp as sort key

Остальные ключи хранились как атрибуты (DynamoDB поддерживает динамический JSON при наличии действующего хэш-ключа и ключа сортировки).

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

Мы сделали ежедневный индекс последних данных моментальных снимков, так как DynamoDB содержит все точки трассировки и является лучшим местом для их хранения и запросов.

Таким образом, мы знали, какие данные были отправлены в какой день (поскольку Dynamodb не позволяет пользователю экспортировать список хеш-ключей). А все остальные прогнозируемые и сравнительные запросы мы могли выполнять внутри ElasticSearch.

DynamoDB решил запрос данных временных рядов на уровне задержки менее миллисекунды. ElasticSearch решил проблему всех операций сравнения и фильтрации поверх данных.

Установите DynamoDB ttl на 30 дней, ElasticSearch не поддерживает ttl, однако мы удаляем дневной индекс, когда день создания индекса пересекает 30 дней.

person user2967920    schedule 17.09.2020