После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс!
В час ночи тушу web-сервер, чтобы никто не отвлекал mysql от работы и запускаю первый из трех необходимых DROP INDEX. Ближе к двум начинаю понимать, что процесс этот не закончится никогда. В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно для удаления остальных индексов и создания новых. Что показывал processlist все это время? Показывал он очень занимательную в контексте выполняемой задачи (напомню, удаление индекса) процедуру: копирование содержимого исходной таблицы во временную. Вот скажите мне, нахрена для удаления индекса создавать копию таблицы?
Начал разбираться и выяснил презабавнейшую вещь. Оказывается, эта поделка использует примерно такой алгоритм удаления индекса:
1. Копируем содержимое исходной таблицы во временную.
2. Создаем для временной таблицы все индексы, которые были в исходной, кроме удаляемого.
3. Замещаем исходную таблицу временной.
Оцените мощь! Для удаления трех индексов, он три раза перельет все шесть миллионов записей и три раза с нуля пересоздаст ненужные индексы. Про реальность этой операции с тридцатитрехмилионной таблицей даже думать смешно. В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц и к началу рабочего дня все уже летало.
Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
сейчас прибежит сами знаете кто и скажет что ты можешь исправить код как тебе нужно и это огромное преимущество опенсорса.
а атк ты прав, да. хотя без вещей вроде опенсорсных кодеков или линукса в моем маленьком роутере мир был бы совсем другим.
Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Ты — программист?
Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
Не надо сравнивать опенсорс и опенсорс. Есть хорошие продукты, а есть mysql. Так же как хорошие продукты есть в клозед сорс и есть в клозед сорсе какашки.
Здравствуйте, quwy, Вы писали:
Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности, ничего в этом плане не добавляющие. Но постойте ка, оказывается у MySQL есть платные тарифные планы поддержки с SLA! Хочется рулеза — платите за план поддержки 24x7, подскажут или исправят в любое время суток. И можно будет соответственно поддержке все рассказать и про студентов, и про красоту. Они там за деньги работают, все стерпят
Q>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Я думаю, не найдется человека в здравом уме, который оспорит то, что Оракле превосходит MySql практически по всем статьям... за исключением цены. Тут дело не в опенсорсе.
Здравствуйте, Sheridan, Вы писали:
S>Ты — программист? S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды?
Здравствуйте, Sheridan, Вы писали:
S>Да, и еще. S>Я уже оччень давно говорил — не трогайте мускуль, он воняет. Возьмите постгрес. S>Так нет-же. Трогают.
Здравствуйте, Testator, Вы писали:
T>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,
Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?
Здравствуйте, IID, Вы писали:
T>>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,
IID>Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?
Вряд ли энтерпрайзная MySQL удаляет индексы более гуманным образом.
Здравствуйте, quwy, Вы писали: Q>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Ну так купи Оракл и найми соответствующий персонал. Нищеброд ведь платит дважды, да?
Приветствую, Antikrot, вы писали:
A> То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды?
Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...
Здравствуйте, Sheridan, Вы писали:
A>> То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды? S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...
ты два раза повторил слово "только", и еще говоришь другим о крайностях?
кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы. и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2.
Приветствую, Antikrot, вы писали:
A> S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...
A> ты два раза повторил слово "только", и еще говоришь другим о крайностях?
Админу бы такое врядли в голову пришло. А если почитать этот форум, то легко сделать вывод, что только с программистами такое может случиться, ибо "я не админ, мне ентого ниче знать нинада"
A> кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы.
Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака.
A> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2.
Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД, написал бы скрипт, вставил бы в крон и пошел бы домой. А потом из дома, за X времени (X==время восстановления из бекапа + еще немного) до момента, когда сервант обязан быть в форме, залез бы по ssh, посмотрел как дела, и если надо — откатился бы.
И ни грамма нервов и времени бы не потратил.
Здравствуйте, Sheridan, Вы писали:
S>... и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
Здравствуйте, Sheridan, Вы писали:
S>Ты — программист? S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
Если говорить о разнице в подходах, то, имхо, всё несколько не так.
Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло.
А первый раз (удалять индекс в большой базе без бекапа) — это было... хм... да, несколько самонадеятельно.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
F>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe.
Что интересно, не обязательно. Как гарантировать то, что данные скопировались в новую базу из старой без потерь?
Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
