Показать полную графическую версию : LOCK TABLES tbl READ? READ LOCAL? LOW_PRIORITY? или WRITE?
вот с проблемой сталкнулся, нужно во время добавления в базу (порядка 5000 ++ разных insert-ов с селектами) залочить таблицы в которых модифицируется и добавляется информация, при этом те кто посещает страницу (порядка 700 000 хостов в день) должны моч читать из этих таблиц
изза большого посещения чтение более приоритетьнее, но при таком большом количестве чтений, не будет ли insert ждать вечно чтобы обработать 50 000 записей, которые делаются сразу но иногда в админке?:))
вот как залочить таблицы так, чтобы из них можно было всегда читать, а добавлять и обновлять только из потока который лочит?)
клиент и сервер субд крутятся локально,
READ, READ LOCAL, LOW_PRIORITY, или WRITE? :)
Vlad Drakula
05-08-2006, 00:25
E-mail
1) не определена база данных
2) предвижу что это MySQL, вы про описания к разным таблицам читали
3) 5000 запросов это фигня... не думаю что это займет больше нескольких минут... если все хорошо написано...
уточняю:
бд MySQL
тип MyISAM
по поводу 3) 5000 запросов это фигня... не думаю что это займет больше нескольких минут... если все хорошо написано... ты можешь себе представить 10 000 пользователей, которые ждут загрузку страницы порядка "нескольких минут"???!
Vlad Drakula
05-08-2006, 01:08
E-mail
а до этого ты писал порядка 10000хостов в день...
раз сервер держит 700000хостов значит он мощьный... значит и 5000 запросов пройдут очень быстро.. и даже если подождут одну минуту(во время минимальной нагрузки на сервер) в день не страшно... веть эти 5000 запросов не постоянно ходить будут...
Vlad Drakula я тебя не спрашиваю как держать сервер или что страшно для пользователей, понимаешь, не 5000 а 50 000 не в этом суть вопроса, алло
Vlad Drakula
05-08-2006, 09:37
E-mail
Vlad Drakula я тебя не спрашиваю как держать сервер или что страшно для пользователей, понимаешь, не 5000 а 50 000 не в этом суть вопроса, алло
суть в том что вы хотите по сути дела(посути вопроса) сделать транзакцию, а в MySQL этого нету... не тот уровень функциональности...
если можно чтобы запросы шли по раздельности то работать, а если единым блоком, то вам может понадобится сменить базу данных... по крайне это будет вполне логично в случае если вам так дороги ваши пользователи и у вас большие нагрузки...
Vlad Drakulaсуть в том что вы хотите по сути дела(посути вопроса) сделать транзакцию
нет, хочу совсем другое, то что в топе описал)
народ неужели никто не занимался лоченьем?..((
Prisoner
05-08-2006, 15:22
Может быть локинг не есть самое лучшее решение?
Опция DELAYED для команды INSERT является специфической для MySQL возможностью, которая очень полезна, если клиент не может ждать завершения команды INSERT
Подробнее... (http://mysql.com/doc/refman/4.1/en/insert-delayed.html)
Vlad Drakula
05-08-2006, 16:34
E-mail
народ неужели никто не занимался лоченьем?..((
1) для этого есть механихм разграничения прав достпупа...
2) для этого есть транзакции..
одной транзакцией всю вашу операцию(~ 5000 запросов) очень легко провернуть... и все(все что нужно) будет на время залочено...
а воотбе то алгоритм лока который вы описываете в точности похож на алгоритм работы лока в SQLite... один в один как просто процитировали...
но лок на запись одним процессов большого куска данных и на долго всегтда считалось плохим тоном... и допустимым только для исключительных и не очень частых случаев, но ни как не для регулярного использования...
может вам просто подумать о редизайне базы данных, чтобы не нужно было делать подобных действий?
Prisoner мне нужно чтобы до завершения 50000 запросов insert не было переиндексации
Vlad Drakulaно лок на запись одним процессов большого куска данных и на долго всегтда считалось плохим тоном
во время записи другие могут ЧИТАТЬ, при чем тут тон, редизайн бд, если не реализовывал лок, не томи, не надо пустого..
повторяю, мне всеголишь необходимо знать что лутше использовать READ, READ LOCAL, LOW_PRIORITY, или WRITE для LOCK TABLES tbl для моей задачи, я не ищу альтернативы этому Vlad Drakula!
E-mail
Тогда тестим и смотрим, что тебе лучше подойдет. Если ты орпределился с технологией, то бенчмарки тебе в руки, и не томи людей, в невежи запишут.
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.