импортировались записи блоками разных размеров, 1000, 5000, 10000, 25000 и 50000, выходило, что чем меньше размер пакета данных, тем больше времени затрачивается на заливку данных.
Пробовалось как на InnoDB так и на MyISAM. На последнем при отключенной перестройке индексов скорость была выше, норазница сохранялась.
Точных цифр не скажу, так как было это больше полугода назад, но переход на генерацию sql-файла и его заливку вместо прямой передачи генерируемых данных в БД уменьшил время заливки данных в БД на порядок, а переход с sql-файла на CSV и LOAD DATA INFILE ещё на 30%.
Причём, чем больше необходимо залить данных, тем ощутимее становится разница.
это проверялось на практике при вставке 800 с чем-то там тысяч записей…
но даже если просто логически подойти к этому вопросу, то получается 10 000 запросов, а это 10 000 разборов запроса, 10 000 — 1 ожиданий для каждого следующего запроса пока выполнится предыдущий, не говоря уже о затратах на межпроцессное взаимодействие при передаче данных.
Ну почему же, в такой вставке нет ничего страшного. Просто лучше в таком случае генерировать sql-код в файл, разбивая данные на достаточно большие insert-кусочки, чтобы каждый из них умещался в query-буфер и заливать целиком этот файл, хотя как показала практика — заливка csv с данными с помощью LOAD DATA INFILE работает в разы быстрее.
И снова спасибо за статью, лакончинчно и доступно. :)
главное пишите на конкретных примерах, где по миллиону записей в одной табличке, и чтобы каждый мог проверить приведите пример sql запросика (или хранимки), который позволит нагенерить эти данные, будэ кому захочется проверить =)
С нетерпением ждём )))
Вообще, было бы интересно почитать ваше мнение на тему правильного подхода к выбору индексов для сложных запросов, когда джоинятся не две, а 3-4 и более таблиц и анализе плана выполнения таких запросов, т.е. как правильно понять что имеет ввиду explain :)
исправьте опечаточку
«также тормозят наши изменения дЫнных (UPDATE, INSERT, DELETE)»
и недопечаточку
«так вот, некоторые думаю, что MySQL сделает следующее „
ну я склонен считать, что дело в преподавательском подходе. Врят ли человек может заинтересоваться профессией если преподаватель преподносит информацию так, как будто сам он водитель-дальнобойщик, а семинар по ИТ ведёт для подработки.
Походить по собеседованиям самый лучший вариант. Не взяли на работу? не трагедия — им же хуже. Цените себя и не принимайте близко к сердцу отказы. Отрицательный опыт — это тоже опыт.
ситуация однако местами ещё хуже, я наблюдал студентов ITшников, которые жутко бояться сделать что-то неправильно и в итоге ничего не делают, как будто их за ошибку выданную компилятором будут бить ногами. Хотя тут скорее дело в преподавательском подходе, когда IT преподаётся без «огонька».
И это хорошо. Разочарование в выбранной профессии не конец света, увы, не все это понимают. Жалуются, нопродолжают кушать этот кактус.
Очень многие молодые специалисты почему-то испытывают суеверный страх перед выбором профессии, почму то считая, что приковывают себя этим выбором раз и навсегда. К счастью, большинство с опытом понимает, что нет ничего страшного сменить направление деятельности разок-другой в год.
а человек мучается сам и мучает окружающих коллег, хотя это совсем уж крайний случай.
В целом, человек может постичь любую область, вопрос в мотивации и наличия объекта применения знаний, так как сколько угодно можно учить Haskell, но теория без реальной практики не даст плодов.
Согласен с вашим имхо, веб-сайт это просто пример пришедший в голову, список может быть огромным и чем он больше тем лучше.
Это прекрасно, что уже к концу школы вы знали, что вам интересно и в какой области. Тут же сделана попытка придумать что-то такое, что могло бы помочь в выборе отрасли и направления в рамках отрасли. И не заумными словами, а так, что называется «на пальцах».
Может в ком-то пропадает прекрасный сантехник, а он вместо этого клавиши топчет, тогда как на сантехнических работах мог бы получать гораздо больше и денег и удовольствия. =)
Пробовалось как на InnoDB так и на MyISAM. На последнем при отключенной перестройке индексов скорость была выше, норазница сохранялась.
Точных цифр не скажу, так как было это больше полугода назад, но переход на генерацию sql-файла и его заливку вместо прямой передачи генерируемых данных в БД уменьшил время заливки данных в БД на порядок, а переход с sql-файла на CSV и LOAD DATA INFILE ещё на 30%.
Причём, чем больше необходимо залить данных, тем ощутимее становится разница.
но даже если просто логически подойти к этому вопросу, то получается 10 000 запросов, а это 10 000 разборов запроса, 10 000 — 1 ожиданий для каждого следующего запроса пока выполнится предыдущий, не говоря уже о затратах на межпроцессное взаимодействие при передаче данных.
И снова спасибо за статью, лакончинчно и доступно. :)
С нетерпением ждём )))
исправьте опечаточку
«также тормозят наши изменения дЫнных (UPDATE, INSERT, DELETE)»
и недопечаточку
«так вот, некоторые думаю, что MySQL сделает следующее „
p. s. не сомневаюсь, но интереснее попробовать секиру, лишь бы не отрубить себе чего )))
Очень многие молодые специалисты почему-то испытывают суеверный страх перед выбором профессии, почму то считая, что приковывают себя этим выбором раз и навсегда. К счастью, большинство с опытом понимает, что нет ничего страшного сменить направление деятельности разок-другой в год.
В целом, человек может постичь любую область, вопрос в мотивации и наличия объекта применения знаний, так как сколько угодно можно учить Haskell, но теория без реальной практики не даст плодов.
успехов вам! надеюсь, поделитесь потом что получилось, так как очень много IT-шников, да и не только, мучаются с подобными вопросами.
Это прекрасно, что уже к концу школы вы знали, что вам интересно и в какой области. Тут же сделана попытка придумать что-то такое, что могло бы помочь в выборе отрасли и направления в рамках отрасли. И не заумными словами, а так, что называется «на пальцах».
Может в ком-то пропадает прекрасный сантехник, а он вместо этого клавиши топчет, тогда как на сантехнических работах мог бы получать гораздо больше и денег и удовольствия. =)