How to organize a searchable queue?

Question

Algorithms

At the moment, I successfully use the redis queue, its performance is completely satisfied. But the search is missing.
I will describe the problem to make it clearer. There is an active queue with a constant filling of ~ 10,000 records. Each entry is an object with 9 fields/properties. Records enter the right side of the queue, and are removed from the left side. At the same time, you need to periodically find priority entries in the queue and take them out, as if skipping ahead. The priority criteria for such entries are changeable, so I say right away that they cannot be placed in a separate queue in advance, you just need to choose from the general one. In addition, according to the criteria, you only need to extract the element that is the most to the left (i.e. closer to the natural onset of its turn to extract)

Answer 1

search is an index
with all the "conveniences" like rebuilding after each insertion, yeah,
you take Postgre with all the inmemory bells and whistles and nosql add-ons, you
take Mongo (memory, goodbye) or Elastic (don't, well, don't go too far ...) you
take Manticore
, set up, test on real data,
I would stop at the latter, but I'm not very sure of good work with a constant insertion, although the RT index is being developed...

Answer 2

What was in the queue should be preserved? It seems that 10,000 records are not very many and can be kept in memory. It is trite to write your own implementation of the ring buffer. At the same time, the element removed from the middle should not be deleted, but marked as read, so that when the end pointer reaches it, it stupidly skips it.