Получить данные для диапазона дат в DynamoDB - PullRequest
Новая
       91

Получить данные для диапазона дат в DynamoDB

1 голос
/ 25 апреля 2020

Я использую Serverless и DynamoDB и относительно новичок в этом. В моем приложении есть таблица «Поездки». Параметры таблиц: {id, маршрут, стоимость, продажа, тип, дата, LR, актив} и ряд других не относящихся к делу номеров документов, где идентификатор генерируется uuid.

Согласно этому руководству для упорядочение данных в диапазоне дат (см. 5-ю строку в таблице в конце) https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-modeling-nosql-B.html Я добавил параметр с именем createdAt, который представляет собой случайное целое число от 1 до 20, отправленное внешним интерфейсом, и сделал GSI с HASH key в качестве созданного AT и SORT key в качестве date.

Я выполнил 20 обещаний одновременно, чтобы сохранить createAt от 1 до 20. Я просто объединяю все результаты в один объект, как этот. 

await Promise.all(promises).then(function (values) {
      console.log(values);
      values.map((value) => {
        value.map((v) => {
          tripdata.push(v);
        });
      });
    });

Вот ответ 

 [
 [
{
  Cost: 12128,
  date: '2020-04-01',
  RouteShortCode: 'Hazira-Manjusar-Sudeep',
  Selling: 11000,
  Type: 'Export'
},
{
  Cost: 12581,
  date: '2020-04-24',
  RouteShortCode: 'Hazira-Nandesari-Kevin',
  Selling: 10000,
  Type: 'Export'
}
],
[
{
  Cost: 12691,
  date: '2020-04-09',
  RouteShortCode: 'Hazira-Nandesari-Kevin',
  Selling: 10000,
  Type: 'Export'
}
],
[
{
  Cost: 11536,
  date: '2020-04-09',
  RouteShortCode: 'Hazira-Nandesari-Omega',
  Selling: 29000,
  Type: 'Import'
},
{
  Cost: 8973.5,
  date: '2020-04-18',
  RouteShortCode: 'Hazira-Manjusar-Sudeep',
  Selling: 11000,
  Type: 'Export'
}
],
[
{
  Cost: 11665,
  date: '2020-04-20',
  RouteShortCode: 'Hazira-Nandesari-Kevin',
  Selling: 10000,
  Type: 'Export'
}
],
]

Serverless.yml для tripsTable 

tripTable:
  Type: "AWS::DynamoDB::Table"
  Properties:
    AttributeDefinitions:
      [
        { "AttributeName": "id", "AttributeType": "S" },
        { "AttributeName": "date", "AttributeType": "S" },
        { "AttributeName": "createdAt", "AttributeType": "N" },
        { "AttributeName": "Asset", "AttributeType": "S" },
      ]
    # { "AttributeName": "Route", "AttributeType": "S" },
    KeySchema:
      [
        { "AttributeName": "date", "KeyType": "HASH" },
        { "AttributeName": "id", "KeyType": "RANGE" },
      ]
    ProvisionedThroughput:
      ReadCapacityUnits: 5
      WriteCapacityUnits: 5
    StreamSpecification:
      StreamViewType: "NEW_AND_OLD_IMAGES"
    TableName: ${self:provider.environment.TRIPS}
    GlobalSecondaryIndexes:
      - IndexName: DateVSTrips
        KeySchema:
          - AttributeName: createdAt
            KeyType: HASH
          - AttributeName: date
            KeyType: RANGE
        Projection:

          ProjectionType: "ALL"
        ProvisionedThroughput:
          ReadCapacityUnits: "5"
          WriteCapacityUnits: "5"

    LocalSecondaryIndexes:
      - IndexName: TripsVSRoutes
        KeySchema:
          - AttributeName: date
            KeyType: HASH
          - AttributeName: Asset
            KeyType: RANGE
        Projection:
          ProjectionType: ALL

Но проблема заключается в записи на 2020/04/01 и 2020 / 04/24 имеют один и тот же параметр createAt, поэтому после объединения всех результатов массива конечный результат не упорядочивается по дате.

Нужно ли снова сортировать этот список или я что-то здесь упустил? Если мне нужно будет снова отсортировать его, не станет ли он гораздо более неэффективным?

1 Ответ

0 голосов
/ 27 апреля 2020

DDB не сможет вернуть вам данные в отсортированном списке, поскольку вы делаете 20 отдельных параллельных запросов.

Вам нужно будет отсортировать весь список самостоятельно, как только у вас будут все 20 результатов.

При этом, действительно ли у вас есть объем, необходимый для структуры, которую вы используете?

Страница, на которую вы ссылались, имеет следующее

Например, предположим, что вы ожидаете следующее:

В системе будет до 2 миллионов заказов, а через 5 лет вырастет до 3 миллионов.

До 20 процентов этих заказов будет Состояние ОТКРЫТО в любой момент времени.

Средняя запись заказа составляет около 100 байтов с тремя записями OrderItem в разделе заказа, каждый из которых составляет около 50 байтов, что дает вам средний размер сущности заказа 250 байтов.

Для этой таблицы вычисление коэффициента N будет выглядеть следующим образом.

ItemsPerRCU = 4KB / 250B = 16

PartitionMaxReadRate = 3K * 16 = 48K

N = (0,2 * 3M) / 48K = 13

Если вы выполнили вычисления и округлили до 20, тогда отлично.

...