DynamoDb Скорость запросов к большим таблицам - PullRequest
Новая
       9

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

0 голосов
/ 30 декабря 2018

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

моя таблица mysql содержит 40 миллионов элементов

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

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

"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

AND book_id = 10

AND reader_id = 222

я знаю, что мне нужно SCAN таблица для этого

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

за 40 миллионов предметов на один стол?

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

1 Ответ

0 голосов
/ 31 декабря 2018

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

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

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

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

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

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

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

Минусы

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

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

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

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

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

...