секунду по 100-300 строк. Эти данные селектом построчно я вытягиваю в своё java приложение, где они онлайн обрабатываются. То есть селект запрос забирает каждую новую строку у меня в бесконечном цикле while (true) . И вот я, как человек внимательный, спустя полгода 🙈🙈🙈🙈 заметил, что это нехитрое действие жрёт львиную долю моего ЦП. Вопрос: всё ли я делаю правильно для забора новых строк из бд? Может как-то поэлегантнее есть решение?
my_mega_procedure; if ( !selected_count && timeout < 15 ) { timeout += 5; } else { timeout = 0; } sleep(timeout);
ЦПУ жрется на стороне джавы же? Понятно, что tight loop будет выжирать цпу. Поэлегантней - можно подписаться на изменения в бд, можно забирать данные раз в секунду (в зависимости от бизнес-требований) и тд
Я не понял сути...ради чего такой запрос? Что он улучшает по сравнению просто селект?
Подписаться на изменения - что это такое? Может то, что мне надо
Циклы пустые не крутит.
Есть Debezium, который стримит изменения
Понял. Буду читать
Спасибо.буду гуглить. Этот дебезиум может в джаву отдавать?
https://jdbc.postgresql.org/documentation/server-prepare/#listen--notify
Отдает в очередь, в кафку например. Наверное можно как-то напрямую подписаться на Write ahead log. Рекомендую это тоже погуглить
Возможно, если вам нужна очередь сообщений — то лучшэ будет взять какую-нибудь реализацыю очереди сообщений и message broker. Кафку там, например. Или rabbitmq, не знаю.
А к джаве как прикрутить? Это реально?
Коннекшн пул используете?
Через JMS Connector, разумеется. Кстати, ИМХО джавовский спек по JMS в любом случае полезно прочесть. Дажэ если у вас не джава.
Да, погуглить Кафка клиент на джаве
Пул соединений? Он же вроде для быстрой вставки в таблицу, а не для запросов типа селект?
Обсуждают сегодня