powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / самописная таблица-очередь и select for update
25 сообщений из 60, страница 2 из 3
самописная таблица-очередь и select for update
    #39705054
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DВАА вот за обработку по одной записи да еще в порядке очереди - поубивала бы )А в очередях с синхронным ответом?
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705057
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-DВАПервый дернул все что есть на момент его запроса из очереди и в обработкуНе часто можно свести обработку к bulk операциям. А в oltp-системах это часто и вредно, так как увеличивается время удержания блокировки на ключевые данные.

вот кстати ни разу не видела в oltp-системах по-одиночной обработки записей очереди ))
ну в лучшем случае с каким-то разумным ограничением по количеству записей, да и то скорее для оперативного разгребания ситуаций с непредвиденными "скоплениями", чем для минимизации времени блокировок
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705067
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyНичего, что могут быть такие задачи, события в которых обязаны обрабатываться именно в порядке их текущего расположения,
с приоритетом, назначенным им в очереди?



ElicА в очередях с синхронным ответом?

Усе может быть, но в исходном посте простейшая задачка с одним условием - не пересекаться процессам обработки, чего накручивать-то ?
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705070
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyНичего, что могут быть такие задачи, события в которых обязаны обрабатываться именно в порядке их текущего расположения,
с приоритетом, назначенным им в очереди?

И кстати порядок обработки событий независимо от их приоритетов определяется временем завершения обработки, а не ее начала
а тут уже как бог на душу положит ))
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705084
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DВАПервый дернул все что есть на момент его запроса из очереди и в обработку, второй и остальные то, что добавилось позже, если кому-то не достается и это происходит часто, значит у меня обработчиков сильно дохрена и их нужно сократить.
А вот за обработку по одной записи да еще в порядке очереди - поубивала бы )
Сценарий: обработка очереди поднимается после технологического перерыва.
В очереди 100500 сообщений.
Одно сообщение обрабатывается, для простоты, 1 минуту и обработка утилизирует, к примеру, условные 5% ресурсов сервера.
Расскажи, сколько времени будет разбираться очередь в твоем подходе и почему нельзя использовать 95% простаивающих ресурсов для сокращения этого времени.
Сценарий слегка (именно что слегка) утрирован, но аналогичные эффекты имеют место и в установившемся режиме.
...и пожалуйста, не путай процессы раздачи работы по обработчикам с, собственно, обработкой данных (это про bulk-подходы к обработке очереди - они, безусловно, возможны, но НЕ ТАК как ты описываешь).
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705086
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousСценарий: обработка очереди поднимается после технологического перерыва.
В очереди 100500 сообщений.
Одно сообщение обрабатывается, для простоты, 1 минуту и обработка утилизирует, к примеру, условные 5% ресурсов сервера.
Расскажи, сколько времени будет разбираться очередь в твоем подходе и почему нельзя использовать 95% простаивающих ресурсов для сокращения этого времени.
Сценарий слегка (именно что слегка) утрирован, но аналогичные эффекты имеют место и в установившемся режиме.
...и пожалуйста, не путай процессы раздачи работы по обработчикам с, собственно, обработкой данных (это про bulk-подходы к обработке очереди - они, безусловно, возможны, но НЕ ТАК как ты описываешь).

DВАну в лучшем случае с каким-то разумным ограничением по количеству записей, да и то скорее для оперативного разгребания ситуаций с непредвиденными "скоплениями", чем для минимизации времени блокировок


пока ты писал я уже ответила )
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705091
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DВА пока ты писал я уже ответила )
Механизм ограничения "разумного количества" каков?
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705096
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousDВА пока ты писал я уже ответила )
Механизм ограничения "разумного количества" каков?

ну чукча не писатель, чукча разгребатель чужих очередей )))
готового алгоритма на руках не имею )
поэтому чисто из общих соображений - суммарное время обработки "разумного колличества" <= максимально допустимое время обработки одной записи
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705099
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DВА... порядок обработки событий независимо от их приоритетов определяется временем завершения обработки, а не ее начала
а тут уже как бог на душу положит ))
порядок здесь ключевое слово.
В разных контекстах определяемое по разному.
Нельзя одним алгоритмом определить все необходимые людям порядки разом по причине непредсказуемой сложности требуемого в конкретном случае алгоритма определения предшествования.
Порядок взятия в обработку "событий" и порядок, к котором завершается обработка - это разные порядки, востребованные в разных задачах.
Если возникает "производственный процесс", в котором выход одного "обработчика событий"
является входом для другого,
то его планирование, да еще с примешиванием параллелизма, превращается в самостоятельную задачу согласования этих порядков с целью определения общей топологии,
пригодной к распараллеливанию.

И еще о порядке.
Конечно, вопрос о том "кого убивать" можно решать и до формулировки задачи, вооружившись знаниями Прокруста о правильности роста или размере фетча.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705106
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyпорядок здесь ключевое слово.
В разных контекстах определяемое по разному.
Нельзя одним алгоритмом определить все необходимые людям порядки разом по причине непредсказуемой сложности требуемого в конкретном случае алгоритма определения предшествования.
Порядок взятия в обработку "событий" и порядок, к котором завершается обработка - это разные порядки, востребованные в разных задачах.
Если возникает "производственный процесс", в котором выход одного "обработчика событий"
является входом для другого,
то его планирование, да еще с примешиванием параллелизма, превращается в самостоятельную задачу согласования этих порядков с целью определения общей топологии,
пригодной к распараллеливанию.

И еще о порядке.
Конечно, вопрос о том "кого убивать" можно решать и до формулировки задачи, вооружившись знаниями Прокруста о правильности роста или размере фетча.

а можно я вашими же словами прокоменчу ? )

boobyИ, имхо, не так много шансов, что skip locked проявится в ответе на него.


Я тут вроде бы докопалась конкретно до алгоритма, предложенного Андреем, с его одиночным фетчем и со своими подозрениями, что это уж слишком :)
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705112
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DВА...
Я тут вроде бы докопалась конкретно до алгоритма, предложенного Андреем, с его одиночным фетчем и со своими подозрениями, что это уж слишком :)
Ок.

А я о том, что мамы разные нужны, мамы всякие важны.

Этот алгоритм имеет право на существование в определенных контекстах.
Уже хотя бы потому, что алгоритм планирования согласованной выборки множеством читателей
с одной панели событий уже вшит в него неявным образом, благодаря skip locked.
Это волшебство практически - всего лишь сказал skip locked, а планировщик чтения готов.

Я бы не прикапывался к алгоритму, в определенных обстоятельствах, несомненно уместному.
:)

Точно это те, где он самый уместный или в конкретном случае могут быть варианты - это должно быть виднее топикстартеру, хочется верить, человеку разумному.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705128
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DВАУ меня очередь, которая постоянно пополняется и количество обработчиков подогнанное к
числу минимально необходимых, для того, что бы количество записей в этой очереди было нулевым.

А, извините, зачем тут тогда очередь? Будет гораздо проще вместо добавления в неё сразу
стартовать обработчик.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705134
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyвыход одного "обработчика событий"
является входом для другого
Небольшое примечание: именно этот вопрос на базе очередей (в более общем случае - просто messaging) обычно решается одним из двух способов:
- в рамках модели publish-subscribe - отдельными "топиками" для различных операций, когда обработчик-"предшественник" по результатам своей деятельности размещает новое сообщение но уже в более другом "топике", на который подписан обработчик-"последователь".
- в рамках модели точка-точка - "предшественник" отправляет приватное сообщение непосредственно "последователю", топология коммуникаций в этом случае может задаваться метамоделью.

Есть комбинированные решения, когда обработчики "договариваются" в рамках publish-subscribe, а общаются уже в модели "точка-точка" - к примеру, такой забавный распределенный messaging как tibco rendezvous использует этот метод для возврата итогового ответа по цепочке обработчиков к отправителю.

Но это уже совсем "высокие материи", ТС же просил просто равномерно раскидать однородную неприоретизированную работу по ресурсам.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705140
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DВАсо своими подозрениями, что это уж слишком :)
Если у тебя в очереди миллионы сообщений и она реально требует крупноблочной обработки - то мое первое подозрение будет заключаться в том, что архитектор... ммм... несколько поторопился с выбором очереди как метода ipc либо не очень хорошо продумал содержимое сообщений.
Но это - лишь мои подозрения , которые я ни в коем случае не намерен тебе навязывать ;)
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705145
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous...
ТС же просил просто равномерно раскидать однородную неприоретизированную работу по ресурсам.
Вот. И DBA косвенно склоняла к чему-то, логически эквивалентному
DBMS_PARALLEL_EXECUTE
Что выглядит и даже работает замечательно, пригодно к наколенной-костыльной реализации
имени себя любимого, не противоречит bulk collect,
но требует вооружённого взгляда на очередь, по количеству звёздочек поднятых обработчиков.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705152
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyно требует вооружённого взгляда на очередь
Эт точно :)

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

...это при том, что готовых решений на рынке вагон плюс маленькая тележка имени AQ
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705177
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous,

вот если таки причитаться к авторТС же просил просто равномерно...,
то окажется, что в разборщиках там Java и Informatica заявлены.

Поделить и властвовать - здесь упирается в вопрос общего управления -
1) кто-то же им должен будет делить всё скопленное добро, "координировать" так сказать.
2) При полностью случайном наполнении очереди может оказаться,
что этот же кто-то должен понимать, когда пора заново пинать заснувшую информатику.

skip locked информатике не противоречит (надеюсь) в силу изначального нацеливания на асинхронную работу клиента очереди.

по части AQ - у меня совсем куцые представления.
С одной стороны, AQ - он и есть skip locked. Бери да пользуйся.
Информатике он в силу жизни поверх skip locked тоже не противоречит.
С другой, у меня стойкое впечатление, что AQ хорошего повара требует.
И, некоторые регламенты работы с очередями гораздо лучше ложатся на поделить и властвовать на костылях, чем на AQ.

PS
Вот не возникает у людей даже тени сомнения в том, что должны работать Java и Informatica.
Ну, и раз не возникает, то skip locked (или AQ, если мир иначе не видишь) - несомненный фаворит.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705202
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyandrey_anonymous,

вот если таки причитаться к авторТС же просил просто равномерно...,
то окажется, что в разборщиках там Java и Informatica заявлены.

Справедливости ради - ТС разное заявляет 21679600

boobyпо части AQ - у меня совсем куцые представления.

Это просто очереди в вендорском исполнении с готовым API (PL/SQL, java, C).
К ним могут быть присобачены синхронные PL/SQL обработчики (по механизму callback, иногда удобно)
Могут быть интегрированы с JMS, если хочется.
Свои ньюансы (иногда толстые) - безусловно присутствуют (как, впрочем везде), но явных противопоказаний в отношении поженить с java или ETL я с ходу не вспомню.

По skip locked - поверх этого дела по хорошему следует накрутить свою API-обертку, но не особо сложную. С учетом замечаний 21678450 и известной аккуратности вполне можно скрестить и с ETL, и с абстрактным java-приложением.

К преимуществам обоих подходов перед сторонними серверами очередей следует отнести возможность органично сочетать обработчики PL/SQL с обработчиками на сервере приложений.
К недостаткам - замороченность интеграции в случае, когда серверов БД становится более одного, особенно если зоопарк.
Тут лучше предпочесть сторонний messaging.
Впрочем, можно интегрировать эту беду а-ля AQ.

...а вот адекватно прикрутить тот же DBMS_PARALLEL_EXECUTE в качестве движка очереди при наличии внешних аппликух...
...я бы, пожалуй, постарался с подобной темы соскочить :)
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705783
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Уважаемые, всем спасибо за глубокую дискуссию!

Задача в итоге шире, чем в первом посте, поясню:

I планируется 2 очереди:
1) очередь заявок на обработку. Заявка - это крупный объект для общения между АС. Эта очередь должна получать новую заявку из внешнего по отношению к данной АС мира, никак не завися от ограниченности ресурсов АС (демон занят и тп).
2) полученная заявка должна захватываться демоном заявок, после чего по метаданным внутри АС производится ее декомпозиция на конкретные работы (работа - многошаговый процесс, в общем случае описанный как набор атомарных SQL в таблицах этой АС, соотношение Заявка - Работы = 1:М)
3) результат декомпозиции - работы - следует сложить во вторую очередь Работ, которую будут разбирать и исполнять демоны второго рода (исполнители работ).

Почему предполагается так:

1) ресурсы (кол-во демонов) ограничено.
2) Кол-во работ (SQL) в каждой заявке разное, время на их исполнение достаточно велико (от минут до часов)
3) !!! в очередь могут добавляться заявки с повышенным приоритетом, и их нужно будет обработать раньше тех, что попали в очередь до нее, но с низким

Т.о. целевой процесс предполагается таким:
Демон заявок:
1) схватил первую заявку из очереди, выяснил, что у нее 5 работ внутри - добавил эти 5 работ в очередь работ
2) схватил следующую заявку ...- и т.д. пока заявки не кончились - встал на ожидание новой строки (кстати посоветуйте как эффективнее. SLEEP?)

здесь вроде как не проблема с балк-операциями (сразу хватать все заявки)

Демон работ (запускается одновременно указанное лимитированное кол-во демонов параллельно):
1) схватил работу, выполнил, отчитался о результате статусом
2) схватил следующую работу .. и т.д.

здесь нельзя балк - работы долгие, выполняются пошагово.

А далее следует большое НО ;)
в угоду скорости внедрения очередь работ отложена на второй этап, Демоны работ эмулируются шелл-файлами линукса и прочей требухой.
Из ограничения "не более Н работ одновременно" получаем более жесткое ограничение "нельзя исполнять более одной заявки вида Х одновременно" и необходимость запускать в параллель демонов очереди по числу видов заявок, каждый из которых не имеет права запустить на исполнение более одной заявки своего вида.
это не дает сделать массовый обработчик, как предлагает DBA.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39705798
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexus12Задача в итоге шире, чем в первом посте
Если появились приоритеты и ресурсы на реализацию велосипеда ограничены - то имеет смысл использовать готовый транспорт.
К примеру, этот:
https://docs.oracle.com/database/121/ADQUE/aq_intro.htm#ADQUE2440
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39706527
SkilledJunior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Задача напоминает работу разделяемого сервера Oracle, диспетчер принимает запросы клиентов, помещает их в память, первый свободный процесс сервера берет запрос из памяти, выполняет его и помещает результат в память, откуда результат забирает диспетчер и возвращает клиенту.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39706653
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SkilledJuniorЗадача напоминает работу разделяемого сервера Oracle, диспетчер принимает запросы клиентов, помещает их в память, первый свободный процесс сервера берет запрос из памяти, выполняет его и помещает результат в память, откуда результат забирает диспетчер и возвращает клиенту.Допустим. Но кому и как это поможет?
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39706738
SkilledJunior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ElicДопустим. Но кому и как это поможет?
Если автор почитает про работу выделенного и разделяемого серверов, начнет лучше понимать что ему делать со своей задачей. Например, при продолжительности полной обработки задачи указанной автором, модель разделяемого сервера применять бессмысленно, никакого выигрыша от этого автор не получит. Две очереди тоже бессмысленны, только лишние затраты на разработку и поддержку диспетчеризации и демонов.

Alexus12,

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

С приоритетом вопрос сложнее, можно иметь какое то количество резервных демонов, которые не задействованы при обработке задач вплоть до момента когда все основные заняты и поступает заявка с высшим приоритетом. Есть конечно плохое решение, фоновый процесс мониторит входящие на предмет появления задач более высокого приоритета, если все демоны заняты, убивает демона который меньше всего по длительности на этот момент отработал, его заявку обратно помещает в очередь, а демона перезапускает, в результате чего демон подхватывает задачу с высшим приоритетом.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39706753
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SkilledJuniorElicДопустим. Но кому и как это поможет?Если автор почитает про работу выделенного и разделяемого серверов, начнет лучше понимать что ему делать со своей задачей. Например, при продолжительности полной обработки задачи указанной автором, модель разделяемого сервера применять бессмысленно, никакого выигрыша от этого автор не получит. Две очереди тоже бессмысленны, только лишние затраты на разработку и поддержку диспетчеризации и демонов.Ты слишком самонадеян, новичок.
...
Рейтинг: 0 / 0
самописная таблица-очередь и select for update
    #39706859
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous,

я только за встроенную функциональность ;)
но опыта по AQ нет, у вас есть?

кто может сказать, есть ли проблемы с:
1) приоритетами (нам сообщения нужно выбирать по сортировке "сначала по приоритетам asc, потом по дате появления в очереди asc - т.е. если появится сообщение с более высоким приоритетом, оно должно схватиться следующим - минуя более старые неразобранные с низким)?

2) есть ли проблемы с постановкой очереди на паузу (например, один из обработчиков не работает в дневное время - его сообщения должны копиться в очереди, а потом, когда он проснется, пойти разгребаться дальше)? в соседнем топике видел проблему, когда подписчик не хотел видеть сообщения, которые появились во время его сна... 8-(

3) с расширением метаданных (как выглядит процесс "добавить в очередь новое поле" - нужно остановить всю очередь (включая тех, кто туда пишет - а это много АС и они не в нашей власти!!!) или можно онлайн - типа redefinition)?

4) как именно лучше выгребать очередь и ПОЧЕМУ:
а) по job по таймеру пинать читателя, внутри которого стоит атомарный dequeuе (проблема сна так решается легко)
б) подписать его (но тут проблема сна + исполнителей будет ограниченное кол-во и нужно этим управлять - как?)
...
Рейтинг: 0 / 0
25 сообщений из 60, страница 2 из 3
Форумы / Oracle [игнор отключен] [закрыт для гостей] / самописная таблица-очередь и select for update
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]