Есть ли какое-нибудь решение для моей задачи или какая-нибудь алгоритмическая

база? Собственно задача.

1 Общее описание
1.1 Есть источники производители тасков (имеется виду задания, которые едят некоторые ресурсы системы и хорошо бы их выполнить)
1.2 Есть процессы исполнители тасков
1.3 И прослойка между производителями и исполнителями, которая хранит данные, до востребования

2 Дополнительные условия
2.1 Известно, что все таски приоритезированы и число приоритетов не константа (то есть приоритет представлен действительным числом и соответственно их может быть бесконечно много)
2.2 Известно, что производители приносят в сотни раз больше, чем могут выполнить потребители
2.3 Известно, что таски имеют id и могут обновляться (то есть, от производителя может прилететь таск с тем же id, но с большим приоритетом, старый вариант следует удалить а новый записать)
2.4 Все задания восполнимы и рано или поздно производитель их снова пришлёт (а если и не пришлёт, то не страшно)

3 Что хочется сделать
3.1 Написать прослойку из пункта 1.3
3.2 Оптимизировать для записи по причине изложенной в 2.2
3.3 Предусмотреть вытеснение задач (я так вижу, что это приоритезированная очередь с заданной размерностью и если элемент вылетает за пределы, то он просто должен быть удалён)
3.4 Предусмотреть обновления из пункта 2.3

А что будет если выполнить таску с id = 1, а потом создастся обновление таски с id = 1? Обновления вообще меняют суть задачи, или только метаданные типа приоритета?

нет обновления только приоритет меняют, а саму задачу нет. Если задача выполнилась а потом прилетело обновление, то оно будет воспринято как новый таск. Я не конкретизировал этот момент, нет отдельного метода update производители не знают что падало на выполнение, а что нет

Для конечных множеств с линейным порядком есть структура данных как бинарная куча В ней доступ к самому большому элементу за O(1), а запись нового элемента за O(log N) Вытащить самый большой элемент тоже будет за O(log N) Но вот доступ к произвольному элементу будет за O(N), но его можно распараллелить map reduce-ом простым А так, вообще можно просто поддерживать дерево поиска Тогда операции добавления/обновления/удаления будут за O(log N), а доступ к самому большому будет за O(N), но его можно распараллелить на все ядра Так что смотри по количеству элементов и частоте обновлений. Если мало элементов и много обновлений, то лучше дерево. Если много элементов, но мало обновлений, то лучше кучу И вопрос: зачем нужна такая очередь тасок, если они создаются чаще чем исполняются?

Для производителей не основная задача производить эти таски это скорее побочный эффект, они их создают просто потому что это ничего не стоит и таким образом максимизируют профит от "дорогих" задач, выполняются только самые приоритетные задачи найденные системой

Если оставить идею с вещественными числами, тогда точно нужно простое дерево поиска. Можно будет его даже как-нибудь экзотически балансировать, чтобы оптимизировать поиск, потому что основной доступ, как я понял, будет на запись тасок с низким приоритетом Я так понял, что ещё будет просто куча задач до которых приоритет практически никогда не дойдёт, а они просто будут ждать обновления Ну я бы тогда посоветовал разделить задачи на группы, а не от балды расставлять приоритеты вещественными числами Создать группу приоритетных задач и её держать кучей И создать группу неприоритетных задач, до которых если приоритет и дойдёт, то будет не важно в каком приоритете их исполнять, и держать её с быстрым доступом по ключу (дерево или хэшмапа), чтобы точечно вытаскивать некоторые в приоритетную кучу

хорошая идея, попробую так реализовать, спасибо

Походу если можно спрогнозировать какие чиселки будут стоять в поле приоритет - все будет сильно проще