Список заданных задач с DynamoDB

Question

Я рассматриваю возможность записи системы очередей поверх DynamoDB. Это не что-то вроде SQS или фоновой обработки. Это - это упорядоченный список вещей, которые сотрудники должны обрабатывать. Есть очереди , которые содержат идентификаторы для других объектов в более крупной системе. Эта часть только представляет собой аспект очереди.

Бизнес-модель работает следующим образом. Объект входит в систему и добавляется в заданную очередь. Сотрудник выбирает что-то от очереди. Это перемещает данный элемент в рабочий набор для заданного времени . Если работник создает задачу до указанного времени , задача завершается и удаляется из системы. Если нет, то удаляется из рабочего набора и добавляется обратно в основную очередь. Есть несколько сотрудников, которые вытаскивают вещи из очереди сразу. Это происходит в реальном человеческом времени. Системе также необходимо поддерживать операционные операции . Таким образом, общие задания могут отображаться в пользовательском интерфейсе .

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

Я играл с DyanmoDB раньше, но только на игрушечном материале. Это реальная сделка. Я не могу понять, как взять эту бизнес-модель и перейти на DynamoDB. Наивный подход был бы принять документ как это:

{ 
     "queue": "high", 
     "jobs": [1,2,3,4,5,6] 
    } 

И просто сохранить, что в таблице заданий. Я сказал наивно, потому что это будет тратить способности DynamoDB на производительность, потому что все Пропускная способность должна пройти через несколько ключей (на практике есть ~ 3 очереди ) для всех чтений и записей. К сожалению, я не могу прийти с полным решением.

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

Hash Range Job Task 
    high 1  55  328 
    low  2  15  23871 
    medium 1  12  38173 

И так далее. Это будет распространять чтения по всей таблице. Получив , первый элемент в очереди будет делать запрос по queue и сортировать по range, затем вытащить первый элемент. Счетчик работает в аналогичным образом.

Я думаю, что рабочий набор будет работать аналогичным образом, кроме хэша будет что-то вроде queue.job. Таким образом, get запрос может быть сделан в таблицу, чтобы выбрать отдельный элемент. Таблица jobs может иметь такое же требование.

Я забочусь о том, чтобы все заказывалось в таблице рабочих мест. Вставив , новый элемент будет использовать count + 1 для ключа диапазона.Я не уверен , как это будет работать на практике. Я вижу проблему, так как размер очереди колеблется. Работы должны быть запрограммированы в начале . Если они не удалены из рабочего набора во времени, они должны перейти к передней части общей очереди. Это можно сделать, используя 0 для диапазона.

Кто-нибудь реализовал что-то похожее на вершине DynamoDB или моя идея полная свинья? Если да, пожалуйста, скажите мне. У меня есть шанс обновить критически важную бизнес-систему и хочу сделать эту вещь stable & быстро, так как у нас сейчас много проблем.

Answer 1

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

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

1. работы Подробности: Hash (JobID/UUID), сведения о задании (другие атрибуты)
2. Очередь заданий: Hash (идентификатор сотрудника/владельца), Hash («высокий/низкий»), {jobid1, jobid2 ...} (это строка JSON).

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