Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 applock - какие последствия для производительности?  [new]
me
Member

Откуда:
Сообщений: 76
всем привет...

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

вариантов в таком случае вроде не особо много - использование applock перед серией проверок/вычислений и самим insert-ом и release applock после insert-а...

вопрос, как это повлияет на производительность в целом и есть ли какие ограничения для applock?

например, чтобы уменьшить негативный эффект ожиданий, можно было бы создавать отдельный applock для каждого уникального значения которое надо вставить (например вкючать это значение частью resource_name)... так чтоб только при попытке вставить это же самое значение - лок был уже занят и надо было ждать, а вставка всех остальных уникальных значений - проходила бы без задержек..

в таком случае, потенцияльно, может быть много одновременных локов для разных значений....
может кто уже имеет практический опыт о последствиях или ограничениях в этом случае???
6 июл 11, 22:55    [10935537]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
invm
Member

Откуда: Москва
Сообщений: 9836
Уникальный индекс с IGNORE_DUP_KEY = ON и не надо мудрить с апплоками.
7 июл 11, 00:04    [10935711]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
В том случае если OLTP база с тысячами запросов в секунду, я бы не рекомендовал использовать applocks в часто выполняемом коде. Для обычной базы с невысокой нагрузкой, на уровне несколько десятков, возможно до 100-200 запросов в секунду, использовать applocks в часто выполняемых запросах можно, если потеря нескольких миллисекунд (чаще меньше) на работу с апплоком допустима.
Applocks работают примерно как extended stored procedures, т.е. вызывают переключение контекста потока, тем самым повышая нагрузку на процессор и снижая производительность.
7 июл 11, 00:15    [10935736]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
me
Member

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

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

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

была идея использовать MERGE и по разному реагировать на WHEN MATCHED для уникальных полей и для неуникальных... но с существующей логикой, вернее опять же ее имплементацией - это выглядит гораздо более трудоемко...

к тому же MERGE тоже подвержен дубликатам хотя и в меньшей степени... так что приходится выбирать из двух зол...

от апплока я тоже не в восторге, но других вариантов пока нет...

а, еще, IGNORE_DUP_KEY = ON - тоже не вариант... потому как опять же, система навороченная и позволяет выбирать хочешь ли ты получить exception если такое значение уже есть, проапдейтить его или наоборот не трогать вообще...

еще идеи?
7 июл 11, 07:59    [10936057]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
me
Member

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

спасибо за инфо.... я понимаю, что бесплатного сыра не бывает.. потому и пытаюсь оценить последствия по возможности заранее ... и на чужом опыте... =)

нагрузку оценить сложновато, она варирует сильно... но если как вы описываете, то по идее должно быть терпимо...
правда тут будет не один апплок, а потенциально много.... но это можно еще потестировать и проверить...

а кроме апплока - какие еще варианты?
задача то довольно стандартная вроде... но пока что-то кроме апплока ничего так особо не попадалось на глаза...
7 июл 11, 08:23    [10936108]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31962
me
задача то довольно стандартная вроде... но пока что-то кроме апплока ничего так особо не попадалось на глаза...
Задача не описана.

Если это "блокировка уровня приложения", то просто делают пометку о блокировке записи в самой записи (добавив для этого флаг в запись)

Но это конечно не сочетается с :
me
логика процедуры оч извращенная и исполнение наверно могло бы быть получше, но исправлять это сейчас не представляется возможным...
Для извращённой процедуры вариант с апплоком нормальный, всё равно там будут более ограничивающие производительность факторы.
7 июл 11, 08:42    [10936170]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
me
Member

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

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

перед вставкой происходят проверки/вычисления и потом сама вставка... так что так или иначе, надо блокировать остальные потоки...

вопрос как это сделать с минимальными потерями и какие вообще есть варианты...
7 июл 11, 17:25    [10940727]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2423
me,

непонятно, а чем не устраивает простое identity ?
7 июл 11, 18:01    [10940988]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
me
Member

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

а чем оно мне поможет?

у мена табличка:
CREATE TABLE [dbo].[tblODSRecord_Demographic](
	[DemographicID] [int] NOT NULL,
	[DemographicValue] [varchar(300)] NOT NULL,
	[ODSRecordID] [int] NOT NULL,
 ) 

и проблема вставки одного и того же значения DemographicValue для только специфических DemographicID, которые клиент считает должны содержать уникальные значения...

пока попробую поиграть с хинтами и добавить повторную проверку на уникальность значения с UPDLOCK прямо непосредственно перед инсертом... по идее должно быть получше чем апплоки...

еще была мысль попробовать фильтрованный индекс, типа уникальный индекс по DemographicValue WHERE DemographicID=xxx например, но таких индексов может быть много и еще неизвестно как это скажется на производительности... но интересно...
7 июл 11, 21:37    [10941825]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31962
me
но таких индексов может быть много и еще неизвестно как это скажется на производительности
Да уж констрейн быстрее, чем делать апплоки. И несравнимо надёжнее.

В крайнем случае можно сделать проверку в триггере. Тоже лучьше, чем код в приложении.
7 июл 11, 22:02    [10941936]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
invm
Member

Откуда: Москва
Сообщений: 9836
me,

Таблица без PK? Круто.

Как-то так:
use tempdb
go
if object_id('dbo.fnIsUniqueDemographicValueRequire', 'FN') is not null
 drop function dbo.fnIsUniqueDemographicValueRequire
go
create function dbo.fnIsUniqueDemographicValueRequire
(
 @DemographicID int
)
returns tinyint
with schemabinding
as
begin
 return 1
end
go
if object_id('[dbo].[tblODSRecord_Demographic]', 'U') is not null
 drop table [dbo].[tblODSRecord_Demographic]
go
CREATE TABLE [dbo].[tblODSRecord_Demographic](
	[DemographicID] [int] NOT NULL,
	[DemographicValue] [varchar](300) NOT NULL,
	[ODSRecordID] [int] NOT NULL,
	[id] int not null identity,
	[FakeID] as case when dbo.fnIsUniqueDemographicValueRequire([DemographicID]) = 1 then [DemographicID] else [id] end persisted
	constraint [UQ__DemographicValue] unique ([FakeID], [DemographicValue])
)
go
7 июл 11, 22:45    [10942119]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
me
Member

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

нет, табличка с PK конечно и еще добавочным индексом...

клево, остроумное решение... только вот identity мне совсем не в тему...
но заманчиво...

спасибо!... буду думать... =)
7 июл 11, 23:57    [10942349]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
invm
Member

Откуда: Москва
Сообщений: 9836
me,

Данное решение неоднократно публиковалось на форуме. Если у вас есть PK, то можете попробовать приспособить его вместо identity-поля.
8 июл 11, 00:16    [10942387]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31962
me
клево, остроумное решение... только вот identity мне совсем не в тему...
но заманчиво...

спасибо!... буду думать... =)
Я бы предпочёл фильтрованный индекс. Как то это проще...
8 июл 11, 09:36    [10943150]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
me
Member

Откуда:
Сообщений: 76
похоже, решение с Identity довольно ограничено... функия для persisted column нужна deterministic, что исключает запросы к другим табличкам... так что как-то мало пользы в большинстве случаев будет...
13 июл 11, 09:38    [10965654]     Ответить | Цитировать Сообщить модератору
 Re: applock - какие последствия для производительности?  [new]
invm
Member

Откуда: Москва
Сообщений: 9836
me
похоже, решение с Identity довольно ограничено... функия для persisted column нужна deterministic, что исключает запросы к другим табличкам... так что как-то мало пользы в большинстве случаев будет...

Тогда храните признак уникальности в самой таблице и воспользуйтесь советом alexeyvg про фильтрованный уникальный индекс.
13 июл 11, 09:47    [10965688]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить