О рулезности опенсорса на примере mysql
От: quwy  
Дата: 02.03.10 17:03
Оценка: +1 -1
После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс!

В час ночи тушу web-сервер, чтобы никто не отвлекал mysql от работы и запускаю первый из трех необходимых DROP INDEX. Ближе к двум начинаю понимать, что процесс этот не закончится никогда. В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно для удаления остальных индексов и создания новых. Что показывал processlist все это время? Показывал он очень занимательную в контексте выполняемой задачи (напомню, удаление индекса) процедуру: копирование содержимого исходной таблицы во временную. Вот скажите мне, нахрена для удаления индекса создавать копию таблицы?

Начал разбираться и выяснил презабавнейшую вещь. Оказывается, эта поделка использует примерно такой алгоритм удаления индекса:
1. Копируем содержимое исходной таблицы во временную.
2. Создаем для временной таблицы все индексы, которые были в исходной, кроме удаляемого.
3. Замещаем исходную таблицу временной.

Оцените мощь! Для удаления трех индексов, он три раза перельет все шесть миллионов записей и три раза с нуля пересоздаст ненужные индексы. Про реальность этой операции с тридцатитрехмилионной таблицей даже думать смешно. В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц и к началу рабочего дня все уже летало.

Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Re: О рулезности опенсорса на примере mysql
От: squid  
Дата: 02.03.10 17:46
Оценка:
Здравствуйте, quwy, Вы писали:

сейчас прибежит сами знаете кто и скажет что ты можешь исправить код как тебе нужно и это огромное преимущество опенсорса.

а атк ты прав, да. хотя без вещей вроде опенсорсных кодеков или линукса в моем маленьком роутере мир был бы совсем другим.

Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Re: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 02.03.10 17:59
Оценка: -18 :))) :))) :)
Ты — программист?
Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 02.03.10 18:02
Оценка: +2 -3
Да, и еще.
Я уже оччень давно говорил — не трогайте мускуль, он воняет. Возьмите постгрес.
Так нет-же. Трогают.

А потом опенсорц виноват, ага.
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re: О рулезности опенсорса на примере mysql
От: vladimir.vladimirovich США  
Дата: 02.03.10 18:04
Оценка:
Здравствуйте, quwy, Вы писали:

Не надо сравнивать опенсорс и опенсорс. Есть хорошие продукты, а есть mysql. Так же как хорошие продукты есть в клозед сорс и есть в клозед сорсе какашки.
Re: О рулезности опенсорса на примере mysql
От: Testator Россия  
Дата: 02.03.10 18:11
Оценка: +4 -2
Здравствуйте, quwy, Вы писали:

Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.


А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности, ничего в этом плане не добавляющие. Но постойте ка, оказывается у MySQL есть платные тарифные планы поддержки с SLA! Хочется рулеза — платите за план поддержки 24x7, подскажут или исправят в любое время суток. И можно будет соответственно поддержке все рассказать и про студентов, и про красоту. Они там за деньги работают, все стерпят
▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬
Мы — то, во что верим.
Re: О рулезности опенсорса на примере mysql
От: Vamp Россия  
Дата: 02.03.10 19:27
Оценка: 1 (1) +1
Q>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Я думаю, не найдется человека в здравом уме, который оспорит то, что Оракле превосходит MySql практически по всем статьям... за исключением цены. Тут дело не в опенсорсе.
Да здравствует мыло душистое и веревка пушистая.
Re[2]: О рулезности опенсорса на примере mysql
От: Antikrot  
Дата: 02.03.10 20:14
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ты — программист?

S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.
То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды?
Re[2]: О рулезности опенсорса на примере mysql
От: Sharowarsheg  
Дата: 02.03.10 20:25
Оценка: 3 (1) :)
Здравствуйте, Sheridan, Вы писали:

S>Да, и еще.

S>Я уже оччень давно говорил — не трогайте мускуль, он воняет. Возьмите постгрес.
S>Так нет-же. Трогают.

После этого от опенсорца остается один апач.
Re[2]: О рулезности опенсорса на примере mysql
От: IID Россия  
Дата: 02.03.10 20:30
Оценка: -1
Здравствуйте, Testator, Вы писали:

T>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,


Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?
kalsarikännit
Re[3]: О рулезности опенсорса на примере mysql
От: Roman Odaisky Украина  
Дата: 02.03.10 20:42
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>После этого от опенсорца остается один апач.


nginx — наше всё!
До последнего не верил в пирамиду Лебедева.
Re[3]: О рулезности опенсорса на примере mysql
От: Roman Odaisky Украина  
Дата: 02.03.10 20:43
Оценка: +4
Здравствуйте, IID, Вы писали:

T>>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,


IID>Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?


Вряд ли энтерпрайзная MySQL удаляет индексы более гуманным образом.
До последнего не верил в пирамиду Лебедева.
Re: О рулезности опенсорса на примере mysql
От: Mr.Cat  
Дата: 02.03.10 20:58
Оценка: :))
Здравствуйте, quwy, Вы писали:
Q>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.
Ну так купи Оракл и найми соответствующий персонал. Нищеброд ведь платит дважды, да?
Re[3]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 02.03.10 21:02
Оценка: :))
Приветствую, Antikrot, вы писали:

A> То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды?


Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[4]: О рулезности опенсорса на примере mysql
От: Antikrot  
Дата: 02.03.10 21:14
Оценка:
Здравствуйте, Sheridan, Вы писали:

A>> То есть ты *всегда*, независимо от СУБД, ни при каких условиях не используешь команду drop index, а будешь создавать новую таблицу и таскать туда записи, даже при том что приличные СУБД (даже упомянуто было какие) делают то что нужно за секунды?

S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...
ты два раза повторил слово "только", и еще говоришь другим о крайностях?
кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы. и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2.
Re[3]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 02.03.10 21:32
Оценка:
Приветствую, IID, вы писали:

IID> Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?


Нет, ты правильно понимаешь лишь вторую часть своего предложения.
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[5]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 02.03.10 22:02
Оценка:
Приветствую, Antikrot, вы писали:

A> S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...


A> ты два раза повторил слово "только", и еще говоришь другим о крайностях?

Админу бы такое врядли в голову пришло. А если почитать этот форум, то легко сделать вывод, что только с программистами такое может случиться, ибо "я не админ, мне ентого ниче знать нинада"

A> кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы.

Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака.

A> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2.

Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД, написал бы скрипт, вставил бы в крон и пошел бы домой. А потом из дома, за X времени (X==время восстановления из бекапа + еще немного) до момента, когда сервант обязан быть в форме, залез бы по ssh, посмотрел как дела, и если надо — откатился бы.
И ни грамма нервов и времени бы не потратил.
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[2]: О рулезности опенсорса на примере mysql
От: andrey.desman  
Дата: 02.03.10 22:04
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>... и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.


Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.
Re[2]: О рулезности опенсорса на примере mysql
От: frogkiller Россия  
Дата: 02.03.10 22:05
Оценка: 1 (1)
Здравствуйте, Sheridan, Вы писали:

S>Ты — программист?

S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.

Если говорить о разнице в подходах, то, имхо, всё несколько не так.

Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.

Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло.

А первый раз (удалять индекс в большой базе без бекапа) — это было... хм... да, несколько самонадеятельно.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[3]: О рулезности опенсорса на примере mysql
От: Vamp Россия  
Дата: 02.03.10 22:09
Оценка:
F>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe.
Что интересно, не обязательно. Как гарантировать то, что данные скопировались в новую базу из старой без потерь?
Да здравствует мыло душистое и веревка пушистая.
Re[3]: О рулезности опенсорса на примере mysql
От: Antikrot  
Дата: 02.03.10 22:12
Оценка:
Здравствуйте, frogkiller, Вы писали:

S>>Ты — программист?

S>>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.

F>Если говорить о разнице в подходах, то, имхо, всё несколько не так.

F>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
на кой черт? копия и так в бекапе. или вообще ничего не бекапится?

F>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло.

это только я не заметил где там в "получилось в итоге" про создание новой *базы*?

В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи.

Re: О рулезности опенсорса на примере mysql
От: Vamp Россия  
Дата: 02.03.10 22:12
Оценка: -1
Q>В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно

Q>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц


Я, наверное, очень тупой. Но не противоречат ли эти два предложения сами себе?
Да здравствует мыло душистое и веревка пушистая.
Re[4]: О рулезности опенсорса на примере mysql
От: frogkiller Россия  
Дата: 02.03.10 22:15
Оценка:
Здравствуйте, Vamp, Вы писали:

F>>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe.

V>Что интересно, не обязательно. Как гарантировать то, что данные скопировались в новую базу из старой без потерь?

Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[5]: О рулезности опенсорса на примере mysql
От: Vamp Россия  
Дата: 02.03.10 22:19
Оценка:
F>Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты.
А что, можно вот так просто посчитать crc таблицы?
Да здравствует мыло душистое и веревка пушистая.
Re[3]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 02.03.10 22:22
Оценка: :))
Приветствую, andrey.desman, вы писали:

a> S>... и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.


a> Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.


Да, я иногда умею завернуть так, что даже самому потом непонятно что хотел сказать
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[4]: О рулезности опенсорса на примере mysql
От: frogkiller Россия  
Дата: 02.03.10 22:22
Оценка:
Здравствуйте, Antikrot, Вы писали:

F>>Если говорить о разнице в подходах, то, имхо, всё несколько не так.

F>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
A>на кой черт? копия и так в бекапе. или вообще ничего не бекапится?

Бекап — отдельная сущность, создаётся независимо от изменений.
"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция.

F>>Подход программиста — такой как получилось в итоге: создать новую базу, в ней что-то сделать, заменить старую новой — все эти операции exception safe. И, кстати, это принципиально ничем не отличается от того, что сделано в mysql. Ну так получилось, что сделать новую базу оказалось проще, чем таблицу в старой — можно сказать, что просто не повезло.

A>это только я не заметил где там в "получилось в итоге" про создание новой *базы*?
A>

A>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи.


Да, я тут ошибся. Почему-то подумал, что создавалась новая база, а не таблица.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[5]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 02.03.10 22:25
Оценка:
Приветствую, frogkiller, вы писали:

f> Для данных — элементарно — сравнить crc/md5/...

Довольно длительная операция имхо получится...
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[6]: О рулезности опенсорса на примере mysql
От: frogkiller Россия  
Дата: 02.03.10 22:26
Оценка:
Здравствуйте, Vamp, Вы писали:

F>>Для данных — элементарно — сравнить crc/md5/... Для индексов — чуть сложнее, но наверняка и для них есть какие-то инварианты.

V>А что, можно вот так просто посчитать crc таблицы?

Э... а что — нельзя? Даже как crc от массива байт, полученного простой конкатенацией строк?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[6]: О рулезности опенсорса на примере mysql
От: frogkiller Россия  
Дата: 02.03.10 22:29
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

f>> Для данных — элементарно — сравнить crc/md5/...

S>Довольно длительная операция имхо получится...

Это да — но тут уже кому что: уверенность в том, что всё действительно скопировалось, или скорость... Всё завист от задачи.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[6]: О рулезности опенсорса на примере mysql
От: Antikrot  
Дата: 02.03.10 22:29
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

A>> S>Я поражаюсь способностям ударяться в крайности, которые присутствуют у некоторых местных читателей...

A>> ты два раза повторил слово "только", и еще говоришь другим о крайностях?
S>Админу бы такое врядли в голову пришло. А если почитать этот форум, то легко сделать вывод, что только с программистами такое может случиться, ибо "я не админ, мне ентого ниче знать нинада"
я правильно понял, что практически все админы знают как [через жопу] внутри mysql сделано удаление индексов?

A>> кроме того, твои слова о "боевой базе" и "сделать сразу так, как было сделано в итоге" какбе вызывают еле заметные подозрения о том, что ты не отличаешь базу от таблицы.

S>Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака.
ну может хоть ты расскажешь где там что вытаскивалось?

A>> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2.

S>Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи
а много тут способов решения задачи?
кроме того, ты тут противоречишь вот этой твоей же фразе:

вместо того чтобы сделать сразу так, как как было сделано в итоге



S>, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД,

о как. интересно как бы ты прикинул. знаешь сложность алгоритма переиндексации в конкретной СУБД?

S>написал бы скрипт, вставил бы в крон и пошел бы домой. А потом из дома, за X времени (X==время восстановления из бекапа + еще немного) до момента, когда сервант обязан быть в форме, залез бы по ssh, посмотрел как дела, и если надо — откатился бы.

S>И ни грамма нервов и времени бы не потратил.
а что не "скопировать базу на другой сервер, удалить там индексы, остановить боевой сервер, скопировать почищенную от индексов базу с рабочего на боевой сервер"?
Re[5]: О рулезности опенсорса на примере mysql
От: Antikrot  
Дата: 02.03.10 22:34
Оценка:
Здравствуйте, frogkiller, Вы писали:

F>>>Если говорить о разнице в подходах, то, имхо, всё несколько не так.

F>>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
A>>на кой черт? копия и так в бекапе. или вообще ничего не бекапится?
F>Бекап — отдельная сущность, создаётся независимо от изменений.
F>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция.
вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.
Re[7]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 02.03.10 22:42
Оценка:
Приветствую, Antikrot, вы писали:

A> я правильно понял, что практически все админы знают как [через жопу] внутри mysql сделано удаление индексов?

Нет. Но все знают что с мускулем надо вести себя осторожно.

A> S>Было бы глупо (а в данном случае и долго) вытаскивать одну таблицу из базы для экспериментов. Намного проще вытащить из бэкапа на резервный сервант копию или вообще скопировать боевую бд и уже там проводить эксперименты. А тем более такие, которые, пусть даже возможно, могут нарушить работу боевого сервака.

A> ну может хоть ты расскажешь где там что вытаскивалось?
В том то и дело что нет. Это ты меня хотел обвинить в том что я таблицу от базы не отличу.

A> A>> и по сути, вся разница в том что ты назвал "вытворять такое" от "было сделано в итоге" заключается в разном порядке выполнения шагов 1 и 2.

A> S>Я бы сделал так: на копии БД на другой машине поэкспериментировал бы с разными способами решения задачи
A> а много тут способов решения задачи?
Как минимум два Плюс вариации.

A> кроме того, ты тут противоречишь вот этой твоей же фразе:

A>

A> вместо того чтобы сделать сразу так, как как было сделано в итоге

Учись читать смысл а не буквы.

A> S>, причем базу бы подрезал на порядок. Прикинул бы время нужное на реформирование боевой БД,

A> о как. интересно как бы ты прикинул. знаешь сложность алгоритма переиндексации в конкретной СУБД?
Ты видел слова "поэкспериментировал бы"? Или читаешь с пятого на десятое?

A> а что не "скопировать базу на другой сервер, удалить там индексы, остановить боевой сервер, скопировать почищенную от индексов базу с рабочего на боевой сервер"?

При наличии последнего бэкапа и выверенном экспериментально методе сие теряет смысл, ибо рубануться все может только при форсмажоре. Плюс быстрее отработает.
Но можно конечно и этот вариант, я не против. Главное тут — предварительно подумать и поэкспериментировать.
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[6]: О рулезности опенсорса на примере mysql
От: frogkiller Россия  
Дата: 02.03.10 22:44
Оценка:
Здравствуйте, Antikrot, Вы писали:

F>>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция.

A>вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.

Не на время работы с копией, а в процессе переключения со старой на новую. От этого практически никуда не деться, разве только какими-то внешними средствами, которые "придержат" все пользовательские запросы на время переключения, а потом отправят их новой базе. Разумеется, "гасить" старую базу желательно уже после подъёма новой. Для пользователей весь процесс может быть практически неотличим от, например, сетевых ретрансмитов.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[8]: О рулезности опенсорса на примере mysql
От: Antikrot  
Дата: 02.03.10 23:05
Оценка:
Здравствуйте, 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>Ты видел слова "поэкспериментировал бы"? Или читаешь с пятого на десятое?
видел. и выразил большое сомнение, что ты (да и не принципиально кто) сможет правильно интерполировать экспериментальные данные с "подрезанной на порядок базы" на полную базу. сколько экспериментов надо, чтобы выявить квадратичную зависимость? а если там меняется что по достижению пороговых значений?
Re: О рулезности опенсорса на примере mysql
От: vladimir.vladimirovich США  
Дата: 03.03.10 01:47
Оценка: :)
Здравствуйте, quwy, Вы писали:

Q> Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.


Кстати претензии к компании Oracle. Как Oracle DB, так и MySQL — это сейчас продукты этой компании. Требуйте у них разъяснений почему они делают разные продукты с разными лицензиями, разными ценами и разным набором функционала.
Re[3]: О рулезности опенсорса на примере mysql
От: Testator Россия  
Дата: 03.03.10 05:00
Оценка: +1
Здравствуйте, IID, Вы писали:

IID>Здравствуйте, Testator, Вы писали:


T>>А вы каким местом думали когда выбирали СУБД и вид лицензии? У MySQL где-нибудь в бесплатной лицензии написано про отсутствие проблемных мест или какую ответственность за баги? Вроде нет, там классический GPL и какие-то варианты дуальности,


IID>Я правильно понимаю, что все кто выбирает GPL продукты думают не тем местом, каким следует ?


Судите самостоятельно:
— Продукт очевидно используется в довольно жестком production режиме, где время на поиск и устранение всяких проблем ограничено.
— Время от времени требуется поддержка от производителя, т.к. продукт сложный.
— Для продукта кроме обычной GPL есть доступные планы поддержки, где в соглашении прописан SLA.

Вопрос: а не ССЗБ ли тот кто пользует неподходящий для него вариант лицензии, и жалуется на проблему с продуктом в rsdn, вместо того чтобы купить поддержку и жаловаться непосредственно производителю?

Вопрос №2: чем по-вашему в указанном случае продукт с GPL отличается от продукта с другой лицензией не предусматривающей поддержки с SLA? И что конкретно GPL содержит такого особенного по отношению к внутренним особенностям ПО, что позволяет применять квантор всеобщности с какими-то свойствами к сущности под названием "GPL продукты"?
▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬
Мы — то, во что верим.
Re[4]: О рулезности опенсорса на примере mysql
От: _ABC_  
Дата: 03.03.10 06:21
Оценка: +3
Здравствуйте, Testator, Вы писали:


T>Судите самостоятельно:

T>- Продукт очевидно используется в довольно жестком production режиме, где время на поиск и устранение всяких проблем ограничено.
T>- Время от времени требуется поддержка от производителя, т.к. продукт сложный.
T>- Для продукта кроме обычной GPL есть доступные планы поддержки, где в соглашении прописан SLA.

T>Вопрос: а не ССЗБ ли тот кто пользует неподходящий для него вариант лицензии, и жалуется на проблему с продуктом в rsdn, вместо того чтобы купить поддержку и жаловаться непосредственно производителю?


Я бы поставил вопрос более конструктивно — не разумнее ли нанять приходящего специалиста для таких дел — администратора БД?
Re: О рулезности опенсорса на примере mysql
От: DOOM Россия  
Дата: 03.03.10 06:39
Оценка: +1
Здравствуйте, quwy, Вы писали:

Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.


Ну видно же по описанию, что у тебя используется MyISAM, который, если кто помнит, транзакции не держал (или до сих не держит). Использовал бы InnoDB (который для больших баз рекомендуется) проблемы бы не было.
Так что в чистом виде ССЗБ...

P.S. На Oracle-то денег хватит? Явно тебе ведь не хватит Express Edition.
P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.
Re[2]: О рулезности опенсорса на примере mysql
От: DOOM Россия  
Дата: 03.03.10 06:41
Оценка: +1
Здравствуйте, vladimir.vladimirovich, Вы писали:

VV>Здравствуйте, quwy, Вы писали:


VV>Не надо сравнивать опенсорс и опенсорс. Есть хорошие продукты, а есть mysql.

MySQL — хороший продукт. Просто имеет границы применимости.
Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD.
Re[4]: О рулезности опенсорса на примере mysql
От: DOOM Россия  
Дата: 03.03.10 06:42
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:


RO>Вряд ли энтерпрайзная MySQL удаляет индексы более гуманным образом.


Но там бы точно сказали послали на нужный документ, где написано как это делать правильно.
Re: О рулезности опенсорса на примере mysql
От: KipDblK Россия  
Дата: 03.03.10 07:31
Оценка:
Здравствуйте, quwy, Вы писали:

Q>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.


Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
Ego Liberare Art Ultimus Injuria
Re[5]: О рулезности опенсорса на примере mysql
От: Roman Odaisky Украина  
Дата: 03.03.10 09:09
Оценка: +1 :)
Здравствуйте, _ABC_, Вы писали:

_AB>Я бы поставил вопрос более конструктивно — не разумнее ли нанять приходящего специалиста для таких дел — администратора БД? :xz:


...который не применяет РСУБД для того, для чего они не предазначены — для временных рядов?
До последнего не верил в пирамиду Лебедева.
Re[6]: О рулезности опенсорса на примере mysql
От: fddima  
Дата: 03.03.10 09:10
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

Ну-ну. Админ зачастую ставит просто обновления от разработчика, незабывая бэкапится.
Бэкап базы может идти часами, например на/с всё того же стриммера — всё упирается исключительно в доступные носители и их объем. "Резервный" сервант — это как правило полудохлая (в плане производительности) тачка (к примеру виртуализированная), и равняться на неё смысла не имеет, и ожидать чего-то огромного тоже.
Тестовая "реструктуризация" базы — это хорошо, но всё нужно делать со смыслом и при необходимости. Я такой тест проводил, но упаси боже проверять команды навроде drop index, обычно чистой прикладухи и так сверх головы хватает.
Из моей практике было так — тесты могли занимать около 5 часов, — в то время как то же самое на боевом — ~5-10 минут. При том задачи были в чём-то схожи (drop index был ), но была массовая реструктуризация базы вообще. С таким подходом разумеется ни о каких 5-10 минутах речи быть не могло в принципе, даже если изначально выбрать "правильный" путь.
Re[2]: О рулезности опенсорса на примере mysql
От: Mamut Швеция http://dmitriid.com
Дата: 03.03.10 09:58
Оценка: +2
S>Да, и еще.
S>Я уже оччень давно говорил — не трогайте мускуль, он воняет. Возьмите постгрес.
S>Так нет-же. Трогают.

S>А потом опенсорц виноват, ага.


Тебе напомнить, или сам вспомнишь... http://rsdn.ru/forum/flame.comp/3708239.aspx
Автор: Sheridan
Дата: 17.02.10


dmitriid.comGitHubLinkedIn
Re[2]: О рулезности опенсорса на примере mysql
От: Mamut Швеция http://dmitriid.com
Дата: 03.03.10 09:59
Оценка:
Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.

KDK>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.


Это, кстати, один самых геморройных моментов мускуля — выбор движка.


dmitriid.comGitHubLinkedIn
Re[3]: О рулезности опенсорса на примере mysql
От: Sharowarsheg  
Дата: 03.03.10 10:06
Оценка:
Здравствуйте, Mamut, Вы писали:

KDK>>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.


M>Это, кстати, один самых геморройных моментов мускуля — выбор движка.


Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде
Re[4]: О рулезности опенсорса на примере mysql
От: fddima  
Дата: 03.03.10 10:07
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>nginx — наше всё!

Он уже научился правильно понимать HTTP-хидеры?
Re[6]: О рулезности опенсорса на примере mysql
От: Roman Odaisky Украина  
Дата: 03.03.10 10:28
Оценка:
Здравствуйте, Antikrot, Вы писали:

F>>"Заменить исходную базу новой" — mv mycooldb mycooldb.old; mv mycolldb.new mycooldb — очень быстрая, почти атомарная операция.

A>вообще интересно. с такими mv всё равно надо на время работы с копией останавливать боевую базу, или хотя бы в readonly переводить.

LOCK TABLES WRITE. Или репликация. А еще у них есть прокси, который умеет перенаправлять запросы по разным направлениям.
До последнего не верил в пирамиду Лебедева.
:)
От: Sheridan Россия  
Дата: 03.03.10 10:32
Оценка: :)
По количеству минусов вполне видно что я оказался прав
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re: :)
От: neFormal Россия  
Дата: 03.03.10 10:47
Оценка: 1 (1) +2 :))) :))) :)))
Здравствуйте, Sheridan, Вы писали:

S>По количеству минусов вполне видно что я оказался прав


ага, так же, как и по количеству минусов у x64 в КУ вполне видно, что у него прекрасное чувство юмора..

  Скрытый текст
теперь этот тред про КУ..
...coding for chaos...
Re[4]: О рулезности опенсорса на примере mysql
От: KipDblK Россия  
Дата: 03.03.10 11:05
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

M>>Это, кстати, один самых геморройных моментов мускуля — выбор движка.

S>Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде

Выбор mod_php или FastCGI или SuExec
Ego Liberare Art Ultimus Injuria
Re[4]: О рулезности опенсорса на примере mysql
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.10 11:40
Оценка: +2 :))
Здравствуйте, Sheridan, Вы писали:

a>> Шеридан, эта фраза.... — это же жесточайший вынос мозга! Я бы конечно всегда стелил солому где положено, но аракул в моем сознании внезапно самоустранился, даже не предупредив меня об этом за две недели, как положено по ТК РФ.


S>Да, я иногда умею завернуть так, что даже самому потом непонятно что хотел сказать


Похоже, ты только так и заворачиваешь.
Re[3]: О рулезности опенсорса на примере mysql
От: vladimir.vladimirovich США  
Дата: 03.03.10 12:38
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>MySQL — хороший продукт. Просто имеет границы применимости.

DOO>Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD.

Автор почему-то не стал делать — это правда, может просто ему Access не попался на глаза во время придумывания архитектуры.

То, что MySQL хороший продукт — усомнюсь. Ладно бы у них просто не было части функционала — это правда дает границы применимости, так у них же с заявленным функционалом бардак. Впрочем в enterprise мире пользуются и продуктами куда более плохого качества и не жужжат.
Re[4]: О рулезности опенсорса на примере mysql
От: DOOM Россия  
Дата: 03.03.10 12:43
Оценка: +1
Здравствуйте, vladimir.vladimirovich, Вы писали:


VV>То, что MySQL хороший продукт — усомнюсь. Ладно бы у них просто не было части функционала — это правда дает границы применимости, так у них же с заявленным функционалом бардак.

Что не мешает MySQL по распространенности делать любую другую бесплатную СУБД.

VV>Впрочем в enterprise мире пользуются и продуктами куда более плохого качества и не жужжат.

Не только в Enterprise. Можно привести кучу ситуаций, когда "мыши плакали, кололись, но продолжали жевать кактус".
Пока Postgre каких-то внезапных рывков в популярности не делает — значит по суммарному количеству параметров MySQL предпочтительнее.
Re[2]: О рулезности опенсорса на примере mysql
От: Testator Россия  
Дата: 03.03.10 13:55
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ты — программист?

S>Только программисту имхо могла прийти в голову вытворять подобное на боевой базе, и только программисту могла прийти в голову идея вообще вытворять подобное вместо того чтобы сделать сразу так, как как было сделано в итоге.

Вот ведь жопошники эти программисты. Понакодили тут, еще вытворяют, идеи в головах видите ли. Нет чтоб как люди: прочел ман, поправил конфиг, и все завертелось! Романтика!
▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬
Мы — то, во что верим.
Re[2]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 03.03.10 14:18
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> Я уже оччень давно говорил — не трогайте мускуль, он воняет.


Да ладно — отлично работает, если его правильно работать.

S> Возьмите постгрес.


Тоже не панацея и так же можно найти приемов прострелить себе ногу.
avalon 1.0rc3 rev 317, zlib 1.2.3
Re[5]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 03.03.10 14:18
Оценка:
Здравствуйте, fddima, Вы писали:

f> RO>nginx — наше всё!

f> Он уже научился правильно понимать HTTP-хидеры?

Например?
avalon 1.0rc3 rev 317, zlib 1.2.3
Re[3]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 03.03.10 14:18
Оценка:
Здравствуйте, Mamut, Вы писали:

M> Это, кстати, один самых геморройных моментов мускуля — выбор движка.


А разве сегодня есть выбор кроме InnoDB? (MyISAM спокойно почил и используется лишь от "незнания")
avalon 1.0rc3 rev 317, zlib 1.2.3
Re[6]: О рулезности опенсорса на примере mysql
От: fddima  
Дата: 03.03.10 14:28
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

f>> RO>nginx — наше всё!

f>> Он уже научился правильно понимать HTTP-хидеры?
AB>Например?
URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично. Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился?
Re[7]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 03.03.10 14:36
Оценка:
Здравствуйте, fddima, Вы писали:

f> URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично.


Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding.

f> Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился?


Он достаточно быстро развивается и обрастает функционалом. Иногда даже кажется, что слишком много на него пытаются навешать.
avalon 1.0rc3 rev 317, zlib 1.2.3
Re[8]: О рулезности опенсорса на примере mysql
От: fddima  
Дата: 03.03.10 14:44
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, fddima, Вы писали:


f>> URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично.

AB>Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding.
Эм. Это ж его сейчас ставить надо, пробовать. Грубо говоря — вместо того что-бы отдать файл с именем "ААА.html" — пытался искать файл "%80%80%80.html" (80 — это я к примеру). Увы, думаю концов сейчас уже не найти.

f>> Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился?

AB>Он достаточно быстро развивается и обрастает функционалом. Иногда даже кажется, что слишком много на него пытаются навешать.
Просто не думаю что он хороший пример хорошего софта, хотя, конечно же если учесть его популярность — то да.
Re[4]: О рулезности опенсорса на примере mysql
От: Mamut Швеция http://dmitriid.com
Дата: 03.03.10 14:44
Оценка:
M>> Это, кстати, один самых геморройных моментов мускуля — выбор движка.

AB>А разве сегодня есть выбор кроме InnoDB? (MyISAM спокойно почил и используется лишь от "незнания")


Ничего он не почил. До сих пор движок по умолчанию


dmitriid.comGitHubLinkedIn
Re[5]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 03.03.10 15:03
Оценка:
Здравствуйте, Mamut, Вы писали:

M> AB>А разве сегодня есть выбор кроме InnoDB? (MyISAM спокойно почил и используется лишь от "незнания")

M> Ничего он не почил. До сих пор движок по умолчанию

Принцип наименьшего удивления, ИМХО. Я бы тоже не стал менять умолчания, которые были заложены столько лет назад. Ну а для 33 лямов записей даже сомнений быть не должно.
avalon 1.0rc3 rev 317, zlib 1.2.3
Re[9]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 03.03.10 15:03
Оценка: 2 (1)
Здравствуйте, fddima, Вы писали:

f> AB>Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding.

f> Эм. Это ж его сейчас ставить надо, пробовать. Грубо говоря — вместо того что-бы отдать файл с именем "ААА.html" — пытался искать файл "%80%80%80.html" (80 — это я к примеру). Увы, думаю концов сейчас уже не найти.

Сейчас проверил — нормально отдает. Возможно, бага и была, но Игорь достаточно оперативно на них реагирует. Так что можно повторить подход к снаряду
avalon 1.0rc3 rev 317, zlib 1.2.3
Re[10]: О рулезности опенсорса на примере mysql
От: fddima  
Дата: 03.03.10 15:14
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Сейчас проверил — нормально отдает. Возможно, бага и была, но Игорь достаточно оперативно на них реагирует. Так что можно повторить подход к снаряду

Ах тааак?!?! Тогда передавай Игорю респегд.

ЗЫ: Второй подход не нужен — карме nginx — +1.
Re[7]: О рулезности опенсорса на примере mysql
От: Vamp Россия  
Дата: 03.03.10 17:06
Оценка:
F>Э... а что — нельзя? Даже как crc от массива байт, полученного простой конкатенацией строк?
Нет, ну если ты точно знаешь, что одна таблица однозначно маппируется на один файл — то конечно можно взять CRC от этого файла.
А вот если это не так — а в общем случае это не так — то как тогда?
Да здравствует мыло душистое и веревка пушистая.
Re: О рулезности опенсорса на примере mysql
От: xBlackCat Россия  
Дата: 03.03.10 18:15
Оценка:
Здравствуйте, quwy, Вы писали:

Q>После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс!


Пойду в сторону от основного направления партии и хаянья MySQL.
При некотором опыте в MySQL можно обнаружить, что создание/удаление нескольких индексов в одной таблице делается одной командой и, следовательно, за одно копирование таблиц. Надо просто все операции записать через запятую.
Rojac — Rsdn Offline JAva Client
Анонсы и обсуждение здесь
Автор: xBlackCat
Дата: 08.02.10
Re[4]: О рулезности опенсорса на примере mysql
От: quwy  
Дата: 03.03.10 22:45
Оценка:
Здравствуйте, vladimir.vladimirovich, Вы писали:

DOO>>MySQL — хороший продукт. Просто имеет границы применимости.

DOO>>Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD.
VV>Автор почему-то не стал делать — это правда, может просто ему Access не попался на глаза во время придумывания архитектуры.
Автора просто супруга попросила сделать давно работающий продукт (базирующийся на open-source-скриптах, кстати) менее тормозным, с чем он справился хорошо: отклик web-приложения в удаленном браузере с 30-60 секунд сократился до 0-3.
Re[2]: О рулезности опенсорса на примере mysql
От: quwy  
Дата: 03.03.10 22:48
Оценка: 2 (1)
Здравствуйте, Testator, Вы писали:

Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.

T>А вы каким местом думали когда выбирали СУБД и вид лицензии?
Я ничего не выбирал, меня попросили привести в чувства уже готовое, и я взялся. О своих впечатлениях отписал тут. А т.к. я уже много лет занимаюсь разработкой в области СУБД, то меня сильно обескуражило все увиденное. Вот и все.
Re[2]: О рулезности опенсорса на примере mysql
От: quwy  
Дата: 03.03.10 22:54
Оценка:
Здравствуйте, Vamp, Вы писали:

Q>>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.

V>Я думаю, не найдется человека в здравом уме, который оспорит то, что Оракле превосходит MySql практически по всем статьям... за исключением цены.
Есть шаровой оракл, для данного проекта его, конечно, не хватило бы, но с другой стороны никто сильно и не думал что будут такие масштабы (специфический сервис, который только потом присосался к более востребованному и со временем начал тормозить).

V>Тут дело не в опенсорсе.

В нем тоже, коммерческая БД, авторы которой заявляют, что она "не хуже других", такого себе позволить просто не может. Вон, например, IB/FB вообще не позволяет переименовывать объекты БД, как бы я выкрутился, если бы она тоже индексы через одно место удаляла?
Re[2]: О рулезности опенсорса на примере mysql
От: quwy  
Дата: 03.03.10 22:58
Оценка:
Здравствуйте, Vamp, Вы писали:

Q>>В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно

Q>>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц
V>Я, наверное, очень тупой. Но не противоречат ли эти два предложения сами себе?
Нет, не противоречат. Потому что в первом случае кроме копирования, пересоздавались ненужные индексы (весьма тяжелые). Да и не известно еще, через какое место реализовано скрытое копирование.
Re[2]: О рулезности опенсорса на примере mysql
От: quwy  
Дата: 03.03.10 23:02
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, quwy, Вы писали:


Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он.

DOO>Ну видно же по описанию, что у тебя используется MyISAM
Где это видно? Используется как раз InnoDB.

DOO>P.S. На Oracle-то денег хватит? Явно тебе ведь не хватит Express Edition.

Я -- фактически приглашенный со стороны специалист, спасательный круг. А при выборе БД, руководствовались в основонм ее совместимостью с кучей опенсорсного php-кода. Так что претензии мимо кассы.

DOO>P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.

Штатные управляющие программы? Дал бы в глаз тому гаду, который из написал! Хорошо, что они не обязательны в повседневной работе.
Re[2]: О рулезности опенсорса на примере mysql
От: quwy  
Дата: 03.03.10 23:11
Оценка:
Здравствуйте, xBlackCat, Вы писали:

Q>>После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс!

BC>Пойду в сторону от основного направления партии и хаянья MySQL.
BC>При некотором опыте в MySQL можно обнаружить, что создание/удаление нескольких индексов в одной таблице делается одной командой и, следовательно, за одно копирование таблиц. Надо просто все операции записать через запятую.
Может быть, в итоге я это сделал тоже за один проход, но руками. Проблема только в том, что для удаления индекса, копирование таблицы как бы вообще не нужно...
Re[3]: О рулезности опенсорса на примере mysql
От: _d_m_  
Дата: 04.03.10 00:10
Оценка: -1
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, Sheridan, Вы писали:


S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет.


AB>Да ладно — отлично работает, если его правильно работать.


Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.
Re[2]: О рулезности опенсорса на примере mysql
От: Mr.Cat  
Дата: 04.03.10 02:07
Оценка:
Здравствуйте, DOOM, Вы писали:
DOO>P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.
А его же трудно публично хаять. Пусть проблем и багов — вагон и маленькая тележка, зато багтрекер закрыт от любопытных глаз. В споре всегда можно сказать "у меня все работает" и спрятать голову в песок.
Re[4]: О рулезности опенсорса на примере mysql
От: zaufi Земля  
Дата: 04.03.10 02:48
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>Здравствуйте, Mamut, Вы писали:


KDK>>>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.


M>>Это, кстати, один самых геморройных моментов мускуля — выбор движка.


S>Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде


мда, есть примерно тожее самое: выбор подходящего MPM (Multi-Processing Module)
Re[3]: О рулезности опенсорса на примере mysql
От: Трурль  
Дата: 04.03.10 06:57
Оценка:
Здравствуйте, frogkiller, Вы писали:

F>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.


А вот интересно: перед удалением файла админ сделает копию ФС?
Re[4]: О рулезности опенсорса на примере mysql
От: DOOM Россия  
Дата: 04.03.10 06:59
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, frogkiller, Вы писали:


F>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.


Т>А вот интересно: перед удалением файла админ сделает копию ФС?


Смотря какой файл
Ну а снэпшот сделать рука не отсохнет — а ситуацию может спасти.
Re[8]: О рулезности опенсорса на примере mysql
От: Farsight СССР  
Дата: 04.03.10 08:09
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

A>> вместо того чтобы сделать сразу так, как как было сделано в итоге

A>> [/q]
S>Учись читать смысл а не буквы.

Молодца! И тут же вот это
Автор: Sheridan
Дата: 03.03.10
.
</farsight>
Re[3]: О рулезности опенсорса на примере mysql
От: Testator Россия  
Дата: 04.03.10 08:26
Оценка:
Здравствуйте, quwy, Вы писали:

Q>Проблема только в том, что для удаления индекса, копирование таблицы как бы вообще не нужно...


Не очевидно это ни разу. Я конечно многовато лет назад занимался базами данных, но помню что например в MSSQL и Oracle есть такие кластерные индексы, которые влияют на физическое расположение записей в таблице для оптимизации. И при удалении такого индекса тупое копирование таблицы тут может оказаться более дешевой операцией чем сортировка записей по-новому. Возможно для MySQL тоже есть какие-то особенности, из-за которых было сделано именно так как сделано.
▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬
Мы — то, во что верим.
Re[4]: О рулезности опенсорса на примере mysql
От: Mr.Cat  
Дата: 04.03.10 08:27
Оценка:
Здравствуйте, Testator, Вы писали:
T>в ... Oracle есть такие кластерные индексы
Отличная шутка
Re[5]: О рулезности опенсорса на примере mysql
От: Testator Россия  
Дата: 04.03.10 08:31
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Testator, Вы писали:

T>>в ... Oracle есть такие кластерные индексы
MC>Отличная шутка

А что тут смешного? Скажи, может вместе посмеемся
▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬
Мы — то, во что верим.
Re[6]: О рулезности опенсорса на примере mysql
От: Mr.Cat  
Дата: 04.03.10 08:38
Оценка:
Здравствуйте, Testator, Вы писали:
T>А что тут смешного?
Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.
Re[7]: О рулезности опенсорса на примере mysql
От: lazymf Россия  
Дата: 04.03.10 08:48
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.


С кластерным индексам мсскл скорее имеют отношения оракловские index organized tables, не?
Re[4]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 04.03.10 09:39
Оценка: +1
Здравствуйте, _d_m_, Вы писали:

_> S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет.

_> AB>Да ладно — отлично работает, если его правильно работать.
_> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.

Эту фразу можно применить к любому программному продукту.
Вот только проблема в подавляющем большинстве случаев не в MySQL, а в том, что люди не читают документацию (которая уж явно меньше BOL).
avalon 1.0rc3 rev 318, zlib 1.2.3
Re[5]: О рулезности опенсорса на примере mysql
От: _d_m_  
Дата: 04.03.10 12:07
Оценка: -1
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, _d_m_, Вы писали:


_>> S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет.

_>> AB>Да ладно — отлично работает, если его правильно работать.
_>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.

AB>Эту фразу можно применить к любому программному продукту.


Вот уж нет.

AB>Вот только проблема в подавляющем большинстве случаев не в MySQL, а в том, что люди не читают документацию (которая уж явно меньше BOL).


Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция. И что перед этим надо делать копию ажно всей БД. Ну а чо, для большинства закоренылых MySQL-евцев это нормально. Потому что от этого, с позволения сказать продукта, всего можно ожидать.
Re[7]: О рулезности опенсорса на примере mysql
От: Testator Россия  
Дата: 04.03.10 14:55
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Testator, Вы писали:

T>>А что тут смешного?
MC>Ну ошибся я, есть там кластерные индексы, посыпаю голову пеплом. Оправдывает меня только то, что к кластерным индексам mssql они никакого отношения не имеют.

Еще бы в Oracle не было, сложнее найти чего там нет.

А таблицы в свежих версиях MySQL на InnoDB оказывается вообще без кластерных индексов не живут:
http://dev.mysql.com/doc/refman/5.5/en/innodb-index-types.html

Даже если подходящих индексов нет, сгенерируется искусственный уникальный. А если есть, возьмется либо primary key, либо первый UNIQUE NOT NULL. Пальцем в небо, но похоже это и есть причина проблемы с drop index.
▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬
Мы — то, во что верим.
Re[8]: О рулезности опенсорса на примере mysql
От: Mr.Cat  
Дата: 04.03.10 15:07
Оценка:
Здравствуйте, lazymf, Вы писали:
L>С кластерным индексам мсскл скорее имеют отношения оракловские index organized tables, не?
Ну да, по идее что-то в таком духе.
Re[4]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 04.03.10 21:02
Оценка:
Приветствую, Трурль, вы писали:

Т> А вот интересно: перед удалением файла админ сделает копию ФС?


Достатояно zfs, она сама будет делать.
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[5]: О рулезности опенсорса на примере mysql
От: Vamp Россия  
Дата: 04.03.10 21:18
Оценка:
S>Достатояно zfs, она сама будет делать.
А ее в Linux портировали что ли?
Да здравствует мыло душистое и веревка пушистая.
Re[6]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 04.03.10 23:02
Оценка:
Приветствую, Vamp, вы писали:

V> S>Достатояно zfs, она сама будет делать.

V> А ее в Linux портировали что ли?
Ты хотел сказать "А ее в ядро включили, чтоли?", да?
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[6]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 05.03.10 10:30
Оценка: +1
Здравствуйте, _d_m_, Вы писали:

_> _>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.

_> AB>Эту фразу можно применить к любому программному продукту.
_> Вот уж нет.

Ты готов озвучить безграбельный продукт?

_> Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция.


А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают.

_> И что перед этим надо делать копию ажно всей БД.


Ну это ты уже сам придумал.
avalon 1.0rc3 rev 318, zlib 1.2.3
Re[7]: О рулезности опенсорса на примере mysql
От: Vamp Россия  
Дата: 05.03.10 14:28
Оценка:
S>Ты хотел сказать "А ее в ядро включили, чтоли?", да?
Да.
Да здравствует мыло душистое и веревка пушистая.
Re[8]: О рулезности опенсорса на примере mysql
От: Sheridan Россия  
Дата: 05.03.10 17:58
Оценка:
Приветствую, Vamp, вы писали:

V> S>Ты хотел сказать "А ее в ядро включили, чтоли?", да?


V> Да.


Нет, несовместимы лицензии. Надо отдельно устанавливать.
avalon 1.0rc3 rev 315, zlib 1.2.3
build date: 15.02.2010 00:26:03 MSK +03:00
Qt 4.6.1
Matrix has you...
Re[7]: О рулезности опенсорса на примере mysql
От: mrTwister Россия  
Дата: 05.03.10 21:54
Оценка:
Здравствуйте, frogkiller, Вы писали:

F>Не на время работы с копией, а в процессе переключения со старой на новую. От этого практически никуда не деться, разве только какими-то внешними средствами, которые "придержат" все пользовательские запросы на время переключения, а потом отправят их новой базе. Разумеется, "гасить" старую базу желательно уже после подъёма новой. Для пользователей весь процесс может быть практически неотличим от, например, сетевых ретрансмитов.


Вообще, правильно это делается не так. Изначально надо было делать master-slave репликацию (а если точнее, то master — second master), все изменения (и индексами и не только) проводить на slave (можно хоть неделю играться, лишь бы вместимости логов хватило), затем когда на слейве сделали все, что надо, меняем их местами (то есть мастер становится слейвом) и он затягивает все изменения (опять таки пусть хоть неделю работает). Пользователи вообще ничего не замечают.
лэт ми спик фром май харт
Re[7]: О рулезности опенсорса на примере mysql
От: _d_m_  
Дата: 15.03.10 04:13
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, _d_m_, Вы писали:


_>> _>> Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.

_>> AB>Эту фразу можно применить к любому программному продукту.
_>> Вот уж нет.

AB>Ты готов озвучить безграбельный продукт?


Черное-белое, оттенков не различаешь? Вопрос не в наличии грабель, а в их количестве. В MySQL по доброму так обильно насыпано грабель-фич.

_>> Люди как бы ожидают адекватного поведения. А тут такой сюрприз — бац! Оказывается элементарный drop index — это охрененно ресурсоемкая операция.


AB>А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают.


Ну тогда можно придумать и свой язык и назвать его, например SQL. Ну и что, что к всем известному языку он не будет иметь никакого отношения. Просто в документации описать. Типа такого "оператор SELECT — удаляет данные из таблицы".

_>> И что перед этим надо делать копию ажно всей БД.


AB>Ну это ты уже сам придумал.


Да нет, вон народ в этом топике на полном серьезе предлагает и обсуждает.
Re[8]: О рулезности опенсорса на примере mysql
От: Anton Batenev Россия https://github.com/abbat
Дата: 15.03.10 10:06
Оценка:
Здравствуйте, _d_m_, Вы писали:

_> AB>Ты готов озвучить безграбельный продукт?

_> Черное-белое, оттенков не различаешь? Вопрос не в наличии грабель, а в их количестве. В MySQL по доброму так обильно насыпано грабель-фич.

Опять общие слова...

_> AB>А не надо чего-то ожидать или гадать на кофейной гуще — достаточно просто почитать документацию и понять как оно там устроено — все достаточно подробно описано и ничего не скрывают.

_> Ну тогда можно придумать и свой язык и назвать его, например SQL. Ну и что, что к всем известному языку он не будет иметь никакого отношения. Просто в документации описать. Типа такого "оператор SELECT — удаляет данные из таблицы".

Отвечу твоими же словами: "Черное-белое, оттенков не различаешь?"

_> _>> И что перед этим надо делать копию ажно всей БД.

_> AB>Ну это ты уже сам придумал.
_> Да нет, вон народ в этом топике на полном серьезе предлагает и обсуждает.

Ну так это от незнания. DROP INDEX делается за доли секунды при правильном администрировании.
avalon 1.0rc3 rev 318, zlib 1.2.3
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.