MySQL параллельные запросы на изменение
Anarchist 21 июля, 2008 - 15:39
В умных книжках пишут, что во имя производительности Мускул использует блокировку таблиц, и что пока один пишет - остальные могут только читать. Либо ждут.
В результате если основной процесс, работающий с СУБД вносит записи, то при выполнении сколько-нибудь продолжительного запроса (хотя бы 10-20-30 минут), связанного с изменением рабочих таблиц его работа фактически блокируется.
Можно ликак-то решить эту проблему оставаясь в рамках выбранной СУБД?
»
- Для комментирования войдите или зарегистрируйтесь
Anarchist пишет:В
К производительности это отношение имеет довольно косвенное, по-моему.
Ничего себе у вас там запросы (-:Е
Используйте таблицы типа InnoDB вместо MyISAM. У них блокировка построчная. Собственно, в доках примерно это и написано
Пожалуйста, не описывайте своё железо в подписи
?
А по-моему - оно в существенной степени зависит от того какая база (структура и размер) и как с ней работать (структура запросов и нагрузка).
Обычные запросы. Когда табличка весит гигабайты - ИМХО нормально.
Собственно, на этот вариант я и смотрел.
Посмотрим, что получится.
--
Live free or die
ы
Э-э-э... Ну да. Я разве противоречу?
Ну, в общем, да (-:Е
МОгу посоветовать глянуть сюда: 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
:(
Складывается нехорошее подозрение, что InnoDB с посторочной блокировкой тормозит как MyISAM с табличной блокировкой уже на примерно вшестеро меньшем размере базы :(
Эх, была ведь мысль завязываться сразу на Постгрес...
--
Live free or die
павпва
Неужели так круто? \-:Е
Что, совсем уже завязались? Вроде перейти не так и долго...
Пожалуйста, не описывайте своё железо в подписи
А что вы хотели?
А что вы хотели? Если у вас есть запросы на модификацию, которые длятся по 10-20-30 минут, то тут ничего не сделаешь, производить две модицикации одновременно невозможно. На сегодняшний день существует следуюшие варианты:
1) При модификации отношение целиком блокируется. Именно целиком, если блокировка построчная, то другой процесс может изменить строку так, что первый вроде бы как и не должен её менять, но у него это уже заложено, или наоборот, пропустить строку, которую надо поменять.
2) Использовать транзакции. Тогда возможно одновременное выполнение произвольного числа запросов. Только надо учитывать, что в случае конфликта, например попытка модификации одного значений двумя транзакциями приведет к авайному останову одной из них. Т.е. в результате того, что кто-то чуток поменяет базу ваша 20 минутная транзакция может ёкнуться на 29 минуте.
3) Блокировки построчные. Работать будет быстрее, однако то, что после операции СУБД будет в том состоянии, в котором вы ожидали гарантировать нельзя. Например после UPDATE aaa SET bbb=1 WHERE bbb=0 не герентировано отсутсвие нулевых значений в bbb/
3) Отключить блокировки нафиг. Работать будет совсем быстро, однако в такос случае СУБД не может гарантировать чего-либо. Вообще чего-либо, даже сохранности данных.
Всего и побольше и можно без хлеба
Дык, этого самого, чтобы работало быстро и как надо :)
Час-два-три...
Этот ответ соответствует общему случаю.
Который меня интересует постолько поскольку. Не более.
В моём частно-конкретном случае: DELETE для старых записей, обращения к которым давно не производилось и INSERT/UPDATE для относительно свежих - ИМХО вполне решаемо.
То, что нужно.
--
Live free or die