Boy Balantoy Ответов: 2

Sql server - возникнут ли проблемы, если я попытаюсь вставить данные в таблицу с помощью параллельных процессов?


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

Что я уже пробовал:

Попытался смоделировать 3 параллельных сеанса, вставляя по 10 000 уникальных записей каждый, ничего проблемного не произошло, хотя обработка идет медленнее, чем я на самом деле ожидал. Но наш производственный сервер поддерживает до 200 пользователей с ожидаемым максимальным количеством одновременных сеансов около 100, и у меня нет таких ресурсов моделирования, чтобы играть с ними, чтобы стресс-тестировать мое приложение. Надеюсь, вы могли бы помочь мне, указав правильное направление. Спасибо! :)

PIEBALDconsult

Только если ты сделаешь это неправильно.

Boy Balantoy

Извините, но я не понимаю смысла этого ответа. Не могли бы вы любезно пояснить, как я могу "сделать это неправильно"? Это было бы очень ценно.

2 Ответов

Рейтинг:
6

Wendelius

Тупик - это другое понятие. В простом случае тупик возникает, если

- пользователь а обновляет строку 11 в таблице 1
- пользователь B обновляет строку 22 в таблице 2
- пользователь B пытается обновить строку 11 в таблице 1. Теперь он должен ждать, потому что строка заблокирована пользователем A
- пользователь а пытается обновить строку 22 в таблице 2. Теперь он должен ждать, потому что строка заблокирована пользователем B

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

Что же касается самого вопроса. Если вы вставляете в таблицу, у вас не должно быть никаких проблем, даже если несколько пользователей вставляют в одну и ту же таблицу одновременно. Это распространенный сценарий в базах данных.

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

Большинство потенциальных проблем связано с ресурсами на стороне сервера. Поэтому обеспечение адекватности ресурсов (памяти, процессора, скорости диска...) должно решить большинство вопросов. Если операции в основном являются обновлениями, будьте осторожны с количеством индексов, не переиндексируйте, если это действительно не нужно.

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


Boy Balantoy

Спасибо за это, приятель. Действительно ценить. :)

Рейтинг:
18

Dave Kreskowiak

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

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