22165554

Ну да, ну да, две таблицы, две процедуры и скпипт, который читает с одной таблицы, делает запрос и кладет результаты в другую -- целая инфраструктура. Прям 5 лет и 5 лямов денег надо, чтобы реализовать.

Хотите делать из сервера СУБД сервер приложений -- дело ваше. Но если речь идет о 1000 запросов одновременно, то с таким подходом начинайте готовить много денег на его апгрейд, когда у вас закончатся цпу/память сервера .

И да, для таблицы-очереди команды update и delete не нужны от слова "совсем".

Вам виднее: отсюда не понятно, какого масштаба вы там воротите дела. Тем более, вариантов вам накидали.

А про очереди -- до определенного предела они отлично делаются на обычных таблицах.

Случай с множественными консьюмерами -- как раз не простой, но и тут есть варианты, если очень охота, а кафку поднимать негде.

Данные для разных консьюмеров изолируются либо через отельные партиции, либо через таблицы. В случае с отдельными таблицами придется городить огород, чтобы их как-то равномерно наполнять, но их можно секционировать по дате / диапазонам id и обработанные партиции транкейтить. В случае с одной таблицей придется как-то решать вопрос с очисткой обработанных данных, но и тут есть варианты, например, можно нарезать новые таблицы, а по факту полной обработки удалять старые. Консьюмер, соответственно, сидит на своей партиции/таблице и последовательно ее обрабатывает, отмечая где-то последний обработанный ключ, оффсет -- как назовете.

lex452,

Что ж, было приятно пообщаться. Прощайте.