Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: самописная таблица-очередь и select for update  [new]
Elic
Member

Откуда:
Сообщений: 29976
DВА
А вот за обработку по одной записи да еще в порядке очереди - поубивала бы )
А в очередях с синхронным ответом?
19 сен 18, 15:26    [21679698]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
DВА
Member

Откуда:
Сообщений: 5439
-2-
DВА
Первый дернул все что есть на момент его запроса из очереди и в обработку
Не часто можно свести обработку к bulk операциям. А в oltp-системах это часто и вредно, так как увеличивается время удержания блокировки на ключевые данные.


вот кстати ни разу не видела в oltp-системах по-одиночной обработки записей очереди ))
ну в лучшем случае с каким-то разумным ограничением по количеству записей, да и то скорее для оперативного разгребания ситуаций с непредвиденными "скоплениями", чем для минимизации времени блокировок
19 сен 18, 15:30    [21679703]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
DВА
Member

Откуда:
Сообщений: 5439
booby
Ничего, что могут быть такие задачи, события в которых обязаны обрабатываться именно в порядке их текущего расположения,
с приоритетом, назначенным им в очереди?



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


Усе может быть, но в исходном посте простейшая задачка с одним условием - не пересекаться процессам обработки, чего накручивать-то ?
19 сен 18, 15:38    [21679716]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
DВА
Member

Откуда:
Сообщений: 5439
booby
Ничего, что могут быть такие задачи, события в которых обязаны обрабатываться именно в порядке их текущего расположения,
с приоритетом, назначенным им в очереди?

И кстати порядок обработки событий независимо от их приоритетов определяется временем завершения обработки, а не ее начала
а тут уже как бог на душу положит ))
19 сен 18, 15:43    [21679723]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
DВА
Первый дернул все что есть на момент его запроса из очереди и в обработку, второй и остальные то, что добавилось позже, если кому-то не достается и это происходит часто, значит у меня обработчиков сильно дохрена и их нужно сократить.
А вот за обработку по одной записи да еще в порядке очереди - поубивала бы )

Сценарий: обработка очереди поднимается после технологического перерыва.
В очереди 100500 сообщений.
Одно сообщение обрабатывается, для простоты, 1 минуту и обработка утилизирует, к примеру, условные 5% ресурсов сервера.
Расскажи, сколько времени будет разбираться очередь в твоем подходе и почему нельзя использовать 95% простаивающих ресурсов для сокращения этого времени.
Сценарий слегка (именно что слегка) утрирован, но аналогичные эффекты имеют место и в установившемся режиме.
...и пожалуйста, не путай процессы раздачи работы по обработчикам с, собственно, обработкой данных (это про bulk-подходы к обработке очереди - они, безусловно, возможны, но НЕ ТАК как ты описываешь).
19 сен 18, 15:51    [21679743]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
DВА
Member

Откуда:
Сообщений: 5439
andrey_anonymous
Сценарий: обработка очереди поднимается после технологического перерыва.
В очереди 100500 сообщений.
Одно сообщение обрабатывается, для простоты, 1 минуту и обработка утилизирует, к примеру, условные 5% ресурсов сервера.
Расскажи, сколько времени будет разбираться очередь в твоем подходе и почему нельзя использовать 95% простаивающих ресурсов для сокращения этого времени.
Сценарий слегка (именно что слегка) утрирован, но аналогичные эффекты имеют место и в установившемся режиме.
...и пожалуйста, не путай процессы раздачи работы по обработчикам с, собственно, обработкой данных (это про bulk-подходы к обработке очереди - они, безусловно, возможны, но НЕ ТАК как ты описываешь).


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



пока ты писал я уже ответила )
19 сен 18, 15:53    [21679746]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
DВА
пока ты писал я уже ответила )

Механизм ограничения "разумного количества" каков?
19 сен 18, 15:59    [21679755]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
DВА
Member

Откуда:
Сообщений: 5439
andrey_anonymous
DВА
пока ты писал я уже ответила )

Механизм ограничения "разумного количества" каков?


ну чукча не писатель, чукча разгребатель чужих очередей )))
готового алгоритма на руках не имею )
поэтому чисто из общих соображений - суммарное время обработки "разумного колличества" <= максимально допустимое время обработки одной записи
19 сен 18, 16:05    [21679761]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
booby
Member

Откуда:
Сообщений: 2249
DВА
... порядок обработки событий независимо от их приоритетов определяется временем завершения обработки, а не ее начала
а тут уже как бог на душу положит ))

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

И еще о порядке.
Конечно, вопрос о том "кого убивать" можно решать и до формулировки задачи, вооружившись знаниями Прокруста о правильности роста или размере фетча.
19 сен 18, 16:09    [21679770]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
DВА
Member

Откуда:
Сообщений: 5439
booby
порядок здесь ключевое слово.
В разных контекстах определяемое по разному.
Нельзя одним алгоритмом определить все необходимые людям порядки разом по причине непредсказуемой сложности требуемого в конкретном случае алгоритма определения предшествования.
Порядок взятия в обработку "событий" и порядок, к котором завершается обработка - это разные порядки, востребованные в разных задачах.
Если возникает "производственный процесс", в котором выход одного "обработчика событий"
является входом для другого,
то его планирование, да еще с примешиванием параллелизма, превращается в самостоятельную задачу согласования этих порядков с целью определения общей топологии,
пригодной к распараллеливанию.

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


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

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



Я тут вроде бы докопалась конкретно до алгоритма, предложенного Андреем, с его одиночным фетчем и со своими подозрениями, что это уж слишком :)
19 сен 18, 16:18    [21679783]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
booby
Member

Откуда:
Сообщений: 2249
DВА
...
Я тут вроде бы докопалась конкретно до алгоритма, предложенного Андреем, с его одиночным фетчем и со своими подозрениями, что это уж слишком :)

Ок.

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

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

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

Точно это те, где он самый уместный или в конкретном случае могут быть варианты - это должно быть виднее топикстартеру, хочется верить, человеку разумному.
19 сен 18, 16:31    [21679793]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51758

DВА
У меня очередь, которая постоянно пополняется и количество обработчиков подогнанное к
числу минимально необходимых, для того, что бы количество записей в этой очереди было нулевым.

А, извините, зачем тут тогда очередь? Будет гораздо проще вместо добавления в неё сразу
стартовать обработчик.

Posted via ActualForum NNTP Server 1.5

19 сен 18, 16:56    [21679819]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
booby
выход одного "обработчика событий"
является входом для другого

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

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

Но это уже совсем "высокие материи", ТС же просил просто равномерно раскидать однородную неприоретизированную работу по ресурсам.
19 сен 18, 17:04    [21679829]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
DВА
со своими подозрениями, что это уж слишком :)

Если у тебя в очереди миллионы сообщений и она реально требует крупноблочной обработки - то мое первое подозрение будет заключаться в том, что архитектор... ммм... несколько поторопился с выбором очереди как метода ipc либо не очень хорошо продумал содержимое сообщений.
Но это - лишь мои подозрения, которые я ни в коем случае не намерен тебе навязывать ;)
19 сен 18, 17:10    [21679840]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
booby
Member

Откуда:
Сообщений: 2249
andrey_anonymous
...
ТС же просил просто равномерно раскидать однородную неприоретизированную работу по ресурсам.

Вот. И DBA косвенно склоняла к чему-то, логически эквивалентному
DBMS_PARALLEL_EXECUTE
Что выглядит и даже работает замечательно, пригодно к наколенной-костыльной реализации
имени себя любимого, не противоречит bulk collect,
но требует вооружённого взгляда на очередь, по количеству звёздочек поднятых обработчиков.
19 сен 18, 17:13    [21679846]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
booby
но требует вооружённого взгляда на очередь

Эт точно :)

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

...это при том, что готовых решений на рынке вагон плюс маленькая тележка имени AQ
19 сен 18, 17:22    [21679859]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
booby
Member

Откуда:
Сообщений: 2249
andrey_anonymous,

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

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

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

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

PS
Вот не возникает у людей даже тени сомнения в том, что должны работать Java и Informatica.
Ну, и раз не возникает, то skip locked (или AQ, если мир иначе не видишь) - несомненный фаворит.
19 сен 18, 18:05    [21679920]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
booby
andrey_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 в качестве движка очереди при наличии внешних аппликух...
...я бы, пожалуй, постарался с подобной темы соскочить :)
19 сен 18, 18:47    [21679972]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
Alexus12
Member

Откуда:
Сообщений: 2868
Уважаемые, всем спасибо за глубокую дискуссию!

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

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

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

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

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

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

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

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

А далее следует большое НО ;)
в угоду скорости внедрения очередь работ отложена на второй этап, Демоны работ эмулируются шелл-файлами линукса и прочей требухой.
Из ограничения "не более Н работ одновременно" получаем более жесткое ограничение "нельзя исполнять более одной заявки вида Х одновременно" и необходимость запускать в параллель демонов очереди по числу видов заявок, каждый из которых не имеет права запустить на исполнение более одной заявки своего вида.
это не дает сделать массовый обработчик, как предлагает DBA.
20 сен 18, 18:14    [21681260]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
Alexus12
Задача в итоге шире, чем в первом посте

Если появились приоритеты и ресурсы на реализацию велосипеда ограничены - то имеет смысл использовать готовый транспорт.
К примеру, этот:
https://docs.oracle.com/database/121/ADQUE/aq_intro.htm#ADQUE2440
20 сен 18, 19:18    [21681314]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
SkilledJunior
Member

Откуда:
Сообщений: 303
Задача напоминает работу разделяемого сервера Oracle, диспетчер принимает запросы клиентов, помещает их в память, первый свободный процесс сервера берет запрос из памяти, выполняет его и помещает результат в память, откуда результат забирает диспетчер и возвращает клиенту.
23 сен 18, 12:39    [21683056]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
Elic
Member

Откуда:
Сообщений: 29976
SkilledJunior
Задача напоминает работу разделяемого сервера Oracle, диспетчер принимает запросы клиентов, помещает их в память, первый свободный процесс сервера берет запрос из памяти, выполняет его и помещает результат в память, откуда результат забирает диспетчер и возвращает клиенту.
Допустим. Но кому и как это поможет?
23 сен 18, 20:12    [21683321]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
SkilledJunior
Member

Откуда:
Сообщений: 303
Elic
Допустим. Но кому и как это поможет?

Если автор почитает про работу выделенного и разделяемого серверов, начнет лучше понимать что ему делать со своей задачей. Например, при продолжительности полной обработки задачи указанной автором, модель разделяемого сервера применять бессмысленно, никакого выигрыша от этого автор не получит. Две очереди тоже бессмысленны, только лишние затраты на разработку и поддержку диспетчеризации и демонов.

Alexus12,

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

С приоритетом вопрос сложнее, можно иметь какое то количество резервных демонов, которые не задействованы при обработке задач вплоть до момента когда все основные заняты и поступает заявка с высшим приоритетом. Есть конечно плохое решение, фоновый процесс мониторит входящие на предмет появления задач более высокого приоритета, если все демоны заняты, убивает демона который меньше всего по длительности на этот момент отработал, его заявку обратно помещает в очередь, а демона перезапускает, в результате чего демон подхватывает задачу с высшим приоритетом.
24 сен 18, 01:30    [21683470]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
Elic
Member

Откуда:
Сообщений: 29976
SkilledJunior
Elic
Допустим. Но кому и как это поможет?
Если автор почитает про работу выделенного и разделяемого серверов, начнет лучше понимать что ему делать со своей задачей. Например, при продолжительности полной обработки задачи указанной автором, модель разделяемого сервера применять бессмысленно, никакого выигрыша от этого автор не получит. Две очереди тоже бессмысленны, только лишние затраты на разработку и поддержку диспетчеризации и демонов.
Ты слишком самонадеян, новичок.
24 сен 18, 07:43    [21683493]     Ответить | Цитировать Сообщить модератору
 Re: самописная таблица-очередь и select for update  [new]
Alexus12
Member

Откуда:
Сообщений: 2868
andrey_anonymous,

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

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

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

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

4) как именно лучше выгребать очередь и ПОЧЕМУ:
а) по job по таймеру пинать читателя, внутри которого стоит атомарный dequeuе (проблема сна так решается легко)
б) подписать его (но тут проблема сна + исполнителей будет ограниченное кол-во и нужно этим управлять - как?)
24 сен 18, 11:31    [21683694]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить