Здравствуйте, frogkiller, Вы писали:
S>>Ты — программист? S>>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
F>Если говорить о разнице в подходах, то, имхо, всё несколько не так. F>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
на кой черт? копия и так в бекапе. или вообще ничего не бекапится?
F>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло.
это только я не заметил где там в "получилось в итоге" про создание новой *базы*?
В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи.
Q>В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно
Q>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц
Я, наверное, очень тупой. Но не противоречат ли эти два предложения сами себе?
Здравствуйте, Vamp, Вы писали:
F>>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. V>Что интересно, не обязательно. Как гарантировать то, что данные скопировались в новую базу из старой без потерь?
Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
F>Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты.
А что, можно вот так просто посчитать crc таблицы?
Приветствую, andrey.desman, вы писали:
a> S>... и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
a> Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
Да, я иногда умею завернуть так, что даже самому потом непонятно что хотел сказать
Здравствуйте, Antikrot, Вы писали:
F>>Если говорить о разнице в подходах, то, имхо, всё несколько не так. F>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой. A>на кой черт? копия и так в бекапе. или вообще ничего не бекапится?
Бекап — отдельная сущность, создаётся независимо от изменений.
"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция.
F>>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло. A>это только я не заметил где там в "получилось в итоге" про создание новой *базы*? A>
A>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи.
Да, я тут ошибся. Почему-то подумал, что создавалась новая база, а не таблица.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Vamp, Вы писали:
F>>Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты. V>А что, можно вот так просто посчитать crc таблицы?
Э... а что — нельзя? Даже как crc от массива байт, полученного простой конкатенацией строк?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Sheridan, Вы писали:
A>> S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей... A>> ты два раза повторил слово "только", и еще говоришь другим о крайностях? S>Админу бы такое врядли в голову пришло. А если почитать этот форум, то легко сделать вывод, что только с программистами такое может случиться, ибо "я не админ, мне ентого ниче знать нинада"
я правильно понял, что практически все админы знают как [через жопу] внутри mysql сделано удаление индексов?
A>> кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы. S>Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака.
ну может хоть ты расскажешь где там что вытаскивалось?
A>> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2. S>Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи
а много тут способов решения задачи?
кроме того, ты тут противоречишь вот этой твоей же фразе:
вместо того чтобы сделать сразу так, как как было сделано в итоге
S>, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД,
о как. интересно как бы ты прикинул. знаешь сложность алгоритма переиндексации в конкретной СУБД?
S>написал бы скрипт, вставил бы в крон и пошел бы домой. А потом из дома, за X времени (X==время восстановления из бекапа + еще немного) до момента, когда сервант обязан быть в форме, залез бы по ssh, посмотрел как дела, и если надо — откатился бы. S>И ни грамма нервов и времени бы не потратил.
а что не "скопировать базу на другой сервер, удалить там индексы, остановить боевой сервер, скопировать почищенную от индексов базу с рабочего на боевой сервер"?
Здравствуйте, frogkiller, Вы писали:
F>>>Если говорить о разнице в подходах, то, имхо, всё несколько не так. F>>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой. A>>на кой черт? копия и так в бекапе. или вообще ничего не бекапится? F>Бекап — отдельная сущность, создаётся независимо от изменений. F>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция.
вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.
Приветствую, Antikrot, вы писали:
A> я правильно понял, что практически все админы знают как [через жопу] внутри mysql сделано удаление индексов?
Нет. Но все знают что с мускулем надо вести себя осторожно.
A> S>Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака. A> ну может хоть ты расскажешь где там что вытаскивалось?
В том то и дело что нет. Это ты меня хотел обвинить в том что я таблицу от базы не отличу.
A> A>> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2. A> S>Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи A> а много тут способов решения задачи?
Как минимум два Плюс вариации.
A> кроме того, ты тут противоречишь вот этой твоей же фразе: A>
A> вместо того чтобы сделать сразу так, как как было сделано в итоге
Учись читать смысл а не буквы.
A> S>, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД, A> о как. интересно как бы ты прикинул. знаешь сложность алгоритма переиндексации в конкретной СУБД?
Ты видел слова "поэкспериментировал бы"? Или читаешь с пятого на десятое?
A> а что не "скопировать базу на другой сервер, удалить там индексы, остановить боевой сервер, скопировать почищенную от индексов базу с рабочего на боевой сервер"?
При наличии последнего бэкапа и выверенном экспериментально методе сие теряет смысл, ибо рубануться все может только при форсмажоре. Плюс быстрее отработает.
Но можно конечно и этот вариант, я не против. Главное тут — предварительно подумать и поэкспериментировать.
Здравствуйте, Antikrot, Вы писали:
F>>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция. A>вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.
Не на время работы с копией, а в процессе переключения со старой на новую. От этого практически никуда не деться, разве только какими-то внешними средствами, которые "придержат" все пользовательские запросы на время переключения, а потом отправят их новой базе. Разумеется, "гасить" старую базу желательно уже после подъёма новой. Для пользователей весь процесс может быть практически неотличим от, например, сетевых ретрансмитов.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Sheridan, Вы писали:
A>> я правильно понял, что практически все админы знают как [через жопу] внутри mysql сделано удаление индексов? S>Нет. Но все знают что с мускулем надо вести себя осторожно.
блин, а г#вна то сколько из-за этого мускуля вылили на оракл...
A>> S>Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака. A>> ну может хоть ты расскажешь где там что вытаскивалось? S>В том то и дело что нет. Это ты меня хотел обвинить в том что я таблицу от базы не отличу.
хотел, но не обвинил )) высказал подозрения.
рассмотрим подробнее:
Вариант А ("только программисту могла прийти в голову идея такое вытворять"):
на боевой базе (отключенной от вебсервера):
DROP INDEX
=> 1. копируется содержимое (данные) во временную таблицу
=> 2. во временной создаются индексы \ тот что не нужен
=> 3. основная таблица замещается временной
повторить три раза
Вариант B ("сделать сразу так"):
на боевой базе (отключенной от вебсервера):
1. создается временная таблица и индексы \ те что не нужны
2. переливаются данные
2. замещение таблицы
ну и где разница, кроме тормозов из-за хренового мускуля?
A>> кроме того, ты тут противоречишь вот этой твоей же фразе: A>>
A>> вместо того чтобы сделать сразу так, как как было сделано в итоге
S>Учись читать смысл а не буквы.
учись писать так, чтобы не надо было распространять свой СПГСна других
смысл в том, что нет по сути (но есть по производительности) разницы в методе, который ты назвал эксклюзивным для программистов, и тем, который был сделан в итоге и признан тобой правильным.
A>> S>, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД, A>> о как. интересно как бы ты прикинул. знаешь сложность алгоритма переиндексации в конкретной СУБД? S>Ты видел слова "поэкспериментировал бы"? Или читаешь с пятого на десятое?
видел. и выразил большое сомнение, что ты (да и не принципиально кто) сможет правильно интерполировать экспериментальные данные с "подрезанной на порядок базы" на полную базу. сколько экспериментов надо, чтобы выявить квадратичную зависимость? а если там меняется что по достижению пороговых значений?
Здравствуйте, quwy, Вы писали:
Q> Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Кстати претензии к компании Oracle. Как Oracle DB, так и MySQL — это сейчас продукты этой компании. Требуйте у них разъяснений почему они делают разные продукты с разными лицензиями, разными ценами и разным набором функционала.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Testator, Вы писали:
T>>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,
IID>Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?
Судите самостоятельно:
— Продукт очевидно используется в довольно жестком production режиме, где время на поиск и устранение всяких проблем ограничено.
— Время от времени требуется поддержка от производителя, т.к. продукт сложный.
— Для продукта кроме обычной GPL есть доступные планы поддержки, где в соглашении прописан SLA.
Вопрос: а не ССЗБ ли тот кто пользует неподходящий для него вариант лицензии, и жалуется на проблему с продуктом в rsdn, вместо того чтобы купить поддержку и жаловаться непосредственно производителю?
Вопрос №2: чем по-вашему в указанном случае продукт с GPL отличается от продукта с другой лицензией не предусматривающей поддержки с SLA? И что конкретно GPL содержит такого особенного по отношению к внутренним особенностям ПО, что позволяет применять квантор всеобщности с какими-то свойствами к сущности под названием "GPL продукты"?
T>Судите самостоятельно: T>- Продукт очевидно используется в довольно жестком production режиме, где время на поиск и устранение всяких проблем ограничено. T>- Время от времени требуется поддержка от производителя, т.к. продукт сложный. T>- Для продукта кроме обычной GPL есть доступные планы поддержки, где в соглашении прописан SLA.
T>Вопрос: а не ССЗБ ли тот кто пользует неподходящий для него вариант лицензии, и жалуется на проблему с продуктом в rsdn, вместо того чтобы купить поддержку и жаловаться непосредственно производителю?
Я бы поставил вопрос более конструктивно — не разумнее ли нанять приходящего специалиста для таких дел — администратора БД?
Здравствуйте, quwy, Вы писали:
Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Ну видно же по описанию, что у тебя используется MyISAM, который, если кто помнит, транзакции не держал (или до сих не держит). Использовал бы InnoDB (который для больших баз рекомендуется) проблемы бы не было.
Так что в чистом виде ССЗБ...
P.S. На Oracle-то денег хватит? Явно тебе ведь не хватит Express Edition.
P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Здравствуйте, quwy, Вы писали:
VV>Не надо сравнивать опенсорс и опенсорс. Есть хорошие продукты, а есть mysql.
MySQL — хороший продукт. Просто имеет границы применимости.
Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD.
Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
Плюс вариации.
