Comments 13
Я для той же самой цели использовал taps — оно само создаёт сервер, с которого можно с помощью клиента, созданного тем же тапсом перегонять данные между мускулем, постгресом и эскулайтом как угодно.
Я правильно ПОНИМАЮ?
Что именно? Да, именно этот тапс.
Что именно нужный taps я нашел. Спасибо за информацию, посмотрю на будущее.
А, да. Именно этот.
Единственное — обратите внимание на раздел "Known Issues". Маловероятно, что это для вас критично, но вдруг.
Единственное — обратите внимание на раздел "Known Issues". Маловероятно, что это для вас критично, но вдруг.
Перед такой миграцией полезно включить в mysql-е strict mode и попробовать просто залить дамп — очень многое сразу всплывет.
А что послужило причиной потребности перенести базу на с mysql на postgresql? Плохая производительность, отсутствие фич, другое? И оправдались ли ожидания от такого перехода?
Просто это частый предмет спора — mysql vs postgresql, и было бы интересно узнать такие подробности от тех, кто это уже прошел.
Просто это частый предмет спора — mysql vs postgresql, и было бы интересно узнать такие подробности от тех, кто это уже прошел.
Холиварить только не будем :) так же подчеркну, мы еще не перенесли все на продакшн, продолжаем тестирование и проверки на косяки с боевой нагрузкой. А так же нам интересно использование дополнительных компонентов postgresql 9.3 (работа с json и hstore), плюс у нас большой интерес к postgis. Соответственно мы аккуратно подходим к переходу на postgresql в продакшн.
Я админ и немного программист, для меня приятно, что чем меньше точек отказа (точек администрирования), тем лучше.
Вот с чем мы столкнулись используя mysql (percona):
— master-slave: всегда требовал ручного вмешательства.
— master-master: тормоза, несколько раз разваливался так, что поднимались из бекапов на новом серваке
— учитывая наследственность БД (на начальном этапе разработки были ручные вставки, было много myisam) целостность данных постоянно под вопросом. На начальных этапах приведения в порядок базы у меня была постоянная борьба с NOT NULL
— периодически обновления движка БД вскрывают несовместимость опций конфига или изменения в них
— обилие движков иногда побуждает программистов делать за счет них костыли
— ограничение в фичах побудило плотно использовать mongo, что в общем-то можно закрыть за счет postgresql
Вот почему нам интересен postgresql:
— стабильная работа master-slave
— pgpool (да и слона можно заточить :)
— работа с json (позволит отказаться от mongo)
— hstore: тут очень интересна скорость работы (в нашем случае так же может позволить сократить или отказаться от парочки костылей)
— единый формат хранилища, не нужно мучится с движками, также я не припомню, что бы конфиг сильно менялся
— возможность писать дополнения на разных языках
— postgis
— при увеличении нагрузки на БД (те же новые фичи будем использовать) планировщик запросов PG окажется в большом выигрыше по сравнения с оптимизатором мускуля
И дополнительно на других моих проектах:
— адекватная работа с объемами данных больше 500 Гб (возможно мои кривые руки, но у меня не было ни одно счастливой БД на мускуле больше 5 Гб). Один раз я дожил на БД для заббикс объемов в 450ГБ, после чего перешли на postgresql и там сейчас база ~>1,2 Тб и отлично живет без шардинга. (собственно pg и попробовали вместо шардинга на мускуле)
— адекватная работа с большим количеством клиентов (опять же, возможно мои кривые руки, но у меня есть PG база, которая нормально живет при 2500 клиентов 1С на ней, а 1с очень неаккуратен с соединениями, а был мускуль, который на 500 коннектах слал всех нах)
Я админ и немного программист, для меня приятно, что чем меньше точек отказа (точек администрирования), тем лучше.
Вот с чем мы столкнулись используя mysql (percona):
— master-slave: всегда требовал ручного вмешательства.
— master-master: тормоза, несколько раз разваливался так, что поднимались из бекапов на новом серваке
— учитывая наследственность БД (на начальном этапе разработки были ручные вставки, было много myisam) целостность данных постоянно под вопросом. На начальных этапах приведения в порядок базы у меня была постоянная борьба с NOT NULL
— периодически обновления движка БД вскрывают несовместимость опций конфига или изменения в них
— обилие движков иногда побуждает программистов делать за счет них костыли
— ограничение в фичах побудило плотно использовать mongo, что в общем-то можно закрыть за счет postgresql
Вот почему нам интересен postgresql:
— стабильная работа master-slave
— pgpool (да и слона можно заточить :)
— работа с json (позволит отказаться от mongo)
— hstore: тут очень интересна скорость работы (в нашем случае так же может позволить сократить или отказаться от парочки костылей)
— единый формат хранилища, не нужно мучится с движками, также я не припомню, что бы конфиг сильно менялся
— возможность писать дополнения на разных языках
— postgis
— при увеличении нагрузки на БД (те же новые фичи будем использовать) планировщик запросов PG окажется в большом выигрыше по сравнения с оптимизатором мускуля
И дополнительно на других моих проектах:
— адекватная работа с объемами данных больше 500 Гб (возможно мои кривые руки, но у меня не было ни одно счастливой БД на мускуле больше 5 Гб). Один раз я дожил на БД для заббикс объемов в 450ГБ, после чего перешли на postgresql и там сейчас база ~>1,2 Тб и отлично живет без шардинга. (собственно pg и попробовали вместо шардинга на мускуле)
— адекватная работа с большим количеством клиентов (опять же, возможно мои кривые руки, но у меня есть PG база, которая нормально живет при 2500 клиентов 1С на ней, а 1с очень неаккуратен с соединениями, а был мускуль, который на 500 коннектах слал всех нах)
Холиварить только не будем :)
Ни в коем случае :) к тому же я не апологет майсиквела. Просто хочется получить инфу из первух рук мигрировавших. Из того что я знаю, так это только то что ждать повышения производительности не стоит (во всяком случае не затачиваясь на фишки постгреса). И как факт, перевод типичного, среднего веб приложение ничего не дает, кроме лишней мороки.
Но фишки у него интересные, аналогов некоторым (ex. postgis) фактически нет. Но многие не production-ready, во всяком случае их никто в этой связи еще не пробовал (ex. hstore) и нет историй успеха. Фишки NoSQL в классических SQL БД, честно говоря настораживают. MySQL в этом плане тоже кстати не отстает :). Тут непонятно только одно, что получат первые запилившие это в продакшен, головняк или плюшки :).
Жаль что вы только в начале процесса миграции.
Если есть уже прошедшие этот путь пожалуйста отпишитесь.
У меня впервые миграция на нагруженном проекте, да и то, тут SQL БД вторична, первична у нас neo4j, а это совершенно другой полет.
Сейчас я делаю заркало боевого трафика на машину, где в основе postgresql — полет нормальный. Теперь нам для продакшена важны как раз плюшки посгри, и ожидаю новый код для проверки.
У меня есть опыт миграции на postgresql с разных движков.
1. Oracle->postgresql: потеря в скорости вставки, что было критично; но оптимизацией кода+прослойка в виде redis решили вопрос. Ну и сэкономить кучу бабла :)
2. Mysql->postgresql: пошли затыки связанные с объемом данных, соответсвенно очень медленная вставка, ОЧЕНЬ тупил на индексах, ОЧЕНЬ медленное чтение (БЛ zabbix на 15k устройств). После перехода на пострю, количество устройств выросло до 32k (опрос раз в 30 сек), база выросла до 1,2 Тб — полет нормальный (железо то же, что и на мускуль) История кратко тут: habrahabr.ru/post/198354/#comment_6877976.
3. MSSQL->postgresql: Был сервак 1с7 с бд на mssql 2005 (или 2008, уже не помню), достаточно туповатое решение. Поступила вводная: кластер 1с8, Terminal server, 450 клиентов, рост до 600-800 в течении 5 лет. Выбрали postgres 9.0, настроили, и вполне безболезненно переплыли. Размер базы был 110 ГБ на тот момент.
По поводу NOSQL в SQL движках, мне думается, что в мускуле это легко сделать на плагинах, но работать будет плохо. По сути в мускуле нету даже нормального планировщика запросов, есть оптимизатор. Они его с 4й версии рашпилем пилят, как я понимаю. В то же время postgresql всегда ориентировался на оракл и возможность использования в ентерпрайзе, и соответственно имеет вменемый и развиваемый планировщик запросов. От сюда я делаю вывод, что если опыт и навыки позволят команде постгреса встроить в планировщик запросов работу с NOSQL данными, то например в томже key-value варианте он будет на 10-15% отставать от redis, но иметь лучший вариант консистентности данных. В случае «ленивого кеша» эти 15% будут не критичны.
Сейчас я делаю заркало боевого трафика на машину, где в основе postgresql — полет нормальный. Теперь нам для продакшена важны как раз плюшки посгри, и ожидаю новый код для проверки.
У меня есть опыт миграции на postgresql с разных движков.
1. Oracle->postgresql: потеря в скорости вставки, что было критично; но оптимизацией кода+прослойка в виде redis решили вопрос. Ну и сэкономить кучу бабла :)
2. Mysql->postgresql: пошли затыки связанные с объемом данных, соответсвенно очень медленная вставка, ОЧЕНЬ тупил на индексах, ОЧЕНЬ медленное чтение (БЛ zabbix на 15k устройств). После перехода на пострю, количество устройств выросло до 32k (опрос раз в 30 сек), база выросла до 1,2 Тб — полет нормальный (железо то же, что и на мускуль) История кратко тут: habrahabr.ru/post/198354/#comment_6877976.
3. MSSQL->postgresql: Был сервак 1с7 с бд на mssql 2005 (или 2008, уже не помню), достаточно туповатое решение. Поступила вводная: кластер 1с8, Terminal server, 450 клиентов, рост до 600-800 в течении 5 лет. Выбрали postgres 9.0, настроили, и вполне безболезненно переплыли. Размер базы был 110 ГБ на тот момент.
По поводу NOSQL в SQL движках, мне думается, что в мускуле это легко сделать на плагинах, но работать будет плохо. По сути в мускуле нету даже нормального планировщика запросов, есть оптимизатор. Они его с 4й версии рашпилем пилят, как я понимаю. В то же время postgresql всегда ориентировался на оракл и возможность использования в ентерпрайзе, и соответственно имеет вменемый и развиваемый планировщик запросов. От сюда я делаю вывод, что если опыт и навыки позволят команде постгреса встроить в планировщик запросов работу с NOSQL данными, то например в томже key-value варианте он будет на 10-15% отставать от redis, но иметь лучший вариант консистентности данных. В случае «ленивого кеша» эти 15% будут не критичны.
Но многие не production-ready, во всяком случае их никто в этой связи еще не пробовал (ex. hstore) и нет историй успеха.
hstore, кстати, очень популярное расширение. Практически, в какой крупный проект ни ткнись — везде hstore :)
Sign up to leave a comment.
Миграция с mysql на postgresql