У меня есть один процесс, который запрашивает таблицу для записей, где PROCESS_IND = 'N', выполняет некоторую обработку, а затем обновляет PROCESS_IND до 'Y'.
Я хотел бы разрешить запуск нескольких экземпляров этого процесса, но не знаю, как лучше всего избежать проблем с параллелизмом.
С чего начать?
Шаблон, который я бы использовал, выглядит следующим образом:
Каждая задача будет выполнять запрос, например:
ОБНОВЛЕНИЕ таблицы задач SETlockedby=(мой идентификатор), locktime=now() ГДЕ Lockedby IS NULL ORDER BY ID LIMIT 10
Где 10 - "размер партии".
LIMIT 10 специфичен для MySQL, но другие базы данных имеют эквиваленты. ORDER BY импортируется, чтобы запрос не был недетерминированным.
Хотя я понимаю намерение, я бы не согласился с немедленным переходом к блокировке на уровне строк. Это сократит время ответа и может даже усугубить вашу ситуацию. Если после тестирования вы видите проблемы параллелизма с APL, вы должны сначала сделать итеративный переход к блокировке «страницы данных»!
Чтобы действительно правильно ответить на этот вопрос, потребуется больше информации о структуре таблицы и задействованных индексах, но для дальнейшего объяснения.
DOL, блокировка строк данных использует гораздо больше блокировок, чем блокировка на уровне всей страницы/страницы. Накладные расходы на управление всеми блокировками и, следовательно, уменьшение доступной памяти из-за запросов на дополнительные структуры блокировок в кэше снизят производительность и сведут на нет любые выгоды, которые вы можете получить, перейдя к более параллельному подходу.
Сначала протестируйте свой подход без перемещения на APL (блокировка всех страниц «по умолчанию»), а затем, если возникнут проблемы, перейдите на DOL (сначала страница данных, а затем строка данных). Имейте в виду, что когда вы переключаете таблицу на DOL, все ответы на этой таблице становятся немного хуже, таблица занимает больше места и становится более склонной к фрагментации, что требует регулярного обслуживания.
Короче говоря, не переходите сразу к datarows, сначала попробуйте свой подход к параллелизму, а затем, если возникнут проблемы, сначала используйте блокировку страниц данных, а затем, в крайнем случае, datarows.
Вы должны включить row level locking в таблице с помощью:
CREATE TABLE mytable (...) LOCK DATAROWS
Затем вы:
FOR UPDATE (которая заблокирует ее)Никакой другой процесс не может ничего сделать с этой строкой, пока транзакция не завершится.
П. S. Некоторые упоминают о накладных расходах, которые могут возникнуть в результате использования LOCK DATAROWS.
Да, есть накладные расходы, хотя я бы вряд ли назвал это проблемой для такого стола.
Но если вы переключитесь на DATAPAGES, вы сможете заблокировать только одну строку на PAGE (по умолчанию 2k), и процессы, строки которых находятся на одной странице, не смогут выполняться одновременно.
Если же речь идет о таблице с блокировкой сразу десятка строк, то заметного падения производительности практически не будет.
Параллелизм процессов имеет гораздо большее значение для такого дизайна.
Самый очевидный способ — это блокировка. Если в вашей базе данных нет блокировок, вы можете реализовать ее самостоятельно, добавив поле «Заблокировано».
Одним из способов упрощения параллелизма является рандомизация доступа к необработанным элементам, поэтому вместо конкуренции за первый элемент они распределяют доступ случайным образом.
Преобразуйте процедуру в один оператор SQL и обработайте несколько строк как один пакет. Вот как должны работать базы данных.
