Порядок сканирования AWS Dynamodb?

Question

У нас есть настройка, в которой различные рабочие узлы выполняют вычисления и обновляют свои относительные состояния в таблице DynamoDB.Таблица выступает своего рода историей активности рабочих узлов.Сторожевой узел должен периодически сканировать таблицу и создавать объект, представляющий текущее состояние рабочих узлов и их заданий.Поэтому для нашего приложения важно иметь возможность сканировать таблицу и извлекать данные в хронологическом порядке (то есть сортировать по отметке времени).В конечном итоге таблица будет слишком большой для сканирования в локальную память для последующего упорядочения, поэтому мы не можем отсортировать ее после сканирования.

Чтение из документации AWS о первичном ключе:

DynamoDB использует значение ключа разделения в качестве ввода для внутренней хэш-функции.Выходные данные из хэш-функции определяют раздел (физическое хранилище, внутреннее для DynamoDB), в котором будет храниться элемент.Все элементы с одним и тем же ключом разделения хранятся вместе, в порядке сортировки по значению ключа сортировки .

Документация по функции сканирования, похоже, ничего не говорит о порядкевозвращенные результаты.Но можно ли интерпретировать эту последнюю часть в приведенной выше цитате (ту часть, которую я выделил жирным шрифтом) так, что результаты сканирования упорядочены по ключу сортировки?Если я установлю все ключи разделов на одно и то же значение, скажем «0», а затем использую мою метку времени в качестве ключа сортировки, могу ли я быть уверен, что операция сканирования вернет данные в хронологическом порядке?

Некоторые примечания:

• Весь код написан на Python, и поэтому я использую модуль boto3 для выполнения операций сканирования.
• Наш системный архитектор настойчиво возражает против идеи обновления любых записей в таблице, чтобы отразить их текущее состояние, или удаления элементов после завершения задания.Мы можем только добавлять данные в таблицу, и поэтому нам нужно каждый раз сканировать все это, чтобы определить рабочие состояния.
• Я использую строгую согласованность чтения для операций сканирования.

Answer 1

Вам лучше использовать yyyy-mm-dd в качестве ключа раздела, а не все 0.Существует ограничение в 10 ГБ данных на раздел, что также означает, что вы не можете иметь более 10 ГБ данных на значение ключа раздела.

Если вы хотите иметь возможность извлекать данные, отсортированные по дате, возьмите формат отметки времени ISO 8601 (примерно yyyy-mm-ddThh-mm-ss.sss), разделите его где-нибудь в соответствии с вашими данными и используйте первую часть в качестве ключа разделенияи вторая часть в качестве ключа сортировки.(Другим преимуществом этого подхода является то, что вы можете в конечном итоге использовать согласованные чтения для большинства запросов, поскольку вполне безопасно предположить, что через день (или час или более) данные полностью реплицируются.)

Если вы можете управлять им, было бы еще лучше использовать Worker ID или Job ID в качестве ключа раздела, а затем вы могли бы использовать метку полного времени в качестве ключа сортировки.

Как упоминалось @thomasmichaelwallace, было быЛучше всего использовать DynamoDB-потоки с Lambda для создания материализованного представления.

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

Answer 2

Технически SCAN никогда не гарантирует порядок (хотя как наблюдение отсутствие гарантии порядка, кажется, означает, что разделение упорядочено случайным образом, но сортировка остается, ну, в общем, отсортированной.)

То, что вы предложили , все равно будет работать , но вместо сканирования вы будете выполнять запрос на partition-key == 0, который затем вернет все элементы с разделомключ 0, (до limit и, необязательно, отсортированный вперед / назад), отсортированный по ключу сортировки.

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

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