[хабр] MySQL капец

>По крайней мере я точно помню что когда ставил под винду постгрю

Под винду вижу дофига таких migration tools. А вот под Linux - фиг :-/ Есть пара популярных скриптов, оба не работают. Один обламывается где-то на первых полутора гигах. Второй не справляется с преобразованием формата создания таблиц.

Под винду вижу дофига таких migration tools. А вот под Linux - фиг :-/ Есть пара популярных скриптов, оба не работают. Один обламывается где-то на первых полутора гигах. Второй не справляется с преобразованием формата создания таблиц.

Ну тут уж я ничем помочь не могу :( Я с перегонкой баз очень давно в последний раз сталкивался, году в 2006-2007. И перегоняли мы данные в постгрес не с мускуля, а из db2 express, для чего писали свой велосипед с квадратными колесами на java+jdbc.

>для чего писали свой велосипед с квадратными колесами

Похоже и мне придётся так делать :)

Похоже и мне придётся так делать :)

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

>Не вижу в этом ничего страшного. Такой велосипед пишется за день

Даже не за день, а за час-два. Но в том-то и фигня, что это не для чего-то нужного, а только для теста, который _может быть_ даст возможность задуматься о замене платформы... Слишком отдалённый профит, чтобы тратить столько времени :) (ещё на само тестирование сколько уйдёт).

Сейчас-то и mysql прекрасно работает. Так что вопрос поиска альтернативы - не насущный вопрос, а только природное любопытство :D

Даже не за день, а за час-два.

Вечная PM-ская привычка умножать сроки на Pi ;)

Но в том-то и фигня, что это не для чего-то нужного, а только для теста, который _может быть_ даст возможность задуматься о замене платформы... Слишком отдалённый профит, чтобы тратить столько времени :) (ещё на само тестирование сколько уйдёт).

Напоминает старый анекдот про программиста, его сынишку и восход/закат солнца. Может просто если найдется новый проект - начать его делать на постгре? А старый оставить в покое.

>Может просто если найдется новый проект - начать его делать на постгре?

Да пока такое не светит. Все новые проекты слишком мелкие и расчитываются на самых тупых хостеров, у которы PG нету. А толстые проекты, где PG потенциально мог бы стать эффективнее - во-первых, старые, во-вторых - и так хорошо работают ;)

Кстати, решил сам сейчас побенчить Постгре на реальных данных (те пресловутые 5Гб) - никак не подберу никакой конвертер, чтобы mysql dump в postgre конвертнуть

А если онлайн перегнать. Сначала создаем пустую базу postgresql со структурой (сначала без индексов). Пишем небольшой клиент на java, который подключается к двум базам и перегоняет данный из одной базы в другую (пачками по 1000-10000 записей). Можно таких клиентов запустить несколько в параллель - каждому дать задание на перенос своей части данных. Затем создаем индексы.

Делаем, естественно, все на копии базы данных, чтобы случайно, что-нибудь не запортить основную БД.

>А если онлайн перегнать

Дольше будет. Всё же, более 2 млн. записей. Но такой вариант в голове тоже держу. Ибо если буду заниматься PG, то ORM-драйвер под него неизбежен. Написать такой драйвер не сложнее, чем конвертер. А дальше - чистая автоматика. each-цикл по объектам с mysql-бэкендом и копирование их в PG-объекты. Процесс копирования пойдёт по времени дольше, зато за то же время написания будет готовый бэкенд.

>С дефолтовыми параметрами это что-то ужасное, а что и куда крутить для увеличения производительности - непонятно...

А my.cnf, значит, смотришь — и назначение всех параметров становится кристально ясным?

>А my.cnf, значит, смотришь — и назначение всех параметров становится кристально ясным?

http://www.linux.org.ru/jump-message.jsp?msgid=5520166&cid=5524708 последний абзац.

>никак не подберу никакой конвертер, чтобы mysql dump в postgre конвертнуть

Работающих в природе вроде бы нет.

Кстати, если ты просто «мигрируешь на постргрес», навряд ли что-то ощутимо изменится в лучшую сторону. Я вообще подозреваю, что в мускуле, как и положено этой говнонедосубд, сплошные myisam'ные таблицы. В этом случае странно ожидать ускорения.

>http://www.linux.org.ru/jump-message.jsp?msgid=5520166&cid=5524708 последний абзац.

Не хватает скриптов «сделать заебись»? Так они весьма примитивны и помогут разве что если мускуль настраивала секретарша, а запросы к базе писал курьер.

>Так они весьма примитивны

Да нет, весьма эффективны :)

>Да нет, весьма эффективны :)

Одно другому не мешает. Почему-то 99% май-эс-кью-эль «специалистов» не умеют использовать explain и не знают о логе медленных запросов. Собственно, этим 99% этот скрипт и призван помочь.

Если ты пытаешься использовать СУБД, не включая мозг, словно это какой-то оптимизатор реестра, естественно, ничего путного не выйдет.

>Собственно, этим 99% этот скрипт и призван помочь

Нет. Для таких случаев эти скрипты - это даже не стрельба из пушки по воробьям. Это поиск с помощью микроскопа очков, забытых на лбу.

Если ты пытаешься использовать СУБД, не включая мозг, словно это какой-то оптимизатор реестра, естественно, ничего путного не выйдет.

Естественно. А вот когда ты пытаешься вывести узкие места в системе по десятку параметров статистического отчёта за неделю работы, когда выясняется, что пару дней назад ночью сервер вдруг почему-то сильно тормозил, то подобные скрипты весьма заметно облегчают жизнь. И глупо «включать мозг» для перемножения в уме четырёхзначных чисел, когда калькулятор это сделает быстрее и надёжнее.