Уровень изоляции транзакций Большое количество операций записи

Я могу говорить глупости, но:

Какой уровень изоляции является «лучшим» для множества потоков, работающих на множестве соединений, выполняющих множество обновлений и записывающих с использованием транзакций? Или уровни изоляции предназначены только для чтения?

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

поэтому параллельные записи/обновления, которые все выполняются с блокировкой базы данных --EDIT После нескольких чтений пришли к такому выводу

http://dev.mysql.com/doc/refman/5.0/en/innodb-lock-modes.html

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

NO:

t1 - T1: update (id 1) 
t2 - T2: update (id 1)

Нужно заботиться о том, чтобы два потока не обновляли одну и ту же строку... но с точки зрения базы данных, пока это InnoDB и имеет самый низкий уровень изоляции READ_UNCOMMITED, проблем быть не должно. Я приду с обновлением после пару мотыльков :D


sql transactions isolation-level
person Darwly    schedule 01.03.2012    source источник
comment
Пожалуйста, определите лучший и дайте более подробную информацию о вашей СУБД.   -  person theglauber    schedule 01.03.2012
comment
я отредактировал вопрос, если у вас есть еще вопросы, не стесняйтесь ..   -  person Darwly    schedule 01.03.2012

Ответы (1)


arrow_upward
1
arrow_downward

Эмпирическое правило: чем выше уровень изоляции (высшее значение: больше изоляции), тем больше блокировок и накладных расходов вы получаете. Поэтому, если вы хотите двигаться как можно быстрее и параллельно, вам вообще не нужна изоляция.

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

person Jens Schauder    schedule 01.03.2012
comment
хм .. Я больше думал о ПОВТОРЯЕМОМ ЧТЕНИИ .... Но в основном вы говорите, что если я использую NONE и забочусь в приложении о том, чтобы не обновлять один и тот же элемент дважды, у меня не должно возникнуть проблем? - person Darwly; 01.03.2012
comment
Почти. Если вас совершенно не волнует, видите ли вы или не видите части того, что делают другие сеансы, и когда, вы ДОЛЖНЫ быть в порядке. - person Jens Schauder; 01.03.2012
comment
Еще один вопрос: Если две транзакции из двух отдельных потоков без Isolation писать в одну таблицу, но в разные столбцы (save id 2) (update id 1), не приведет ли это к проблемам? - person Darwly; 02.03.2012
comment
Извините, не могу помочь на таком уровне детализации. Вам нужно некоторое подробное знание фактических используемых rdbms. - person Jens Schauder; 02.03.2012
comment
@Darwly - следите за тем, чтобы приложение не обновляло один и тот же элемент дважды - вы имеете в виду, что вы собираетесь повторно реализовать блокировку на более высоком уровне, и код блокировки, вероятно, не будет так тщательно протестирован, как тот, что существует внутри база данных? - person Damien_The_Unbeliever; 02.03.2012
comment
В некоторых случаях это можно сделать без блокировок, а просто на основе алгоритма, который использует приложение. - person Jens Schauder; 02.03.2012
comment
@Damien_The_Unbeliever ну да .. У меня не было бы реального механизма блокировки на уровне базы данных, только блокировка ROW при обновлении. В InnoDB это уже реализовано. Меня не волнуют показания.. так что если у меня не будет обновления на том же ROW, не будет никаких условий гонок, т.к. потоки уже заранее синхронизированы в приложении. я понятнее? Я использую это решение для своего приложения stackoverflow.com/questions/9518549/ - person Darwly; 02.03.2012