MySQL параллельные запросы на изменение

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

В результате если основной процесс, работающий с СУБД вносит записи, то при выполнении сколько-нибудь продолжительного запроса (хотя бы 10-20-30 минут), связанного с изменением рабочих таблиц его работа фактически блокируется.

Можно ликак-то решить эту проблему оставаясь в рамках выбранной СУБД?

Anarchist пишет:В

Anarchist написал(а):
В умных книжках пишут, что во имя производительности Мускул использует блокировку таблиц, и что пока один пишет - остальные могут только читать

К производительности это отношение имеет довольно косвенное, по-моему.

Цитата:
В результате если основной процесс, работающий с СУБД вносит записи, то при выполнении сколько-нибудь продолжительного запроса (хотя бы 10-20-30 минут), связанного с изменением рабочих таблиц его работа фактически блокируется.

Ничего себе у вас там запросы (-:Е

Цитата:
Можно ликак-то решить эту проблему оставаясь в рамках выбранной СУБД?

Используйте таблицы типа InnoDB вместо MyISAM. У них блокировка построчная. Собственно, в доках примерно это и написано


Пожалуйста, не описывайте своё железо в подписи

?

krigstask написал(а):
К производительности это отношение имеет довольно косвенное, по-моему.

А по-моему - оно в существенной степени зависит от того какая база (структура и размер) и как с ней работать (структура запросов и нагрузка).

krigstask написал(а):
Ничего себе у вас там запросы (-:Е

Обычные запросы. Когда табличка весит гигабайты - ИМХО нормально.

krigstask написал(а):
Используйте таблицы типа InnoDB вместо MyISAM. У них блокировка построчная. Собственно, в доках примерно это и написано

Собственно, на этот вариант я и смотрел.
Посмотрим, что получится.

--
Live free or die

ы

Anarchist написал(а):
krigstask написал(а):
К производительности это отношение имеет довольно косвенное, по-моему.

А по-моему - оно в существенной степени зависит от того какая база (структура и размер) и как с ней работать (структура запросов и нагрузка)

Э-э-э... Ну да. Я разве противоречу?

Цитата:
Обычные запросы. Когда табличка весит гигабайты - ИМХО нормально.

Ну, в общем, да (-:Е

Цитата:
Собственно, на этот вариант я и смотрел.
Посмотрим, что получится.

МОгу посоветовать глянуть сюда: http://www.samag.ru/cgi-bin/go.pl?q=articles;n=07.2007;a=02
Там не только PostgreSQL с MySQL, но и разные типы таблиц мускулёвых


Пожалуйста, не описывайте своё железо в подписи

А не подскажешь

А не подскажешь алгоритм переноса данных (база стабилизировалась на ~4.3 Gb) из MyISAM в InnoDB (поправить тип таблиц в дампе - вылетает по ошибке синтаксиса, при попытке вывода содержимого части таблиц mysql вылетает: памяти ему мало, как натравить mysqldump на отдельную таблицу пока не понял).
--
Live free or die

Не подскажу —

Не подскажу — не помню, сам сейчас с PostgreSQL работаю.

Цитата:
поправить тип таблиц в дампе - вылетает по ошибке синтаксиса

Хм. Покажи, как делаешь, авось вспомню (-:Е


Пожалуйста, не описывайте своё железо в подписи

а так?

ALTER TABLE `xxx` ENGINE = InnoDB
не работает?

или вставками можно, вот вообще: http://dev.mysql.com/doc/refman/5.0/en/converting-tables-to-innodb.html

:(

krigstask написал(а):
Используйте таблицы типа InnoDB вместо MyISAM. У них блокировка построчная. Собственно, в доках примерно это и написано

Складывается нехорошее подозрение, что InnoDB с посторочной блокировкой тормозит как MyISAM с табличной блокировкой уже на примерно вшестеро меньшем размере базы :(

Эх, была ведь мысль завязываться сразу на Постгрес...
--
Live free or die

павпва

Anarchist написал(а):
Складывается нехорошее подозрение, что InnoDB с посторочной блокировкой тормозит как MyISAM с табличной блокировкой уже на примерно вшестеро меньшем размере базы :(

Неужели так круто? \-:Е

Цитата:
Эх, была ведь мысль завязываться сразу на Постгрес...

Что, совсем уже завязались? Вроде перейти не так и долго...


Пожалуйста, не описывайте своё железо в подписи

А что вы хотели?

А что вы хотели? Если у вас есть запросы на модификацию, которые длятся по 10-20-30 минут, то тут ничего не сделаешь, производить две модицикации одновременно невозможно. На сегодняшний день существует следуюшие варианты:
1) При модификации отношение целиком блокируется. Именно целиком, если блокировка построчная, то другой процесс может изменить строку так, что первый вроде бы как и не должен её менять, но у него это уже заложено, или наоборот, пропустить строку, которую надо поменять.
2) Использовать транзакции. Тогда возможно одновременное выполнение произвольного числа запросов. Только надо учитывать, что в случае конфликта, например попытка модификации одного значений двумя транзакциями приведет к авайному останову одной из них. Т.е. в результате того, что кто-то чуток поменяет базу ваша 20 минутная транзакция может ёкнуться на 29 минуте.
3) Блокировки построчные. Работать будет быстрее, однако то, что после операции СУБД будет в том состоянии, в котором вы ожидали гарантировать нельзя. Например после UPDATE aaa SET bbb=1 WHERE bbb=0 не герентировано отсутсвие нулевых значений в bbb/
3) Отключить блокировки нафиг. Работать будет совсем быстро, однако в такос случае СУБД не может гарантировать чего-либо. Вообще чего-либо, даже сохранности данных.

Всего и побольше и можно без хлеба

KiberGus написал(а):
А что вы хотели?

Дык, этого самого, чтобы работало быстро и как надо :)

KiberGus написал(а):
Если у вас есть запросы на модификацию, которые длятся по 10-20-30 минут

Час-два-три...

KiberGus написал(а):
то тут ничего не сделаешь, производить две модицикации одновременно невозможно.

Этот ответ соответствует общему случаю.
Который меня интересует постолько поскольку. Не более.

В моём частно-конкретном случае: DELETE для старых записей, обращения к которым давно не производилось и INSERT/UPDATE для относительно свежих - ИМХО вполне решаемо.

KiberGus написал(а):
3) Блокировки построчные. Работать будет быстрее, однако то, что после операции СУБД будет в том состоянии, в котором вы ожидали гарантировать нельзя. Например после UPDATE aaa SET bbb=1 WHERE bbb=0 не герентировано отсутсвие нулевых значений в bbb/

То, что нужно.

--
Live free or die

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".