Является ли Oracle AQ/Streams каким-либо использованием в моей ситуации?
Я пишу систему документооборота, которая на каждом этапе полностью управляется явным человеческим взаимодействием. То есть задача назначается человеку, который выбирает один из нескольких ограниченных вариантов {одобрить, отклонить, переслать}, а затем он либо отправляется следующему человеку, либо прекращается.
Просто любопытно, может ли Oracle Streams/AQ что-либо предложить по сравнению с плоскими таблицами, управляемыми обычным кодом веб-приложения. Объем обработки после каждого действия довольно ограничен, а объем не слишком высокий, поэтому нет необходимости регулировать объемы, бросая их в очередь. Каковы некоторые из преимуществ введения структуры очереди, или это излишне для моей ситуации?
3 ответа
Есть много причин, по которым система очередей выгодна, но я не уверен, что они применимы в вашей ситуации. Похоже, у вас есть единственная система, хранящаяся в одной базе данных. Таким образом, я не думаю, что организация очередей обеспечит какое-либо преимущество перед обычными столами.
Ситуации, в которых AQ предоставляет преимущества, включают: - как механизм взаимодействия различных систем (нескольких баз данных) друг с другом.
- если у вас слабосвязанные системы - производитель сообщений, отправляющий неизвестному количеству подписчиков
Как способ управления состоянием в одной системе, как вы описали, я думаю, что Streams/AQ будет излишним.
Большим преимуществом организации очередей является то, что она может сделать проблемы параллелизма, которые в противном случае действительно сложными (показать один и только один поток эту запись для обработки), действительно легкими. Без постановки в очередь вы могли бы попробовать, но не гарантировать, что такое поведение, и вам пришлось бы в конечном итоге выполнять большое количество промежуточных обновлений состояния и проверять наличие неисправных потоков.
В версии 10g и ниже Oracle реализовал операцию удаления транзакций с помощью SKIP LOCKED Синтаксис, который конечным пользователям не разрешен. В 11g этот синтаксис был представлен, чтобы позволить людям решить эту проблему (покажите мне следующую запись), не требуя реализации AQ.
Вторым преимуществом AQ является то, что очистка очереди выполняется асинхронно.
Большим недостатком AQ является его размер и обслуживание - в итоге создается порядка 7 таблиц / IOT для одной постоянной очереди / темы, и невозможно напрямую обслуживать эти объекты базы данных, но вы должны выполнять обслуживание через пакеты DBMS_AQ и DBMS_AQADM.
Если ваше приложение действительно такого низкого уровня громкости и допускает задержку в несколько минут, я бы избегал и того, и другого, и использовал бы триггеры старой школы для заполнения своих собственных таблиц журналов. Я тогда обработал бы это с работами pl. Все, чтобы избежать дополнительных функций / сложностей, которые приносит AQ.