Скорость запроса больших таблиц DynamoDb

мы переходим с mysql на Dynamo db, прежде чем у меня есть несколько вопросов

в моей таблице mysql 40 миллионов элементов

есть начало, я переместил 225000 в одну таблицу на динамо-базе, чтобы проверить, стоит ли она

мой объект выглядит так:

"Partition key"{
             account_id:number,
             book_id:1,
             reader_id:2,
             field:3,
             field:4,
             ...
}

мой первый тест - получить данные по account_id

поэтому я создал глобальный индекс для этого поля

что я пробовал:

запрос всех данных, где account_id = 2, с использованием правильного индекса

это заняло примерно 90 секунд, и было возвращено 225 000 предметов.

это нормальная скорость для динамо-дб?

Теперь скажем, что мне не нужны возвращаемые фактические объекты, мне просто нужно подсчитать, сколько объектов

Матчи:

account_id = 3

И book_id = 10

И reader_id = 222

я знаю, что мне нужно ПРОСМОТРЕТЬ таблицу для этого

какой будет лучший подход, и могу ли я ожидать "нормальной" скорости для этого вида сканирования

для 40 миллионов элементов одна таблица?

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


.net amazon-dynamodb dynamodb-queries
person David Munsa    schedule 30.12.2018    source источник
comment
вам никогда не следует делать сканирование. используйте эластичный поиск, чтобы сканировать, и динамо-машину для поиска и получения.   -  person best wishes    schedule 30.12.2018
comment
какой у меня выбор в этом сценарии? я должен использовать сканирование   -  person David Munsa    schedule 31.12.2018

Ответы (1)


arrow_upward
0
arrow_downward

Сканирование Dynamodb стоит дорого, и его почти никогда не следует использовать, но если ваши требования такие, вы можете воспользоваться следующим подходом:

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

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

  1. атомарность операции в первой таблице и
  2. когда вы устанавливаете для параллелизма меньшее число в лямбда-выражении, это решает условие гонки во второй таблице.

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

Плюсы подхода

  1. Не нужно будет делать сканирование.

Минусы

  1. придется вести 2 стол.
  2. если требования изменятся, нам, возможно, придется повторно заполнить вторую таблицу, и это потребует значительных усилий. (PS это можно сделать проще, если вы используете лямбда и динамо, сначала очистите вторую таблицу. Теперь вы просто измените какое-то случайное поле в своей первой таблице items, и он пройдет по конвейеру, заполняя вторую таблицу.)
  3. задержка в доступности данных. (поскольку заполнение данных асинхронно)

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

  1. ваша схема таблицы может развиваться, и вычисленное значение может не иметь этих значений. (например, определение нового вторичного ключа?) (Следовательно, предлагается иметь 2 таблицы)

  2. Условия гонки будут там, где два запроса одновременно пытаются обновить одни и те же записи. (Следовательно, лямбда-функция с меньшим параллелизмом, так что 2 потока не работают с одной и той же записью.)

  3. Атомарность: если вторая запись не удалась, нам, возможно, придется отменить первую запись.

person best wishes    schedule 31.12.2018